Mysql

MySQL 表定义主键不是必须的，并且直到明天（MySQL 版本 8.3.0）都是这样。不过，在 MGR 和 PXC 架构中不容许应用没有主键的表。如果数据表没有主键，会有许多家喻户晓的负面性能影响，其中最苦楚的是复制速度很蹩脚。 明天，我想疾速阐明一下 须要应用主键的另一个起因：磁盘空间！ 创立一个非常简单的示例表： mysql > show create table test1\G*************************** 1. row *************************** Table: test1Create Table: CREATE TABLE `test1` ( `a` int NOT NULL, `b` bigint DEFAULT NULL, KEY `a` (`a`), KEY `b` (`b`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci1 row in set (0.00 sec)填充 10M 测试行，须要 748M 磁盘空间。当初，假如我的测试表的 a 列具备惟一值： mysql > select count(*) from test1;+----------+| count(*) |+----------+| 10000000 |+----------+1 row in set (1.34 sec)mysql > select count(DISTINCT(a)) from test1;+--------------------+| count(DISTINCT(a)) |+--------------------+| 10000000 |+--------------------+1 row in set (5.25 sec)上面我将把索引类型更改为主键： ...

MySQL整体分为两层，1.server层，2.存储引擎（InnoDB，Memory，MyISAM）等，默认应用InnoDB。server层分为连接器，查问缓存，分析器，优化器，执行器。外围服务根本都在这层，不同存储引擎共用同一个server层。应用时须要先链接，应用的协定是TCP，须要出入IP地址，端口，用户名和明码。链接后长时间不应用该链接会处于Sleep状态，超时（wait_timeout）后会断开连接，默认8小时。连贯分为长连贯和短连贯；长连贯是连贯胜利后如果始终有查问动作则始终不会断开；短连贯是执行过几轮查问后会断开连接，再次应用须要重连。连贯过程简单耗时，所以倡议应用长连贯。但长连贯应用过多也会导致MySQL内存涨的比拟块，这是因为在查问过程中长期应用的内存会治理在连贯对象中，这样连贯不中断内存不开释。重大时会导致MySQL内存占用量过高而被零碎强制杀掉，这样就会呈现MySQL异样重启。为了防止这个问题能够: 定期断开长连贯。应用一段时间，或者程序外面判断执行过一个占用内存的大查问后，断开连接，之后要查问再重连.如果你用的是 MySQL 5.7 或更新版本，能够在每次执行一个比拟大的操作后，通过执行 mysql_reset_connection 来从新初始化连贯资源。这个过程不须要重连和从新做权限验证，然而会将连贯复原到刚刚创立完时的状态查问缓存就是在连贯建设后的查问操作的第一步，如果命中缓存就间接返回后果完结查问，看似会进步查问效率。然而大多数状况下我会倡议你不要应用查问缓存，为什么呢？因为查问缓存往往弊大于利。查问缓存变更频繁，只有对表进行更新，那表中的查问缓存全副清空。好在 MySQL 也提供了这种“按需应用”的形式，你能够将参数 query_cache_type 设置成 DEMAND，这样对于默认的 SQL 语句都不应用查问缓存。而对于你确定要应用查问缓存的语句，能够用 SQL_CACHE 显式指定，像上面这个语句一样 mysql> select SQL_CACHE * from T where ID=10；解析器，辨认sql语法，次要做词法剖析和语法分析。优化器，在解析器执行实现后引擎就能了解用户的行为了，但很多行为逻辑后果统一但因为两头执行程序不同而执行效率也不同。如：优化器是在表外面有多个索引的时候，决定应用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连贯程序。优化器的作用就是决定执行程序，保障执行效率。执行器，依据优化后的语句调用存储引擎的接口，将执行后果收集并返回给客户端。留神一点，表名是否存在，表中列是否存在等判断都是在解析器阶段进行判断的。

作者：俊达xtrabackup反对增量备份。在做增量备份之前，须要先做一个全量备份。xtrabackup会基于innodb page的lsn号来判断是否须要备份一个page。如果page lsn大于上次备份的lsn号，就须要备份该page。1、先进行一次全量备份。 xtrabackup --backup --slave-info -u root -H 127.0.0.1 -P3380 \ -pabc123 --stream=xbstream --target-dir /data/backup/full \ --extra-lsndir=/data/backup/full \ 2>/data/backup/full/backup_full.log | gzip - > /data/backup/full/backup_full.gz备份命令加上了--extra-lsndir选项，将xtrabackup_checkpoints独自输入到文件。增量备份时须要依据xtrabackup_checkpoints中的lsn。相干文件： # ls -l /data/backup/full总用量 2996-rw-r--r-- 1 root root 3014835 6月 25 16:35 backup_full.gz-rw-r--r-- 1 root root 40313 6月 25 16:35 backup_full.log-rw-r--r-- 1 root root 134 6月 25 16:35 xtrabackup_checkpoints-rw-r--r-- 1 root root 673 6月 25 16:35 xtrabackup_info2、发动增量备份 mkdir /data/backup/inc1xtrabackup --backup --slave-info -u root -H 127.0.0.1 -P3380 \ -pabc123 --stream=xbstream --target-dir /data/backup/inc1 \ --extra-lsndir=/data/backup/inc1 \ --incremental-basedir=/data/backup/full \ 2>/data/backup/inc1/backup_inc1.log | gzip - > /data/backup/inc1/backup_inc1.gz-incremental-basedir：全量备份或上一次增量备份xtrabackup_checkpoints文件所在目录增量备份也能够在上一次增量备份的根底上进行： ...

二阶段提交的 prepare 阶段，binlog 和 InnoDB 各自会有哪些动作？ 本文基于 MySQL 8.0.32 源码，存储引擎为 InnoDB。1. 二阶段提交二阶段提交，顾名思义，蕴含两个阶段，它们是： prepare 阶段。commit 阶段。咱们只思考 SQL 语句操作 InnoDB 表的场景，对于用户事务，是否应用二阶段提交，取决于是否开启了 binlog。 因为 MySQL 把 binlog 也看作一个存储引擎，开启 binlog，SQL 语句扭转（插入、更新、删除）InnoDB 表的数据，这个 SQL 语句执行过程中，就波及到两个存储引擎。 应用二阶段提交，就是为了保障两个存储引擎的数据一致性。 用户事务提交分为两种场景，如果开启了 binlog，它们都会应用二阶段提交。 场景 1：通过 BEGIN 或其它开始事务的语句，显式开始一个事务，用户手动执行 COMMIT 语句提交事务。 场景 2：没有显式开始的事务，一条 SQL 语句执行时，InnoDB 会隐式开始一个事务，SQL 语句执行实现之后，主动提交事务。 如果没有开启 binlog，SQL 语句扭转表中数据，不产生 binlog，不必保障 binlog 和表中数据的一致性，用户事务也就不须要应用二阶段提交了。 InnoDB 内部事务是个特例，不论是否开启了 binlog，扭转表中数据都不会产生 binlog 日志，所以内部事务不须要应用二阶段提交。 2. prepare 阶段以下代码中，ha_prepare_low() 会调用 binlog 和 InnoDB 解决 prepare 逻辑的办法。 int MYSQL_BIN_LOG::prepare(THD *thd, bool all) { ... thd->durability_property = HA_IGNORE_DURABILITY; ... int error = ha_prepare_low(thd, all); ...}调用 ha_prepare_low() 之前，用户线程对象的 durability_property 属性值会被设置为 HA_IGNORE_DURABILITY。 ...

作者：俊达xtrabackup工具中有一个xbcloud程序，能够将数据库间接备份到S3对象存储中，本地不落盘。这里介绍将数据库间接备份到OSS的一种办法。具体方法如下： 1、筹备OSS咱们应用ossutil工具上传备份文件。下载ossutil工具： wget -O ossutil-v1.7.16-linux-amd64.zip "https://gosspublic.alicdn.com/ossutil/1.7.16/ossutil-v1.7.16-linux-amd64.zip?spm=a2c4g.120075.0.0.33ee51f9DUd7FF&file=ossutil-v1.7.16-linux-amd64.zip" unzip ossutil-v1.7.16-linux-amd64.zipcp ossutil-v1.7.16-linux-amd64/ossutil64 /usr/local/bin/chmod +x /usr/local/bin/ossutil64筹备oss配置文件：运行ossutil64 config，按提醒输出endpoint，ak，sk信息 ossutil64 config生成的配置文件如下： # cat ~/.ossutilconfig[Credentials]language=ENendpoint=oss-cn-hangzhou.aliyuncs.comaccessKeyID=XXXXaccessKeySecret=XXXX查看配置是否正确： ossutil64 ls oss://ycdbbackupossutil64 cp localfile oss://ycdbbackup2、创立一个命名管道 mkfifo /data/backup/backup0625.xbstreamls -l /data/backup/backup0625.xbstreamprw-r--r-- 1 root root 0 6月 25 14:33 /data/backup/backup0625.xbstream3、执行备份命令将备份的输入重定向到步骤2创立的命名管道。 xtrabackup --backup --slave-info -u root -H 127.0.0.1 -P3380 -pabc123 \ --stream=xbstream --target-dir /data/backup/ 2>/data/backup/xtrabackup.log \ > /data/backup/backup0625.xbstream4、应用ossutil工具将备份文件上传到OSS # ossutil64 cp /data/backup/backup0625.xbstream oss://ycdbbackupSucceed: Total num: 1, size: 0. OK num: 1(upload 1 files).average speed 1081000(byte/s)189.095486(s) elapsed5、将备份日志信息也上传到OSS倡议将xtrabackup备份的日志信息也上传到OSS ...

本文介绍了 MySQL 8.3 的一个新个性，给 GTID 打标签~ 作者：李富强，爱可生 DBA 团队成员，相熟 MySQL，TiDB，OceanBase 等数据库。置信继续把对的事件做好一点，会有不一样的播种。 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文约 900 字，预计浏览须要 3 分钟。 摘要MySQL 8.3 翻新版于 2024 年 1 月 16 号公布，该版本扩大了 MySQL 复制和组复制中应用全局事务标识（GTID）的格局，反对给 GTID 打标签，以反对辨认事务组。此加强性能能够为特定事务组的 GTID 调配惟一标识。例如：蕴含数据操作的事务能够很容易地与治理操作产生的事务辨别开来，只须要比拟他们的 GTID。 GTID 格局原始格局原始 GTID 格局是 source_id:transaction_id source_id 标识源服务器，通常用 server_uuid 示意。transaction_id 代表事务在源上提交的程序，例如要提交第一个事务的 transaction_id 为 1，要在同一源服务器上提交的第十个事务的 transaction_id 就是 10。全局惟一标识符（GTID）是创立并与源服务器上提交的每个事务相关联的惟一标识符。此标识符不仅对其发动的服务器是惟一的，在给定复制拓扑中所有服务器上都是惟一的。 带标签的格局扩大后的 GTID 格局是 source_id:\<tag>:transaction_id，其中 tag 是最长为 8 个字符的任意字符串。通过设置零碎变量 gtid_next 的值为 automatic:\<tag> 启用，或者设置 gtid_next 为 uuid:\<tag>:transaction_id 以将单个事务的 uuid 设置为任意值，并为其调配自定义标签。 操作试验通过 mysql-shell 工具，疾速部署一个 MySQL 8.3 版本的实例（过程略）。 ...

前言说实话，比拟一下这两个 MySQL 发行版，并不会让我很兴奋。这是因为在我对于 MySQL 的记忆中，如果是谈代码库时，两个发行版之间没有真正的区别。 据我所知，企业版的差别在于附加的插件/组件，因而除非您明确须要应用它们，否则两个版本应该是雷同或靠近的。 那么你可能会说，为什么要写这篇文章？ 好吧，在一篇 Oracle 的博客及其开场白 戳中了这一点：MySQL 8.0.35 的企业版与社区版相比，性能方面是有所提高的。 以下是该文章的局部后果截图： 依据显示的后果来看，让我特地想进一步测试一下，但服务器的配置形式有点麻烦。 在博客的测试中，测试数据库总大小为 20 GB，相应的 InnoDB 缓冲池为 124 GB，其余设置与默认值不同，如 innodb_undo_log_truncate=FALSE。 简而言之，这意味着所有工作都在内存中实现，一旦加载数据，磁盘上的任何操作都会缩小。设置是为了满足测试基准，而不是基于定制或通用默认值的理论生产而筹备。 同样令我打动的是，该文章报告 企业版的性能进步了 17% 到 25% 。 25% 的增长是很多了。难道不值得验证一下吗？当然，是的，我接下来就是这么做的。 测试环境筹备意外 Oracle，因而我的测试基于一个配置较差的 EC2 实例：m5.xlarge 4 个 CPU、16GB RAM。 我还应用提供的卷作为 MySQL 数据目录的地位，而用于在测试运行之间重置数据的离线数据集位于额定的块存储上。 应用程序节点位于同一网络/子网/区域中，并且也是 m5.xlarge 规格。 没有代理或中间件。 MySQL 企业版 和 社区版 的配置次要基于默认值，但以下内容除外： [mysqld]basedir =/opt/mysql_templates/mysql-8P/datadir = /opt/mysql_instances/test-sysbench-my834/datalc_messages_dir =/opt/mysql_templates/mysql-8P/share/log-error = /opt/mysql_instances/test-sysbench-my834/mysql-3307.errpid-file = /opt/mysql_instances/test-sysbench-my834/mysqld.pidplugin-dir =/opt/mysql_templates/mysql-8P/lib/plugin/port = 3307server-id = 3307socket = /opt/mysql_instances/test-sysbench-my834/mysql.socktmpdir = /opt/mysql_instances/test-sysbench-my834/tempuser =mysqldefault_time_zone='+01:00'max-connections =2500innodb-buffer-pool-instances =3innodb-buffer-pool-size =10Ginnodb-data-file-path =ibdata1:100M:autoextendinnodb_data_home_dir = /opt/mysql_instances/test-sysbench-my834/datainnodb_redo_log_capacity =3355443200innodb_log_group_home_dir = /opt/mysql_instances/test-sysbench-my834/logsskip-log-bin简而言之，禁用 binlog，将 redo log 设置为理论的值。当然，将缓冲池设置为适宜 RAM 但不适宜数据集的维度。所有其余参数都是指向 日志/二进制文件/库 的指针。 ...

我在通过下列形式启动mysql服务时，遇到了服务启动不胜利，且服务没有报错的状况 当然第一种解决形式当然是通过管理员权限关上cmd，而后键入netstat -aon查看3306端口是否被占用，如果被占用的话，就拿到3306那一行的PID值而后通过 taskkill /f /pid xxxx 杀死过程。 最初再通过上面形式启动mysql服务。 net start mysql那么如果说上述情况不论用，重新启动mysql服务还是呈现第一次的那个问题，那么就请应用上面的形式去做 首先查看配置文件是否有谬误，能够参考早晨的配置文件输出上面命令（将本来的mysql删除） sc query mysql sc delete mysql将mysql的data数据删除（已有数据请及时做备份）跳转到mysql的bin目录下，输出mysqld --initialize --console ,初始化数据库，并获取初始登陆的明码通过mysql -u username -p 登陆mysql界面通过 set password for root@localhost=password('您的明码')去批改登陆密码最初通过net start mysql，实现mysql服务的启动

作者：俊达xtrabackup是percona开源的mysql物理备份工具。xtrabackup 8.0反对mysql 8.0版本的备份和复原。xtrabackup 2.4反对mysql 5.7及以下版本的备份和复原。这里咱们以xtrabackup 8.0为例解说备份和复原的具体操作办法。xtrabackup 2.4版本的应用上和8.0版本相差并不大。 全量备份本地全量备份将整个数据库备份到本地目录。 xtrabackup --backup --slave-info -u root -H 127.0.0.1 -P3380 -pabc123 --target-dir /data/backup/ 2>/tmp/xtrabackup.log要害参数阐明： backup：发动全量备份-u, -H, -P, -p：连贯mysql实例，用户名、主机IP、端口、明码-slave-info：记录slave复制位点信息-target-dir：备份文件的寄存门路2>/tmp/xtrabackup.log：将备份过程中的日志重定向到/tmp/xtrabackup.log文件中备份过程中的日志信息会输入到规范谬误中，个别能够重定向到文本文件中备份进去的文件： -rw-r----- 1 root root 448 6月 26 14:46 backup-my.cnf-rw-r----- 1 root root 610 6月 26 14:46 binlog.000020-rw-r----- 1 root root 36 6月 26 14:46 binlog.indexdrwxr-x--- 2 root root 4096 6月 27 11:03 demo-rw-r--r-- 1 root root 9326 6月 27 11:03 export.log-rw-r----- 1 root root 5554 6月 26 14:46 ib_buffer_pool-rw-r----- 1 root root 134217728 6月 27 11:03 ibdata1-rw-r----- 1 root root 12582912 6月 27 11:03 ibtmp1drwxr-x--- 2 root root 4096 6月 27 11:03 #innodb_redodrwxr-x--- 2 root root 4096 6月 26 14:46 mysql-rw-r----- 1 root root 25165824 6月 26 16:08 mysql.ibddrwxr-x--- 2 root root 4096 6月 26 14:46 performance_schema-rw-r--r-- 1 root root 7883 6月 26 16:08 prepare_full.log-rw-r--r-- 1 root root 9109 6月 26 16:08 prepare_full.log.2drwxr-x--- 2 root root 4096 6月 27 11:03 sys-rw-r----- 1 root root 16777216 6月 26 16:08 undo_001-rw-r----- 1 root root 16777216 6月 26 16:08 undo_002-rw-r----- 1 root root 105 6月 26 14:46 xtrabackup_binlog_info-rw-r----- 1 root root 134 6月 27 11:03 xtrabackup_checkpoints-rw-r----- 1 root root 673 6月 26 14:46 xtrabackup_info-rw-r----- 1 root root 8388608 6月 26 16:08 xtrabackup_logfile-rw-r----- 1 root root 154 6月 26 14:46 xtrabackup_slave_info-rw-r----- 1 root root 39 6月 27 11:03 xtrabackup_tablespacesxtrabackup_logfile：innodb redo日志备份 ...

作者：俊达 主库server_id没有设置主库没有设置server_id Got fatal error 1236 from master when reading data from binary log: 'Misconfigured master - server_id was not set'主库查看server_id mysql> show variables like 'server_id';+----------------+-------+| Variable_name | Value |+----------------+-------+| server_id | 1 |即便没有设置server_id，show variables命令查看server_id为1， 解决办法：1、 主库设置server_id倡议不要将server_id设置为1 mysql> set global server_id=234;同时在配置文件中设置server_id，防止数据库重启后参数设置生效。2、备库上重新启动复制 stop slave;start slave;show slave status\G备库server_id没有设置如果备库没有设置server_id，也无奈启动复制 mysql> set global server_id=default;Query OK, 0 rows affected (0.00 sec)mysql> start slave;ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO从谬误日志中能够看到无奈启动备库的起因： ...

1. 筹备工作参数配置： binlog_format = ROWbinlog_rows_query_log_events = OFF创立测试表： CREATE TABLE `t_binlog` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `i1` int DEFAULT '0', `str1` varchar(32) DEFAULT '', PRIMARY KEY (`id`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;示例 SQL： BEGIN;INSERT INTO `t_binlog` (`i1`, `str1`)VALUES (100, 'MySQL 外围模块揭秘');COMMIT;2. 解析 binlog执行示例 SQL 之后，咱们能够用上面的命令解析事务产生的 binlog 日志： cd <binlog 日志文件目录>mysqlbinlog binlog.000395 \ --base64-output=decode-rows -vv解析 binlog 日志之后，咱们能够失去 4 个 binlog event。 依照这些 binlog event 在 binlog 日志文件中的程序，简化之后的内容如下： Query_log_event# at 1233# Query thread_id=8BEGINTable_map_log_event# at 1308Table_map: `test`.`t_binlog` mapped to number 95Write_rows_log_event# at 1369Write_rows: table id 95 flags: STMT_END_FINSERT INTO `test`.`t_binlog`SET @1=1 /* INT meta=0 nullable=0 is_null=0 */ @2=100 /* INT meta=0 nullable=1 is_null=0 */ @3='MySQL 外围模块揭秘' /* VARSTRING(96) meta=96 nullable=1 is_null=0 */Xid_log_event# at 1438Xid = 32COMMIT/*!*/;示例 SQL 中，只有两条 SQL 会产生 binlog event： ...

作者：俊达MySQL从5.6版本开始反对GTID复制。开启GTID之后，主库上执行的每一个事务都有一个全局惟一的ID。GTID由两局部组成：server_uuid和事务序列号。初始化数据库时，会生成一个全局惟一的server_uuid，server_uuid保留在datadir下的auto.cnf中： # cat auto.cnf[auto]server-uuid=e7ce5684-09b8-11ee-9dd0-fa8338b09400如果删除auto.cnf，重启实例时会从新生成。事务序列号在事务提交时按程序生成。 GTID事务复制到备库时，GTID放弃不变。开启GTID有很多长处： 1、MySQL会记录执行过的GTID事务，这样就能够防止反复执行同一个事务。如果没有开启GTID，change master时如果指定的位点不对，可能会反复执行事务，引起主备数据不统一或复制中断。 2、change master时反对主动定位，mysql会依据以后实例曾经执行过的GTID事务，主动判断须要同步哪些binlog。 1、主库开启GTID除了惯例的参数，主库须要配置 enforce_gtid_consistency和gtid_modeenforce_gtid_consistency=ONgtid_mode=ONlog_bin=/data/mysql5.6/binlog/binloglog_slave_updates=ONbinlog_format=ROWserver_id=2342、主库创立复制账号在进行主库和备库之间的复制前，须要在主库上创立一个专用于复制的账号，并授予相应的权限。以下是创立复制账号的步骤： -- 创立复制账号CREATE USER 'rep'@'%' IDENTIFIED BY 'rep123';-- 授予复制账号必要的权限GRANT REPLICATION SLAVE ON *.* TO 'rep'@'%';创立完复制账号后，备库能够应用这个账号连贯到主库，并通过复制账号进行数据同步。在备库上配置复制时，将会应用这个账号的凭证信息。 3、备库配置5.6版本开启GTID时，备库也必须开启log-bin和log-slave-updates，否则无奈启动实例。 enforce_gtid_consistency=ONgtid_mode=ONlog_bin=/data/mysql5.6/binlog/binloglog_slave_updates=ONbinlog_format=ROWserver_id=2365.6版本开启GTID，不设置log-bin和log-slave-updates，实例无奈启动： 2023-06-14 14:56:35 23275 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 or UPGRADE_STEP_2 requires --log-bin and --log-slave-updates2023-06-14 14:56:35 23275 [ERROR] Aborting从5.7版本开始，备库不开启binlog和log-slave-updates也能够应用GTID。 4、备库初始化这一步和非GTID的步骤根本一样。不过开启GTID后，通常须要记录GTID_PURGED，作为复制的终点。 /opt/mysql5.7/bin/mysqldump -uroot -h127.0.0.1 -P3357 -pabc123 --all-databases \ --master-data=2 --routines --flush-privileges --triggers --events > /tmp/mysql57_dump.sql--gtid-mode=auto：如果数据库开启了GTID，则备份文件中会退出set global GTID_PURGED=xxx; 5、备库创立复制通道change master to master_host='172.16.121.234',master_port=3356,\master_user='rep',master_password='rep123', master_auto_position=1;开启GTID之后，能够在change master时指定master_auto_position=1，启用主动定位。这样就不须要指定具体的binlog位点。slave会依据gtid_executed主动计算须要同步主库的哪些binlog。 更多技术信息请查看云掣官网https://yunche.pro/?t=yrgw

在 MySQL 中执行 Online DDL 之前，须要保障在三个方面的空间短缺。 作者：徐文梁，爱可生 DBA 成员，一个执着于技术的数据库工程师，次要负责数据库日常运维工作。善于 MySQL，Redis 及其他常见数据库也有涉猎；喜爱垂钓，看书，看风光，结交新敌人。 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文约 1400 字，预计浏览须要 4 分钟。 问题背景客户反馈对某张表执行 alter table table_name engine=innodb; 时报错空间有余。 通过登录数据库查看客户的 tmpdir 设置的门路，发现是 /tmp。该目录磁盘空间自身较小，调整 tmpdir 的门路与数据目录雷同，从新执行 ALTER 操作执行胜利。 问题到此结束了，然而故事并没有完结。通过查看官网信息，咱们能够从这个小小的报错中深挖更多信息。 信息解读从官网的阐述中，咱们能够理解到，在进行 Online DDL 操作时，须要保障以下三个方面的空间短缺，否则可能会导致空间有余报错。 长期日志文件当进行 Online DDL 操作创立索引或者更改表时，长期日志文件会记录期间的并发 DML 操作，长期日志文件最大值由 innodb_online_alter_log_max_size 参数管制，如果 Online DDL 操作耗时较长（如果表数据量较大这是很有可能的），并且期间并发 DML 对表中的记录批改较多，则可能导致长期日志文件大小超过 innodb_online_alter_log_max_size 值，从而引发 DB_ONLINE_LOG_TOO_BIG 谬误，并回滚未提交的并发 DML 操作。 长期排序文件对于会重建表的 Online DDL 操作，在创立索引期间，会将长期排序文件写入到 MySQL 的长期目录。仅思考 UNIX 零碎，对应的参数为 _tmpdir_，如果 /tmp 目录比拟小，请设置该参数为其余目录，否则可能会因为无奈包容排序文件而导致 Online DDL 失败。 ...

引言在构建数据库复制零碎时，正确配置主库和备库是确保数据同步顺利进行的关键步骤。以下是建设复制的根本步骤，次要包含主库开启binlog的要害参数设置，创立主库复制账号以满足根本权限需要，备库参数配置和初始化的步骤。 1、主库开启binlog主库须要配置的要害参数server_id：主备库须要设置为不同。log_bin：binlog文件的前缀，能够指定绝对路径，也能够只指定文件名。若不指定门路，binlog默认寄存在datadir指定的门路下。binlog_format：可设置为STATEMENT、MIXED、ROW这几种模式。个别倡议应用ROW模式。 server_id=100log_bin=/data/mysql5.6/binlog/binlogbinlog_format=ROW# log_slave_updates=ON上述参数中，log_bin不能动静批改。须要重启mysql能力失效。应用show global variables确认主库binlog曾经开启： mysql> show global variables like 'log_bin%';| log_bin | ON || log_bin_basename | /data/mysql5.6/binlog/binlog || log_bin_index | /data/mysql5.6/binlog/binlog.index |应用show binary logs命令查看主库binlog列表： mysql> show binary logs;+---------------+-----------+| Log_name | File_size |+---------------+-----------+| binlog.000001 | 120 |+---------------+-----------+1 row in set (0.00 sec)2、主库创立复制账号（满足根本权限要求）主库须要创立一个复制账号，备库须要应用复制账号连贯到主库，获取binlog。 mysql> create user 'rep'@'%' identified by 'rep123';Query OK, 0 rows affected (0.00 sec)mysql> grant replication slave on *.* to 'rep'@'%';Query OK, 0 rows affected (0.00 sec)复制账号须要的权限：replication slave。 ...

<article class=“article fmt article-content”><p><strong>MatrixOne是一款高度兼容MySQL语法的HTAP数据库，在大部分场景下能够间接实现对MySQL的替换。</strong></p><p>作为一款开源数据库，MatrixOne 选用对开发者敌对的<strong>Apache-2.0 License</strong>，反对在支流的 Linux 和 MacOS 零碎中间接进行物理部署。在部署形式上，<strong>MatrixOne反对源码编译部署、二进制包部署和Docker容器部署</strong>。各种部署形式均操作简略，疾速部署后即可领有单机不输MySQL的数据分析和事务处理能力。</p><p>以MatrixOne最新的Release版本1.0.1为例，MatrixOne提供了4类二进制包，别离用于在x86架构和arm架构的MacOS零碎与Linux零碎部署。</p><ul><li>mo-v1.0.1-darwin-arm64.zip</li><li>mo-v1.0.1-darwin-x86_64.zip</li><li>mo-v1.0.1-linux-arm64.zip</li><li>mo-v1.0.1-linux-x86_64.zip</li></ul><p>区别于MySQL在不同操作系统下部署时的繁琐和不对立，MatrixOne的二进制包单机部署开箱即用。</p><p>例如在任意x86架构的Linux零碎中，咱们能够通过wget命令获取MatrixOne的二进制包：</p><pre><code class=“text”>wget https://github.com/matrixorigin/matrixone/releases/download/v1.0.1/mo-v1.0.1-linux-x86_64.zip</code></pre><p>而后创立指标的部署目录：</p><pre><code class=“text”>mkdir /opt/matrixone</code></pre><p>解压安装包至目标目录：</p><pre><code class=“text”>unzip mo-v1.0.1-linux-x86_64.zip -d /opt/matrixone</code></pre><p>解压实现后切换目录，启动MatrixOne服务：</p><pre><code class=“text”>cd /opt/matrixone./mo-service –daemon –launch ./etc/launch/launch.toml &> test.log &</code></pre><p>MatrixOne将所有的服务都打包在了mo-service包中，启动命令执行后，可通过查看服务或查看6001端口监听状况来确认服务启动状况：</p><pre><code class=“text”>ps -ef | grep mo-servicenetstat -nlap | grep 6001</code></pre><p><strong>须要留神的是，MatrixOne没有自带客户端工具，咱们能够应用mysql client或DBeaver、Navicat、SQLYog等可视化工具将MatrixOne视为MySQL来进行拜访。</strong></p><p>MatrixOne启动后提供查问服务的端口为6001，默认启用的用户为root，初始密码为111，例如咱们应用mysql client拜访时的命令可写为：</p><pre><code class=“mysql”>mysql -h127.0.0.1 -P6001 -uroot -p111</code></pre><p>当看到如下信息即示意拜访胜利，咱们就能够像应用MySQL个别进行库表创立或数据查问/写入：</p><pre><code class=“text”>Server version: 8.0.30-MatrixOne-v1.0.1 MatrixOne</code></pre><p>除手动部署外，MatrixOne还提供了晋升易用性的mo_ctl工具，mo_ctl不单能疾速部署，还可一键式的进行MatrixOne服务的启动进行或github commitid级的版本升降级，残缺的介绍可参考官网文档：</p><ul><li>https://docs.matrixorigin.cn/1.0.1/MatrixOne/Get-Started/install-on-linux/install-on-linux-method2/</li><li>https://docs.matrixorigin.cn/1.0.1/MatrixOne/Maintain/mo_ctl/</li></ul><p><strong>MatrixOne目前没有binlog性能，以后也未反对“主从架构”的部署，这个能力会在后续版本和大家见面，补齐本地模式下的高可用能力。</strong></p><p>对于习惯应用Docker进行容器部署的同学，MatrixOne已将各版本的镜像上传至Docker Hub，咱们同样能够通过两行命令疾速实现MatrixOne的镜像获取和服务启动：</p><pre><code class=“docker”>docker pull matrixorigin/matrixone:1.0.1docker run -d -p 6001:6001 –name matrixone matrixorigin/matrixone:1.0.1</code></pre><ul><li>与MySQL的TP定位不同，MatrixOne是一款汇合TP和AP能力的“超交融云原生分布式数据库”，这也示意基于K8s的集群部署能力充分发挥MatrixOne极致的剖析性能。</li></ul><p>MatrixOne在架构上实现了三个独立的层级，每个层级都有本人的对象单元和分工。不同类型的节点能够自在伸缩，不受到其余层的制约。</p><p>这三个层级是：</p><ul><li><strong>计算层</strong>：以计算节点 Compute Node（简称 CN）为单位，实现了计算和事务处理的 Serverless 化，具备本人的缓存，能够任意重启和扩缩容。</li><li><strong>事务层</strong>：以数据库节点 Transaction Node（简称 TN ）和日志节点 Log Service 为单位，提供残缺的日志服务和元数据信息，内置 Logtail 用于保留最近的数据。</li><li><strong>存储层</strong>：全量数据保留在对象存储中，以 S3 为代表，实现了低成本的有限伸缩存储形式。对立的文件操作服务 File Service 实现了不同节点对底层存储的无感知操作。</li></ul><p></p><p>MatrixOne基于K8s的集群部署操作能够参考官网文档集群部署指南章节，MatrixOne中的CN节点是无状态的，在K8s中能够依据负载进行任意的弹性扩缩，保障集群持续保持较低的SQL执行耗时。</p><p>MatrixOne在K8s中的部署是绝对繁琐的，若您想体验MatrixOne集群的卓越性能，欢送试用MatrixOne Cloud。MatrixOne Cloud 是一个全托管云原生数据平台，它提供了 HSTAP 数据库 MatrixOne 的云上服务，极大简化了 MatrixOne 的部署和运维老本。并且，MatrixOne Cloud 所提供的 Serverless 实例反对计算资源的主动弹性伸缩以及按 SQL 用量计费，让咱们不需再关注数据库部署运维的复杂性，而能够仅关注业务利用或SQL自身。</p><p>以后MatrixOne Cloud正在全面公测，新用户注册每月赠送500元的收费额度，欢送大家前来试用和反馈。</p></article> ...

基本概念二进制日志（binnary log）以事件模式记录了对MySQL数据库执行更改的所有操作。 binlog 是逻辑日志，记录内容是语句的原始逻辑，相似于“给 ID=2 这一行的 c 字段加 1”，属于MySQL Server 层。 binlog是记录所有数据库表构造变更（例如CREATE、ALTER TABLE…）以及表数据批改（INSERT、UPDATE、DELETE…）的二进制日志。不会记录SELECT和SHOW这类操作，因为这类操作对数据自身并没有批改，但能够通过查问通用日志来查看MySQL执行过的所有语句。 须要留神的一点是，即使update操作没有造成数据变动，也是会记入binlog。 不论用什么存储引擎，只有产生了表数据更新，都会产生 binlog 日志。 binlog有两个罕用的应用场景： 主从复制：mysql replication在master端开启binlog，master把它的二进制日志传递给slaves来达到master-slave数据统一的目标。数据恢复：通过mysqlbinlog工具来复原数据。 binlog会记录所有波及更新数据的逻辑操作，并且是程序写。 记录格局binlog 日志有三种格局，能够通过binlog_format参数指定。 statementrowmixed指定statement，记录的是逻辑SQL语句，比方执行一条update T set update_time=now() where id=1，记录的内容如下。长处是日志文件小，节约IO，进步性能。 同步数据时，会执行记录的SQL语句，然而有个问题，update_time=now()这里会获取以后零碎工夫，间接执行会导致与原库的数据不统一。 row 记录表的行更改状况，准确性强，能够为数据库的复原、复制带来更好的可靠性；然而二进制文件的大小相较于STATEMENT会有所增加，较大的网络IO和磁盘IO。 mixed：STATEMENT和ROW模式的混合。默认采纳STATEMENT格局进行二进制日志文件的记录，然而在一些状况下会应用ROW格局。 写入机制binlog的写入机会也非常简单，事务执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。 因为一个事务的binlog不能被拆开，无论这个事务多大，也要确保一次性写入，所以零碎会给每个线程调配一个块内存作为binlog cache。 咱们能够通过binlog_cache_size参数管制单个线程 binlog cache 大小，如果存储内容超过了这个参数，就要暂存到磁盘（Swap）。 binlog日志刷盘流程如下 上图的 write，是指把日志写入到文件系统的 page cache（binlog file），并没有把数据长久化到磁盘，所以速度比拟快上图的 fsync，才是将数据长久化到磁盘的操作。个别状况下，咱们认为 fsync 才占磁盘的 IOPS。write和fsync的机会，能够由参数sync_binlog管制，默认是1。 N=1：示意采纳同步写磁盘的形式来写二进制日志，这时写操作不应用操作系统的缓冲来写二进制日志，每次事务提交都会写入文件。N=0：为0的时候，示意每次提交事务都只write，由零碎自行判断什么时候执行fsync。尽管性能失去晋升，然而机器宕机，page cache外面的 binlog 会失落。最初还有一种折中形式，能够设置为N(N>1)，示意每次提交事务都write，但累积N个事务后才fsync。在呈现IO瓶颈的场景里，将sync_binlog设置成一个比拟大的值，能够晋升性能。同样的，如果机器宕机，会失落最近N个事务的binlog日志。binlog_cache相干参数介绍属性阐明binlog_cache_size示意binlog_cache的容量，默认大小为32K.binlog_cache_use记录了应用缓冲写二进制日志的次数binlog_cache_disk_use记录了应用临时文件写二进制日志的次数binlog_cache_size是基于会话(session)的。每个线程一个，参数 binlog_cache_size 用于管制单个线程内 binlog cache 所占内存的大小。如果超过了这个参数规定的大小，就要暂存到磁盘（临时文件中）。 binlog的存储地位show variables like 'datadir'查问binlog文件的默认大小show variables like 'max_binlog_size'max_binlog_size 指定了单个二进制文件的最大值（默认1G）。如果超过该值，则产生新的二进制文件，后缀名+1，并记录到index文件。 ...

MySQL 8 和 MySQL 5.7 在自增计数上的区别 作者：Arunjith Aravindan 本文起源：Percona 博客，爱可生开源社区翻译。 本文约 900 字，预计浏览须要 2 分钟。 Auto-Increment自增（Auto-Increment）计数性能能够为主键列生成惟一值，这是数据库的一种设计。与 MySQL 5.7 相比，MySQL 8 为自增性能做了一项重要的降级。这个降级能够确保自增计数器的最大值在服务器重启后放弃不变，从而为数据一致性和可靠性提供了更好的保障。在本文中，咱们将比照 MySQL 5.7 和 MySQL 8 的不同之处，并提供理论示例来展现两者的区别。 MySQL 5.7 的自增在 MySQL 5.7 中，主动增计数器的工作机制如下：当向蕴含自增列的表中插入新的一行数据时，计数器会主动加 1，生成的数值会作为插入行的主键应用。这个计数器值仅保留在内存中，在服务器重启后无奈长久化。因而，如果服务器解体或重启，计数器可能会重置为一个较低的值。 MySQL 8 的自增长久化随着 MySQL 8 的公布，自增计数器机制有了显著改良。在 MySQL 8 中，自增计数器的最大值当初能够在服务器重启后长久化。这意味着，即便服务器重启，自增计数器也会从上次完结的中央复原，以确保自增主键的值放弃间断。 示例比照让咱们用一个简略的例子来阐明 MySQL 5.7 和 MySQL 8 在长久自增计数器方面的区别。咱们将创立一个名为 users 的表，用于存储用户信息。 在 MySQL 5.7 中建表。 mysql> select version();+-----------+| version() |+-----------+| 5.7.42-46 |+-----------+mysql> CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL);Query OK, 0 rows affected (0.02 sec)在表中插入三条数据，能够查看到。 ...

如果您在容器上部署MySQL，那么首要任务之一就是找到正确的镜像。 有肯定水平的凌乱，尤其是当咱们试图帮忙部署有问题的人时。 例如，当人们说我应用的是官网的docker镜像… 这到底意味着什么？Docker Hub，提供他们的官网形象(https://hub.docker.com/_/mysql)，但这不是咱们Oracle的MySQL团队所反对的官网MySQL镜像。在Docker Hub（[1]，[2]，[3]）呈现问题之前，MySQL的实在官网镜像也在这里提供：https://hub.docker.com/r/mysql/mysql-server/. 你看到了吗，没有更新，最初一次可用的更新是2023年1月的8.0.32。 因而，如果您正在寻找MySQL的最新官网反对版本，包含Innovation Release，您能够在Oracle Container Registry中找到它们：(https://container-registry.oracle.com/),如下图： MySQL社区版本装置配置办法：https://container-registry.oracle.com/ords/f?p=113:4:80484266...,AI_REPOSITORY,AI_REPOSITORY_NAME,P4_REPOSITORY_NAME,P4_EULA_ID,P4_BUSINESS_AREA_ID:2,2,MySQL%20Server%20Community%20Edition,MySQL%20Server%20Community%20Edition,1,0&cs=3-68MX-MKcGbaKIcT0U6LfvuPlOBZFa3seqMWLWiCRELGPWpMbS_viSGHPhsclX-QuNpaVRHLvUKZuQ04IYFMQQ如下图： Oracle容器注册表包含所有Oracle产品（如Java、Oracle Linux和MySQL）的容器映像。 如果你正在寻找MySQL容器映像，你晓得在哪里能够找到它。 转载于The Oracle MySQL Blog:https://blogs.oracle.com/mysql/post/where-to-find-official-my...

上篇文章提到，InnoDb默认应用B+树作为索引存储构造。然而有时候就会呈现一种状况：明明在字段上增加了索引，但却并未失效。 本篇则用实例来讲述一下mysql索引生效的状况。 咱们先创立一个表：有 username、age、address 等字段, 并且建设了 (username)、(age,address)等字段 CREATE TABLE t_user ( id INT AUTO_INCREMENT PRIMARY KEY, age INT, username VARCHAR(255), address VARCHAR(255), INDEX idx_username (username), INDEX idx_age_address (age, address));再插入几条数据: INSERT INTO t_user (age, username, address)VALUES(25, 'person1', '北京'),(30, 'person2', '上海'),(22, 'person3', '广州'),(28, 'person4', '深圳'),(35, 'person5', '成都'),(40, 'person6', '重庆'),(29, 'person7', '杭州'),(26, 'person8', '武汉'),(31, 'person9', '南京'),(27, 'person10', '西安'); 如何理解 select 语句是否走了索引呢？咱们能够应用 explain 语句。 explain select * from t_user where id = 1;当 key 不为null时，代表走了索引。 ...

一、下载(已提供安装包，不须要下载)点开上面的链接：https://dev.mysql.com/downloads/mysql/ 点击Download 就能够下载对应的安装包了, 安装包如下: 二、解压下载实现后咱们失去的是一个压缩包，将其解压，咱们就能够失去MySQL 8.0.31 的软件本体了(就是一个文件夹)，咱们能够把它放在你想装置的地位 。 三、配置1. 增加环境变量环境变量外面有很多选项，这里咱们只用到Path这个参数。为什么在初始化的开始要增加环境变量呢？ 在黑框(即CMD)中输出一个可执行程序的名字，Windows会先在环境变量中的Path所指的门路中寻找一遍，如果找到了就间接执行，没找到就在当前工作目录找，如果还没找到，就报错。咱们增加环境变量的目标就是可能在任意一个黑框间接调用MySQL中的相干程序而不必总是批改工作目录，大大简化了操作。 右键此电脑→属性，点击高级零碎设置 点击环境变量 在零碎变量中新建MYSQL_HOME 在零碎变量中找到并双击Path 点击新建 最初点击确定。 如何验证是否增加胜利？ 右键开始菜单(就是屏幕左下角)，抉择命令提示符(管理员)，关上黑框，敲入mysql，回车。 如果提醒Can't connect to MySQL server on 'localhost'则证实增加胜利； 如果提醒mysql不是外部或外部命令，也不是可运行的程序或批处理文件则示意增加增加失败，请从新查看步骤并重试。 2. 初始化MySQL==以管理员身份，运行命令行窗口：== 在方才的命令行中，输出如下的指令： mysqld --initialize-insecure 略微期待一会，如果呈现没有呈现报错信息，则证实data目录初始化没有问题，此时再查看MySQL目录下曾经有data目录生成。 tips：如果呈现如下谬误 是因为权限有余导致的，以管理员形式运行 cmd 3. 注册MySQL服务命令行（留神必须以管理员身份启动）中，输出如下的指令，回车执行： mysqld -install 当初你的计算机上曾经装置好了MySQL服务了。 4. 启动MySQL服务在黑框里敲入net start mysql，回车。 net start mysql // 启动mysql服务 net stop mysql // 进行mysql服务 5. 批改默认账户明码在黑框里敲入mysqladmin -u root password 1234，这里的1234就是指默认管理员(即root账户)的明码，能够自行批改成你喜爱的。 ...

MySQL 的两阶段提交 + WAL技术（Write-Ahead Logging，先写日志再写盘），这两个联合在一起保障了数据不会失落。 binlog 的写入机制1、事务执行过程中，先把日志写到 binlog cache，事务提交的时候，再把 binlog cache 写到 binlog 文件中。 2、一个事务的 binlog 是不能被拆开的，因而不管这个事务多大，也要确保一次性写入。 3、零碎给每个线程调配了一片 binlog cache 内存，参数 binlog_cache_size 用于管制单个线程内 binlog cache 所占内存的大小。如果超过了这个大小，就要暂存到磁盘。 4、事务提交的时候，执行器把 binlog cache 里的残缺事务写入到 binlog 中，并清空 binlog cache。 5、每个线程有本人 binlog cache，然而共用同一份 binlog 文件。 6、下图中的 write, 将日志写入到文件系统的 page cache，在内存中，所以速度很快；fsync 将数据长久化到磁盘，占用磁盘 IOPS。 参数 sync_binlog sync_binlog = 0, 示意每次提交事务都只 write ，不 fsync。（不举荐）sync_binlog = 1, 示意每次提交事务都会执行 fsync（这个配置是最平安的，不会丢binlog日志）sync_binlog = N(N > 1), 示意每次提交事务都只 write，但累计 N 个事务后才 fsync。IO 瓶颈的场景中，将 sync_binlog 设置成一个较大的值，能够晋升性能。然而对应危险就是，如果主机异样重启，会失落最近 N 个事务的 binlog 日志。 ...

以下内容是依据玖章算术CEO叶正盛在「3306 数据库朋友圈」技术演讲整顿。文末附残缺的PPT下载链接！MySQL与PostgreSQL都是十分优良并且十分胜利的数据库，PostgreSQL的性能比MySQL弱小，然而仍然没有MySQL风行，作者从产品性能、技术架构、生态、品牌商业几方面来剖析起因。 影响产品倒退的因素 依据搜索引擎指数统计，过来1年Google Trends（寰球）显示MySQL关键字网页搜寻是PostgreSQL的1.5倍，百度指数（中国）显示MySQL是PostgreSQL的4.2倍。 依据云厂商调研数据，寰球MySQL用量大略是PostgreSQL的3倍，中国大略是15倍（备注，云厂商数据统计口径比拟多，仅供参考）。 DB-Engines从2013年开始对寰球数据库风行度做跟踪，每个月从搜索引擎(Google)、社区问答(Stack overflow，DBA Stack Exchange)、企业招聘岗位(Indeed，Simply hired)、个人资料(Linkedin)、社区话题（Twitter）等渠道采集数据并做加权计分，在行业里有很高权威性。从2023年9月份的数据看，MySQL以1111分排名第2，PostgreSQL以621分排名第4。 1、PostgreSQL没有MySQL风行的10个起因综合来看，MySQL比PostgreSQL都具备更高的风行度，然而PostgreSQL在产品性能方面是公认的开源畛域No.1。为什么功能强大的PostgreSQL没有MySQL风行，作者总结了以下10个起因。 (总结）功能强大的PostgreSQL没有MysQL风行的10个起因 从产品功能分析，尽管MySQL没有PostgreSQL功能强大，然而MySQL基于线程模型+读写拆散计划，在晚期互联网衰亡时LAMP（Linux+Apache+MySQL+PHP）是十分风行的解决方案。晚期（2000~2010）MySQL更多应用在新闻、论坛等互联网场景，随着InnoDB存储引擎的成熟，MySQL在事务处理方面也全面加强，开始在互联网交易畛域全面开花，如阿里巴巴应用MySQL全面完成了去IOE，京东、携程也从Oracle/SQLServer转到了分布式MySQL架构。PostgreSQL因为是过程模型，与PHP这类没有内置连接池的语言较难配合，在高并发的互联网场景不如MySQL有扩大劣势，并且大型互联网公司在分库分表后SQL语句广泛较简略，PostgreSQL不能体现出竞争力。 从公司和品牌察看，MySQL长期有主体公司（MySQL AB/SUN/Oracle）推动，并且基于GPL开源协定（GPL宗旨是第三方如果批改源码再公布须要回馈到骨干或者开源），能够更好聚合社区回馈造成品牌效应，PostgreSQL的没有相对的主体商业公司驱动，加上宽松的类BSD/MIT协定，PostgreSQL有很多分支，性能并没有回馈到骨干，导致社区品牌效应没有MySQL聚力。 MySQL的易用性十分好，出世就反对Windows/Linux，MySQL的玲珑灵便，简略易用（limit分页、show语法等等），取得了很多开发者的青睐，容易造成人才劣势，人才技能会很大影响着软件架构选型。PostgreSQL晚期只反对Linux，直到8.0才反对Windows，它在代码构造与数据库规范实现方面是榜样，是学术畛域的最爱，然而学术研究相比工业利用的人群少很多，实际胜利案例不如MySQL丰盛。 MySQL在中国风行度是寰球最高，很大起因来自于新浪、网易、搜狐、百度、腾讯等公司晚期应用PHP+MySQL的实际，再加上阿里巴巴胜利通过Java+MySQL实现去IOE的标杆案例，让MySQL在中国全面压倒性超过PostgreSQL。题外话：MySQL在英文含意与发音方面相比PostgreSQL简洁，对于公众品牌心智来说有些许劣势。 数据库是十分外围的根底软件，生产应用后替换的老本很高，即便当初看PostgreSQL在性能上更当先，然而在稳定性方面没有失去大规模的验证、人才储备有余的状况下，要替换现有零碎是高风险的事件。Uber已经就因为应用PostgreSQL遇到很多问题，而后全副迁徙到MySQL。 2、数据库在次要业务场景的竞争力剖析和瞻望 数据库在次要业务场景竞争力 在互联网畛域，MySQL有相对的影响力，然而咱们也看到PostgreSQL在GIS(地理信息系统）畛域十分弱小，PostGIS是PostgreSQL面向GIS畛域的业余插件，简直成为GIS畛域的规范解决方案。 市场需求与趋势（国内） PostgreSQL曾经错失了互联网时机，不过它反对更简单的SQL，HTAP能力也更加杰出，适宜利用于企业级软件畛域（ERP、CRM、BOSS等等）。但随着中国的信创产业倒退迅速，PostgreSQL宽松的BSD开源协定，很多厂商基于PostgreSQL倒退出了新型国产数据库，提供更好的服务反对，信创波及到大量零碎替换，这可能会是PostgreSQL在中国迎来新的倒退机会。另外PostgreSQL的pgVector插件能够反对根底的向量数据库性能，在赶上了明天ChatGPT引领的大模型AI时代风口。 产品与技术总是在不停的提高，MySQL与PostgreSQL的选型还会是继续争执的话题，MySQL依附互联网有先发劣势，并且人才丰盛，以后在互联网畛域还会是首选，然而因为MySQL对简单SQL反对有余，在企业级软件畛域PostgreSQL会更有后劲。尽管国内Oracle、DB2这些企业级数据库都将远去，然而咱们看见达梦、OceanBase等自研数据库在飞速发展，PostgreSQL还会面临新一轮的竞争。 本文更多是作者的经验总结与思考，也查阅了大量的材料，以下是局部参考资料： https://dev.mysql.com/doc/refman/8.0/en/what-is-mysql.htmlhttps://www.postgresql.org/docs/16/index.htmlhttps://survey.stackoverflow.co/2023/#most-popular-technologi...https://www.toutiao.com/article/6824292543253971459/https://www.uber.com/en-TW/blog/postgres-to-mysql-migration/https://db-engines.com/en/rankinghttps://www.modb.pro/dbRank3、作者简介 叶正盛，玖章算术CEO，NineData程序员（https://www.ninedata.cloud/），原阿里云数据库产品治理与解决方案部总经理，资深技术专家，是阿里巴巴去IOE、异地多活、云原生数据库等我的项目核心成员。 ▶︎ 附注2个数据库分类和市场大图 数据库系统分类大图 国内数据库市场特色大图 如要下载残缺的PPT，请关注NineData公众号，回复「NineData」，间接支付。

作者通过一个死锁案例联合OPTIMIZER TRACE，对 MySQL 5.7 的索引成本计算、索引抉择以及 ICP 个性进行了剖析。 作者：李锡超，一个爱笑的江苏苏宁银行 数据库工程师，次要负责数据库日常运维、自动化建设、DMP 平台运维。善于 MySQL、Python、Oracle，喜好骑行、钻研技术。 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文约 2100 字，预计浏览须要 7 分钟。 问题景象自公布了 INSERT 并发死锁问题的文章，收到了屡次死锁问题的交换。一个具体案例如下： 研发反馈利用产生死锁，收集如下诊断内容： >以上 `space id 603 page no 86 n bits 248`，其中 `space id` 示意表空间 ID，`page no` 示意记录锁在表空间内的哪一页，`n bits` 是锁位图中的位数，而不是页面偏移量。记录的页偏移量个别以 `heap no` 的模式输入，但此例并未输入该信息。## 根本环境信息确认如下问题相干信息：- 数据库版本：Percona MySQL 5.7- 事务隔离级别：Read-Commited- 表构造和索引：要害信息梳理 事务 T1语句delete from ltb2 where c = 'code001' and j = 'Y15' and b >= '20230717' and d != '1' and e != '1'关联对象及记录space id 603 page no 86 n bits 248 index PRIMARY of table testdb.ltb2持有的锁未知期待的锁lock_mode X locks rec but not gap waiting 事务 T2语句update ltb2 set f = '0', g = '0', is_value_date = '0', h = '0', i = '0' where c = '22115001B' and j = 'Y4' and b >= '20230717'关联对象及记录space id 603 page no 86 n bits 248 index PRIMARY of table testdb.ltb2持有的锁lock_mode X locks rec but not gap期待的锁lock_mode X locks rec but not gap waiting能够看到在主键索引上产生了死锁，然而在查问的条件中，并未应用主键列。 ...

咱们在上篇 高性能MySQL实战（一）：表构造 中曾经建设好了表构造，这篇咱们则是针对已有的表构造和搜寻条件为表创立索引。 1. 依据搜寻条件创立索引咱们还是先将表构造的初始化 SQL 拿过去： CREATE TABLE `service_log` ( `id` bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键', `service_type` smallint NOT NULL DEFAULT -1 COMMENT '接口类型', `service_name` varchar(30) DEFAULT '' COMMENT '接口名称', `service_method` tinyint NOT NULL DEFAULT -1 COMMENT '接口方式 1-HTTP 2-TCP', `serial_no` int DEFAULT -1 COMMENT '音讯序号', `service_caller` tinyint DEFAULT -1 COMMENT '调用方', `service_receiver` tinyint DEFAULT -1 COMMENT '接管方', `status` tinyint DEFAULT 10 COMMENT '状态 10-胜利 20-异样', `error_message` varchar(200) DEFAULT '' COMMENT '异样信息', `message` varchinar(1000) DEFAULT '' COMMENT '报文内容', `create_user` varchar(50) DEFAULT '' COMMENT '创建者', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创立工夫', `update_user` varchar(50) DEFAULT '' COMMENT '更新者', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '更新工夫', `is_delete` tinyint NOT NULL DEFAULT 0 COMMENT '刪除标记', `ts` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '工夫戳', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='接口调用日志';现有如下搜寻条件： ...

在咱们对数据库技术方案设计的时候，咱们是否有本人的设计理念或者准则，还是更多的根据本人的直觉去设计，是否已经后悔线上产生过的一次低级故障，可能略微留神点就能够防止，是否想过怎么能力很好的防止，上面标准的价值正是咱们工作的查看清单，须要咱们一直从谬误中积攒无效教训来领导将来的工作。以下标准在大型互联网公司通过了充沛的验证，尤其实用于并发量大、数据量大的业务场景。先介绍的是平安标准，因为平安无小事，很多公司都已经因为本人的数据泄露导致用户的惨痛损失，所以将平安标准放到了第一位。 一、平安标准1.【强制】禁止在数据库中存储明文明码，需把明码加密后存储阐明：对于加密操作倡议由公司的中间件团队基于如mybatis的扩大，提供对立的加密算法及密钥治理，防止每个业务线独自开发一套，同时也与具体的业务进行理解耦 2.【强制】禁止在数据库中明文存储用户敏感信息，如手机号等阐明：对于手机号倡议公司搭建对立的手机号查问服务，防止在每个业务线独自存储 3.【强制】禁止开发间接给业务同学导出或者查问波及到用户敏感信息的数据，如须要需上级领导审批 4.【强制】波及到导出数据性能的操作，如蕴含敏感字段都需加密或脱敏 5.【强制】跟数据库交互波及的敏感数据操作都需有审计日志，必要时要做告警 6.【强制】对连贯数据库的IP需设置白名单性能，杜绝非法IP接入 7.【强制】对重要sql（如订单信息的查问）的拜访频率或次数要做历史趋势监控，及时发现异常行为 8.【举荐】线上连贯数据库的用户名、明码倡议定期进行更换 二、根底标准1.【举荐】尽量不在数据库做运算，简单运算需移到业务利用里实现 2.【举荐】回绝大sql语句、回绝大事务、回绝大批量，可转化到业务端实现 阐明：大批量操作可能会造成重大的主从提早，binlog日志为row格局会产生大量的日志 3.【举荐】防止应用存储过程、触发器、函数等，容易造成业务逻辑与DB耦合 阐明：数据库善于存储与索引、要解放数据库CPU，将计算转移到服务层、也具备更好的扩展性4.【强制】数据表、数据字段必须退出中文正文 阐明：后续保护的同学看到后才分明表是干什么用的 5.【强制】不在数据库中存储图片、文件等大数据 阐明：大文件和图片须要储在文件系统 6.【举荐】对于程序连贯数据库账号，遵循权限最小准则 7.【举荐】数据库设计时，须要问下本人是否对当前的扩展性进行了思考 8.【举荐】利用 pt-query-digest 定期剖析slow query log并进行优化 9.【举荐】应用内网域名而不是ip连贯数据库 10.【举荐】如果数据量或数据增长在后期布局时就较大，那么在设计评审时就应退出分表策略 11.【举荐】要求所有研发SQL关键字全副是小写，每个词只容许有一个空格 三、命名标准1.【强制】库名、表名、字段名要小写，下划线格调，不超过32个字符，必须见名知意，倡议应用名词而不是动词，词义与业务、产品线等相关联，禁止拼音英文混用 2.【强制】一般索引命名格局：idx_表名_索引字段名（如果以首个字段名为索引有多个，能够加上第二个字段名，太长能够思考缩写），惟一索引命名格局：uk_表名_索引字段名（索引名必须全副小写，长度太长能够利用缩写），主键索引命名：pk_ 字段名 3.【强制】库名、表名、字段名禁止应用MySQL保留字 4.【强制】长期库表名必须以tmp为前缀，并以日期为后缀 5.【强制】备份库表必须以bak为前缀，并以日期为后缀 6.【举荐】用HASH进行散表，表名后缀应用16进制数，下标从0开始 7.【举荐】按日期工夫分表需合乎YYYYMM[HH]格局 8.【举荐】散表如果应用md5（或者相似的hash算法）进行散表，表名后缀应用16进制，比方user_ff 9.【举荐】应用CRC32求余（或者相似的算术算法）进行散表，表名后缀应用数字，数字必须从0开始并等宽，比方散100张表，后缀从00-99 10.【举荐】应用工夫散表，表名后缀必须应用特定格局，比方按日散表user_20110209、按月散表user_201102 11.【强制】表白是与否概念的字段，应用 is _ xxx 的形式进行命名 四、库设计规范1.【举荐】数据库应用InnoDB存储引擎 阐明：反对事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高 2.【举荐】数据库和表的字符集对立应用UTF8 阐明：utf8号称万国码，其无需转码、无乱码危险且节俭空间。若是有字段须要存储emoji表情之类的，则将表或字段设置成utf8mb4，utf8mb4向下兼容utf8。 3.【举荐】不同业务，应用不同的数据库，防止相互影响 4.【强制】所有线上业务库均必须搭建MHA高可用架构，防止单点问题 五、表设计规范1.【举荐】建表标准示例 CREATE TABLE `student_info` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键', `stu_name` varchar(10) NOT NULL DEFAULT '' COMMENT '姓名', `stu_score` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT '总分', `stu_num` int(11) NOT NULL COMMENT '学号', `gmt_create` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创立工夫', `gmt_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新工夫', `status` tinyint(4) DEFAULT '1' COMMENT '1代表记录无效，0代表记录有效', PRIMARY KEY (`id`), UNIQUE KEY `uk_student_info_stu_num` (`stu_num`) USING BTREE, KEY `idx_student_info_stu_name` (`stu_name`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='学生信息表';2.【强制】禁止应用外键，如果有外键完整性束缚，须要利用程序控制 ...

欢送大家围观小阑精心整顿的API平安最新资讯，在这里你能看到最业余、最前沿的API平安技术和产业资讯，咱们提供对于寰球API平安资讯与信息安全深度察看。本周，咱们带来的分享如下：一篇对于Jetpack WordPress插件存在API破绽的文章一篇对于如何应答一直增长的API安全漏洞的文章一篇对于API安全性是事不宜迟的文章工具：应用Burp Suite查找GraphQL破绽 Jetpack WordPress插件API破绽影响数百万个网站风行的WordPress插件Jetpack强制对所有装置进行更新，以解决插件中的一个要害API破绽。该插件在WordPress用户中十分受欢迎，寰球下载量超过500万次。自2012年首次公布2.0版以来，所有版本都存在这个破绽。Jetpack的官网布告中对这个破绽的性质提供的细节很少，只是指出它影响到一个API，并可能容许对受影响主机的文件系统进行拜访。文章列出了所有受影响的版本，但坚称目前没有已知的对该破绽的利用。用户被要求确保他们正在应用最新的插件版本，即Jetpack 12.1.1。小阑总结：这个破绽对于受影响的WordPress站点来说是十分危险的，因为它可能容许攻击者利用API破绽，从而拜访站点上的文件系统。如果攻打胜利，攻击者能够读取、批改或删除站点上的数据。这可能导致站点解体、数据泄露或损坏，对站点和其用户造成极大的损失。为了预防这个破绽，所有应用Jetpack插件的WordPress站点都应该尽快更新到最新版本Jetpack 12.1.1。此外，站点管理员还应该遵循良好的平安实际，如装置平安插件，设置强明码和多因素身份验证，以及定期备份站点数据以应答意外状况。此外，站点管理员还应该保持警惕，防止关上或下载来自未知起源的文件和链接，以缩小站点蒙受攻打的危险。 翻新爱护：2023年应答API安全漏洞的前沿策略在本周探讨API平安挑战的两篇文章中的第一篇中，介绍了Katrina Thompson的想法。作者强调了API在构建当今数字基础设施方面的重要性。可怜的是，这减少了攻击者的危险，他们意识到API在攻打组织时代表了“最佳点”。依据这篇文章，最近的一项钻研表明，97%的企业领导者将API的应用归类为对将来增长至关重要，另一项钻研表明，应用API的均匀数量比去年增长了82%。笔者指出了五种类型的API安全漏洞，并提出了解决办法，具体如下：过于宽松的API：API常常能够拜访比它们应该拜访的更多的数据，并且通常以比它们应该更高的权限执行。API应被授予执行其业务指标所需的最低权限。代码中的谬误：正如读者所知，许多API破绽是因为代码库中的缺点造成的，导致BOLA、BFLA和身份验证中断等破绽。始终确保扫描API代码库以查找破绽，并在任何重大更改时手动审查。速度超过平安：与API代码中的谬误主题相结合的是偏爱速度而不是安全性的主题。在许多状况下，业务需要往往占主导地位，API团队在充沛验证安全性之前公布API。这会导致生产中代价昂扬的中断，包含低廉的修补程序和返工。在开发的晚期阶段解决平安问题要无效得多。公开和暗藏的API：时事通信的读者相熟影子和僵尸API给平安团队带来的问题。如果您不晓得本人领有和操作的API，则无奈爱护。每个API都是惟一的：确保您理解爱护每个 API 的特定需要，因为它们可能具备十分不同的特色和平安要求。小阑解读：要防止API破绽并进步防范措施：及时更新API：确保你应用的所有插件、库和框架的API都是最新版本。施行受权和访问控制：限度API的拜访仅限于通过受权和验证的用户或应用程序，应用令牌、密钥或其余访问控制机制，确保只有非法用户能力应用API。输出验证和过滤：在解决API申请时，对输出数据进行严格的验证和过滤，确保输出数据合乎预期格局和类型，以避免歹意数据注入或其余平安威逼。强化身份验证：为API拜访施行弱小的身份验证机制，如多因素身份验证、OAuth等，避免未经受权的拜访和歹意流动。监控和日志记录：实时监控API的应用状况，并记录重要操作和事件，这样能够疾速检测异样行为并采取适当的响应措施。平安审计和代码审查：进行定期的平安审计和代码审查，查看潜在的破绽和安全隐患；修复发现的问题，并确保API的代码品质和安全性。平安培训和意识：提供平安培训，教育开发人员、管理员和用户无关API平安最佳实际和常见攻击方式，加强安全意识，及时辨认和应答平安威逼。 以后最紧迫的工作：确保API的安全性这一篇文章将介绍印度CIO.com和Indiatimes.com上多位平安专家的见解。寰球信息安全和网络安全主管Nikhil Chawla认为，人员和威逼给API平安带来了许多挑战。在许多状况下，开发人员没有充沛意识到对API可能带来的威逼，漠视了重要的主题，如速率限度、DDoS攻打和跨站脚本攻打。通过更好地了解这些问题，他们能够在爱护API方面获得更大胜利。CSB银行有限公司首席信息安全官巴比塔·B·P重点关注API可见性这一重要话题。在大规模确保API平安方面，要害是确保以自动化形式监控API，并尽量减少对手动发现和审计API的依赖。Radware云平安服务销售总监Navneet Daga总结道，进步API安全性须要平安和开发团队之间增强合作，API安全性不是一个单点解决方案，而是须要分层策略进行深度进攻。小阑倡议：API在古代应用程序中起着关键作用，其安全性的重要性不容忽视：数据保护：API作为不同应用程序之间的桥梁，承载着大量敏感数据的传输和替换。确保API的安全性能够预防数据泄露、篡改或未经受权的拜访，爱护用户和组织的重要信息。业务连续性：许多企业和组织依赖于API来提供外围服务和性能，如果API存在破绽或受到攻打，可能导致系统解体、服务中断或无奈失常运行，对业务造成重大影响。用户隐衷爱护：API通常须要与用户进行交互，波及到用户个人信息的解决和存储，确保API的安全性能够避免用户隐衷泄露和滥用，加强用户对产品和服务的信任感。避免歹意攻打：歹意攻击者经常利用API的弱点进行攻打，例如通过API暴力破解明码、注入恶意代码或发动拒绝服务攻打；增强API安全性能够缩小潜在的攻击面，进步零碎的抵挡能力。合规要求：许多行业和法规对数据的安全性和隐衷爱护有严格的要求，例如金融、医疗和集体信息管理畛域，放弃API的安全性是满足合规要求的重要一步。 应用Burp Suite查找GraphQL破绽Port Swigger提供了一个对于应用他们的Burp Suite工具来辨认GraphQL破绽。利用 GraphQL API 的第一步是发现端点。这能够应用Burp Suite手动实现，也能够通过将通用查问发送到常见的GrahpQL API端点来实现，如下所示：/graphql/api/api/graphql/graphql/api/graphql/graphql确定终结点后，能够确定终结点反对的不同申请办法，包含反对的数据类型。下一步是辨认未经污染的参数，并发现通过这些参数注入歹意内容的不同办法。通过发现架构信息，能够深刻理解 API 的构造，并容许攻击者深刻理解如何进一步攻打 API。Burp Suite还提供了一个扩大，能够主动执行大部分发现过程，这是风行的扩大。InQL是一个Burp Suite扩大，可帮忙您平安地审核GraphQL API。它收回一个内省查问，申请给定 URL 的所有查问和渐变（通过指向实时终结点的链接或通过 JSON 文件），并提供结构化视图以帮忙您浏览后果。从平安角度来看，文章最初提出了一些爱护GraphQL API 的有用倡议：在API终端节点上禁用侦测，除非有明确且易于了解的理由来启用它，这能够避免攻击者理解终结点的工作原理。查看API的架构，确保它不会向公众公开意外字段。确保禁用倡议，以避免攻击者应用工具收集无关基础架构的信息。确保您的API架构不会公开公有用户字段，例如PII等信息。感激 APIsecurity.io 提供相干内容对于星阑星阑科技基于大数据分析及AI智能化技术体系，助力企业应答数字世界的平安危险。凭借继续翻新的平安理念和成果导向的攻防能力，星阑科技倒退成为国内数据智能、信息安全畛域的双料科技公司。为解决流动数据安全问题，星阑科技从数据攻防、数据分析、数据治理等不同场景登程，提供全景化数据流转监测、利用数据分析、API平安治理、高级威逼检测等解决方案，构建全链路流动数据保护体系。星阑科技外围产品——萤火流动数据分析平台，可针对用户异构、多模态数据提供危险监测、合规性治理、数据建模、用户追踪、行为关联、AI解释与推理等一体化数据分析能力，为企业的数据可观测性、数据合规、威逼监测、利用治理、业务洞察等场景提供全面反对。

　在容器化的时代，当然所有皆可容器化。在docker官网首页赫然有上面这几个大字。足以晓得docker的劣势。那么且问，mysql适宜跑在docker中吗?　当然，这个问题有人说能够，也有人说不能够。上面咱们就正反都来看下各自的观点。　1. 不能够容器化　大部分人的理由有两个：　其一，数据安全性不能保障　在容器或者docker呈现故障时，不易复原。即便应用数据卷挂载（volume）也会在容器故障时产生数据问题，共享的数据卷且对宿主机也会有伤害。即数据的长久化和完整性不能保障。docker适宜无状态的服务，不适宜有数据状态的mysql。　其二，影响mysql性能　mysql咱们罕用来读写，那么IO性能就会受docker影响，最终瓶颈呈现在写（在做了挂载状况下）；且如果物理机其余利用占用过多资源，也会影响到容器。　当然，以上的问题，也都有对应的解决方案，但时也足够简单；对研发力量有余的企业来说，如果自觉容器化的话，可能会捡了芝麻，丢了西瓜。　2. 能够容器化　有的小伙伴就会说了，同样是服务，业务服务都是跑在docker中的，数据库服务有何不可？　我只有配置下数据卷挂载，解决掉数据长久化问题，基本上就问题不大了。　比方： docker run -p 3306:3306 --name mysql -v /mydata/mysql/log:/var/log/mysql -v /mydata/mysql/data:/var/lib/mysql -v /mydata/mysql/conf:/etc/mysql-e TZ=Asia/Shanghai -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7　亦或是docker官网给的mysql容器化的配置sample services: backend: build: backend ports: - 8080:8080 secrets: - db-password db: # We use a mariadb image which supports both amd64 & arm64 architecture image: mariadb:10.6.4-focal # If you really want to use MySQL, uncomment the following line #image: mysql:8.0.27 restart: always secrets: - db-password volumes: - db-data:/var/lib/mysql environment: - MYSQL_DATABASE=example - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/db-password expose: - 3306 - 33060 volumes: db-data:secrets: db-password: file: db/password.txt　两个例子都是通过-v把mysql相干目录数据做好挂载，那么在容器呈现故障或者被删除时，可能保障相干数据在宿主机中存在。让数据恢复成为了可能性。留神！是可能性　当然还有docker人造的劣势：　...

本文剖析了 INSERT 及其变种（REPLACE/INSERT ON DUPLICATE KEY UPDATE）的几个场景的死锁及如何防止。 作者：张洛丹，DBA 数据库技术爱好者~ 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文共 3200 字，预计浏览须要 10 分钟。 说在后面本文剖析了 INSERT 及其变种（REPLACE/INSERT ON DUPLICATE KEY UPDATE）的几个场景的死锁及如何防止： 场景一：INSERT 惟一键抵触场景二/三：REPLACE INTO 惟一键抵触（来自线上业务）场景四：INSERT 主键抵触（来自官网案例）其实 Google 一番，也会有大量这样的文章。本文只是就几个场景进行了剖析，不过一遍走下来，对 INSERT 加锁状况、如何导致的死锁也就把握了，集体能力无限，如文中内容有谬误和纰漏，也欢送大佬指出。 有趣味的就持续往下看吧~ 回顾行锁在此之前，先浅浅回顾一下 InnoDB 中的行锁类型。 记录锁（RECORD LOCK）对索引记录加锁。 间隙锁（GAP LOCK，也叫范畴锁）对索引记录的所在间隙加锁，在 RR 隔离级别下，用于解决幻读的问题（实际上在 RC 隔离级别下，也会产生间隙锁）。 S 间隙锁和 X 间隙锁是兼容的，不同的事务能够在同一个间隙加锁。 NEXT-KEY 锁相当于 RECORD LOCK + GAP LOCK。 插入意向锁（INSERT INTENTION LOCK）GAP 锁的一种，在执行 INSERT 前，如果待插入记录的下一条记录上被加了 GAP 锁，则 INSERT 语句被阻塞，且生成一个插入意向锁。 仅会被 GAP 锁阻塞。 隐式锁新插入的记录，不生成锁构造，但因为事务 ID 的存在，相当于加了隐式锁；别的事务要对这条记录加锁前，先帮忙其生成一个锁构造，而后再进入期待状态。 ...

在上篇「快、准、稳的实现亿级别MySQL大表迁徙」的文章中，介绍了NineData在单张大表场景下的迁徙性能和劣势。但在大部分场景中，可能遇到的是多张表形成的大数据量场景下的数据搬迁问题。因为搬迁数据量较大，迁徙的时长、稳定性及准确性都受到极大的挑战，常见的迁徙工具通常不能很好得反对。为此，NineData针对这种场景专门进行针对性的优化，以提供高效、精确、稳固的大数据量迁徙能力。 1、传统的迁徙计划目前，数据迁徙次要分为逻辑迁徙和物理迁徙，逻辑迁徙次要有mysqldump、mydumper ，物理迁徙次要有XtraBackup。对于这类导入导出和拷贝文件的传统迁徙计划，在迁徙中会存在一些问题： 要求业务停机，在迁徙过程中，通过须要进行服务，放弃动态迁徙数据，因为迁徙数据量大，须要的迁徙工夫较长，这也意味着业务停机工夫较长。迁徙工夫久，对于mysqldump的逻辑迁徙，单线程导出表，迁徙工夫长。可靠性差，导出异样后，不反对断点能力，在迁徙过程中，如果遇到数据库、软件或硬件任何问题导致的工作中断，都须要从头迁徙，迁徙难度高。保障能力弱，迁徙期间，不能提供欠缺的观测跟干涉能力；同时，比拟不足构造及数据比照能力，不足品质保障体系，可能影响迁徙胜利性。2、高性能的迁徙计划NineData 提供的数据复制同时蕴含了数据迁徙和数据同步的能力，在不影响业务的前提下，提供了高效、稳固、可运维的大数据量迁徙能力。经实测，在源及指标实例同城状况下，500GB的mysql数据的迁徙，只需1个小时，均匀迁徙速度142MB/s。 通过对 MySQL 大数据量迁徙的性能测试，和传统迁徙比，NineData 数据迁徙的劣势有： 简略易用： 一分钟即可实现工作配置，并全自动化实现工作迁徙。强劲性能： 欠缺的智能分片、表级行级并发、动静攒批等核心技术，无效保障迁徙性能。高牢靠： 联合新型断点、异样诊断及丰盛的修复伎俩，对于迁徙过程中可能呈现软硬件故障，提供欠缺的容灾能力，大大提高了大数据量迁徙的成功率。数据品质保障： NineData 还提供了比照性能，蕴含数据和构造的比照，以及全量、疾速（抽样）和不统一复检的比照形式，并且也反对不同的比照频率。在迁徙或复制完结后，通过数据和构造比照，能无效的保障数据的一致性。NineData 在提供弱小迁徙能力的同时，也保障了应用的简略性，只须要1分钟就能实现迁徙工作的配置，实现齐全自动化的数据迁徙过程。上面咱们来看下整个工作的配置过程： 2.1 配置迁徙链路 配置工作名称，抉择要迁徙的源和指标实例。抉择复制类型，数据迁徙抉择构造和全量复制（数据迁徙）。依据须要，抉择适合的抵触解决策略。2.2 抉择迁徙对象 抉择迁徙对象：针对不同粒度抉择迁徙对象，也能够抉择局部迁徙对象。 2.3 配置映射对象 配置映射和过滤规定：可自定义迁徙的库名、表名和依照不同的过滤条件进行多表的局部数据迁徙，也能够针对表的列名进行映射和局部列迁徙。 2.4 预查看&启动 通过丰盛的查看项，保障了迁徙工作的稳定性；通过开启数据比照，保障了迁徙后数据的一致性。到此，咱们就实现了一个高性能迁徙工作的配置。 同时，为了提供更好的迁徙体验，NineData针对迁徙过程提供了欠缺的观测、干涉能力。其岂但提供对象迁徙的具体状态、停顿、详情，还通过监控和日志走漏后盾线程的外部执行状况，帮忙用户全方位追踪迁徙停顿。同时，还针对运行过程中可能呈现的异常情况，提供根底诊断能力，及修复、跳过、移除等多种修复策略和迁徙限流能力，让用户可能自主疾速得诊断并修复链路，保障迁徙稳定性。 3、总结NineData 提供的高效、疾速、稳固的MySQL大数据量迁徙能力，很好的补充了传统迁徙计划的有余。以后，NineData 曾经反对数十种常见数据库的迁徙复制，同时，除了SAAS模式外，还提供了企业专属集群模式，满足企业最高的数据安全合规要求。目前，NineData已在运营商、金融、制造业、地产、电商等多个行业实现大规模利用实际。如果您感兴趣的话，能够登录官网：数据迁徙-迁徙工具-数据传输-NineData-玖章算术，立刻开始应用。

序本文次要钻研一下mysql jdbc的prepareStatement prepareStatementjava/sql/Connection.java /** * Creates a <code>PreparedStatement</code> object for sending * parameterized SQL statements to the database. * <P> * A SQL statement with or without IN parameters can be * pre-compiled and stored in a <code>PreparedStatement</code> object. This * object can then be used to efficiently execute this statement * multiple times. * * <P><B>Note:</B> This method is optimized for handling * parametric SQL statements that benefit from precompilation. If * the driver supports precompilation, * the method <code>prepareStatement</code> will send * the statement to the database for precompilation. Some drivers * may not support precompilation. In this case, the statement may * not be sent to the database until the <code>PreparedStatement</code> * object is executed. This has no direct effect on users; however, it does * affect which methods throw certain <code>SQLException</code> objects. * <P> * Result sets created using the returned <code>PreparedStatement</code> * object will by default be type <code>TYPE_FORWARD_ONLY</code> * and have a concurrency level of <code>CONCUR_READ_ONLY</code>. * The holdability of the created result sets can be determined by * calling {@link #getHoldability}. * * @param sql an SQL statement that may contain one or more '?' IN * parameter placeholders * @return a new default <code>PreparedStatement</code> object containing the * pre-compiled SQL statement * @exception SQLException if a database access error occurs * or this method is called on a closed connection */ PreparedStatement prepareStatement(String sql) throws SQLException;java.sql.Connection定义了prepareStatement办法，依据sql创立PreparedStatementConnectionImplmysql-connector-java-5.1.21-sources.jar!/com/mysql/jdbc/ConnectionImpl.java ...

MySQL 报错 You can‘t specify target table for update in FROM clause解决办法 意思是： 更新表时，更新的条件也是从这个表查问进去的， 这是不容许的 例如，我这样写的： 就报错 update gs_work set status = '2'where id in ( select w.id from gs_work w left join gs_work_cs cs on cs.work_id= w.id where cs.cs_user_id= 1 and w.status ='1') 改成这样就能够了， 条件再加一层 update gs_work set status = '2'where id in ( select id from ( select w.id, w.cur_work from gs_work w left join gs_work_cs cs on cs.work_id= w.id where cs.cs_user_id= 1 and w.status ='1') as nw )

一个线上数据失落故障案例，引出了在 GTID 模式下 AUTO POSITION MODE 的必要性。 作者：孙绪宗 新浪微博 DBA 团队工程师，次要负责 MySQL、PostgreSQL 等关系型数据库运维。 本文起源：原创投稿 * 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 浏览前需知Retrieved_Gtid_Set：从库曾经接管到主库的事务编号（从库的 IO 线程曾经承受到了）。Executed_Gtid_Set：曾经执行的事务编号（从库的执行 SQL 线程曾经执行了的 SQL）。故障景象主从数据不统一，然而看复制是失常状态（双 Yes）。此时主库执行，从库本该报错 1062 或者 1032 的 SQL，从库复制线程还是双 Yes，没有报错。 MySQL 版本：5.7.35 故障复现查看主库状态 MySQL [xuzong]> show master status;+------------------+----------+--------------+------------------+-----------------------------------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+------------------+----------+--------------+------------------+-----------------------------------------------+| mysql-bin.000008 | 39349641 | | | c233aec0-58d3-11ec-a74a-a0a33ba8b3ff:1-104345 |+------------------+----------+--------------+------------------+-----------------------------------------------+从库上只须要设置 GTID 值的 gno 大于主库的值即可复现。 mysql> stop slave;Query OK, 0 rows affected (0.00 sec)mysql> reset slave all;Query OK, 0 rows affected (0.01 sec)mysql> reset master;Query OK, 0 rows affected (0.01 sec)mysql> set @@GLOBAL.GTID_PURGED='c233aec0-58d3-11ec-a74a-a0a33ba8b3ff:1-1000000'; #1000000>104345Query OK, 0 rows affected (0.00 sec)而后用 POSITION MODE 点位复制，启动从库，执行 show slave status \G 就会看到如下： ...

正是因为 MySQL 对字符串进行隐式转换时会截断再转，而不是像 Oracle、SQL Server 这些数据库针对这种问题间接报错，所以才呈现了这个诡异的问题。 作者：刘晨 网名 bisal ，具备十年以上的利用运维工作教训，目前次要从事数据库利用研发能力晋升和技术治理相干的工作，Oracle ACE（Alumni），腾讯云TVP，领有 Oracle OCM & OCP 、EXIN DevOps Master 、SCJP 等国内认证，国内首批 Oracle YEP 成员，OCMU 成员，《DevOps 最佳实际》中文译者之一，CSDN & ITPub 专家博主，公众号”bisal的集体杂货铺”，长期保持分享技术文章，屡次在线上和线下分享技术主题。 本文起源：原创投稿 * 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景共事问了个 MySQL 的问题，景象上的确诡异。大抵意思是 SELECT 表的数据，WHERE 条件是 "a=0"，其中 a 字段是 VARCHAR 类型，该字段存在 NULL 以及蕴含字符的记录，然而并无 "0" 的记录，而后执行 SQL 返回的记录恰好就是所有蕴含中文字符的记录。 明明没有 "0" 值记录，却能够返回，而且有法则，这是什么景象？ select * from test where a = 0;问题剖析为了比对阐明，咱们别离用 MySQL、Oracle 和 SQL Server 进行模仿。 2.1 筹备测试表三种数据库建表和插入数据的语句。 MySQLcreate table test (id int, a varchar(3000), b varchar(2000));insert into test values(1, '测试a', '测试b'),(2, NULL, '测试');Oraclecreate table test (id NUMBER(1), a varchar2(3000), b varchar2(2000));insert into test values(1, '测试a', '测试b');insert into test values(2, NULL, '测试');SQL Servercreate table test (id numeric(1,0), a varchar(3000), b varchar(2000));insert into test values(1, '测试a', '测试b');insert into test values(2, NULL, '测试');2.2 比照查问后果预期 test 表返回的记录都应该是这样的。 ...

linux 下进行环境装置绝对比较简单，可还是会遇到各种奇奇怪怪的问题，咱们来梳理一波 装置 mysql 咱们会用到下地址： Mysql 官网文档的地址，能够参考，不要全副应用https://dev.mysql.com/doc/refman/8.0/en/linux-installation-yum-repo.html 开始装置 mysql卸载默认的 mysql防止已有的 mysql 影响咱们当初要装置的 mysql yum search mysql yum remove mariadb.x86_64到 mysql 官网上下载 rpm 地址：https://dev.mysql.com/downloads/repo/yum/?from=from_parent_mi... 当然也能够间接执行如下命令，应用 wget 的形式将 rpm下载到咱们 linux 环境中，如果要下载其余版本，能够批改 rpm 的具体名称 ， 例如咱们本次应用的是 mysql57-community-release-el7-11.noarch.rpm wget https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm本地装置 mysql yum 源yum localinstall mysql查看对应的须要装置的 mysql 版本，进行装置yum search mysql yum install mysql-community-server.x86_64查看装置是否胜利ps -ef | grep mysql 启动 mysql，重启 mysql， 进行 mysqlservice mysqld start service mysqld restart service mysqld stop查找默认明码cat /var/log/mysqld.log | grep password登录 mysqlmysql -uroot -p 回车，而后输出明码 ...

全面理解 8.1.0 版本新性能：InnoDB Cluster 只读正本的相干操作。 作者：Miguel Araújo 高级软件工程师 / Kenny Gryp MySQL 产品总监 本文起源：Oracle MySQL 官网博客 * 爱可生开源社区出品。 前言MySQL 的第一个 Innovation 版本 8.1.0 曾经公布，咱们将推出 MySQL InnoDB Cluster 只读正本。 在 MySQL InnoDB Cluster 中，正本（Secondray）节点的次要目标是在主（Primary）节点产生故障时做好切换代替（高可用性）。这是由 MySQL 组复制（MGR）插件配合实现的。正本节点的另一个用处是缩小主节点的只读工作负载。 当初，能够向数据库拓扑构造中增加异步正本节点这些正本节点能够用于： 将读流量从主节点或者其余正本节点转移过去，分担它们的读压力。设置专门用于读取的正本节点。设置专门用于报表等特定目标的正本节点。通过增加多个读取正本节点，实现超出其余正本节点解决能力范畴的扩容。 MySQL InnoDB Cluster 会治理这些正本节点的操作，包含： MySQL Router 会主动从新导向流量。MySQL Shell 负责配置、首次预配（应用 InnoDB Clone 插件）。复制配置和任何想要进行的拓扑构造变更。只读正本节点也能够与 MySQL InnoDB ClusterSet 配合应用，这个模式下，正本节点能够增加到主集群或正本集群中。 MySQL Router 会辨认这些读取正本节点，并依据一些配置选项将读流量从新导向到它们。这些读取正本节点会从主节点或者其余正本节点进行复制，如果复制中断或成员变更（例如新主节点选举），它会主动从新连贯到另一个成员。 创立只读正本将读取正本节点增加到集群中和增加从节点很类似。Admin API 的外观和交互方式放弃不变，这能够确保最佳的用户体验。 假如您曾经有一个运行中的集群，能够应用新增的这个命令来增加读取正本节点： \<Cluster\>.addReplicaInstance(instance[, options]) mysqlsh-js> cluster.addReplicaInstance("rome4:3306")Setting up 'rome4:3306' as a Read Replica of Cluster 'rome'.Validating instance configuration at rome4:3306...This instance reports its own address as rome4:3306Instance configuration is suitable.* Checking transaction state of the instance...省略……* Waiting for clone to finish...NOTE: rome4:3306 is being cloned from rome1:3306** Stage DROP DATA: Completed** Clone Transfer FILE COPY ############################################################ 100% Completed PAGE COPY ############################################################ 100% Completed REDO COPY ############################################################ 100% CompletedNOTE: rome4:3306 is shutting down...* Waiting for server restart... ready * rome4:3306 has restarted, waiting for clone to finish...** Stage RESTART: Completed* Clone process has finished: 4.30 GB transferred in 4 sec (1.08 GB/s)* Configuring Read-Replica managed replication channel...** Changing replication source of rome4:3306 to rome1:3306* Waiting for Read-Replica 'rome4:3306' to synchronize with Cluster...** Transactions replicated ############################################################ 100% 'rome4:3306' successfully added as a Read-Replica of Cluster 'rome'.如此简略，一个新的正本就增加到集群中了。和一般的集群成员一样，只读正本也反对 Clone 或者增量预配。 ...

随着数据分析在业务决策中变得日益重要，数据实时同步和剖析成为企业晋升竞争力的要害。MySQL 作为宽泛应用的关系型数据库，其数据存储丰盛，但无奈满足大规模数据分析和高并发查问的需要。而 Doris 作为一款专为大数据分析设计的分布式数据仓库，具备高性能、可扩大的特点，其优异的数据处理能力也在行业内广受关注。 01 为什么须要把 MySQL 同步到 Doris？大数据分析需要： 当您的业务数据量一直增长，MySQL 数据库曾经无奈满足大规模数据分析和查问的需要。实时数据仓库需要： 如果您的业务须要实时数据分析和决策，MySQL 可能无奈提供足够的性能和实时性。Doris 通过其优良的实时数据同步和解决能力，使您可能在最短时间内获取最新的业务数据。简单多维分析： 当您须要进行简单的多维分析、跨维度查问和简单聚合操作时，Doris 的分布式架构和优化的查问引擎能够显著进步查问性能，从而减速决策过程。数据存储优化： MySQL 在大数据场景下可能会面临性能降落和存储成本上升的问题。Doris 的列式存储和智能压缩等技术，可能高效存储大量数据，并在存储老本和性能之间找到平衡点。02 传统同步形式的弊病在实时数据同步畛域，传统办法存在一些痛点。 停机工夫长： 传统的同步形式通常要求同步期间进行业务，并且停机工夫高达数小时，对业务挑战微小。可靠性低： 不提供同步过程的观测、诊断与修复能力，同步过程中如果源端在做构造变更容易导致同步异样。同步耗时长： 传统 ETL 工具同步过程耗时长、复杂度高，无奈满足高频率的实时同步需要。难以保障数据准确性： 不提供数据一致性比照能力，难以保障同步数据的一致性。数据提早： 局部解决方案在大数据量、高并发状况下容易导致数据提早。03 NineData 的同步计划有什么亮点？咱们的解决方案为上述问题提供了翻新的解决方案，确保您可能高效、精确地将 MySQL 数据实时同步到 Doris： 实时同步性能卓越： NineData 采纳先进的数据同步技术，确保数据实时同步到 Doris，极大地升高了数据提早，实测 500 GB 数据传输实现仅用时 40 分钟，让您的决策基于最新数据。简略配置操作： 提供直观的图形化界面，让您轻松配置同步工作，无需编写繁冗的代码，升高了操作门槛和出错几率。牢靠的数据一致性： 通过配套的数据一致性比照机制，能够轻松发现同步过程产生的数据不统一的问题，同时提供一键修复性能，为您的业务数据提供牢靠的保障。灵便的定制选项： 同步工作能够依据业务需要进行灵便定制，抉择全量同步或增量同步，满足不同场景的数据同步要求。可观测可干涉： NineData 提供弱小的监控告警零碎，及时告诉您同步工作的状态和问题，让您可能迅速响应并解决潜在的同步危险。04 操作应用4.1 一分钟疾速配置同步工作通过 NineData 的数据复制控制台，仅需轻点鼠标，即可轻松实现 MySQL 到 Doris 的同步工作配置。 4.2 治理同步工作您能够实时监控同步工作的各项指标，同时能够通过内置的数据比照性能对同步实现后两端的数据进行自动化的比照，保障两端数据的一致性。 NineData 还反对复制限流性能，如果复制工作占用了太多读写资源，能够对写入速率进行限度，保障线上业务的性能。 ▶︎ 查看工作详情 ▶︎ 查看各复制类型详情 ▶︎ 查看数据比照 ▶︎ 配置复制限流 ...

简介CloudCanal 近期公布了 GaussDB for MySQL和 OpenGauss 为对端的数据迁徙同步链路。 对于新兴国产数据库 GaussDB ，咱们也是第一次落地其相干的数据迁徙同步能力，故从比较简单的对端作为切入点，逐渐相熟并延长其相干数据生态。 本文以 MySQL 到 OpenGauss 数据迁徙同步为案例，简要介绍技术背景以及疾速应用案例。 技术点MySQL 和 PostgreSQL 生态GaussDB for MySQL 和 OpenGauss 别离是 MySQL 和 PostgreSQL 生态的产物，所以对于数据迁徙同步的场景，也是离开解决的。 这些解决技术的差别点包含： Schema 构造元数据获取形式数据类型构造迁徙和同步数据写入形式性能调优尽管上述两者差别显著，然而 GaussDB for MySQL 和 MySQL , OpenGauss 和 PostgreSQL 之间兼容性相当不错，基本上能够做到无差别解决。 所以作为对端，咱们大量复用了 MySQL 和 PostgreSQL 数据迁徙同步相干技术，使得 GaussDB 数据链路从一推出，即具备不错的成熟度。 简略示例咱们以 MySQL 到 OpenGauss 为示例，简要介绍如何应用 CloudCanal 做 GaussDB 相干的数据迁徙同步。 筹备动作下载安装 CloudCanal 公有部署版本,应用参见疾速上手文档筹备 MySQL 数据库（8.0）和 OpenGauss 数据库（5.0）登录 CloudCanal ，增加 OpenGauss 和 MySQL工作创立工作治理 -> 新建工作测试链接 并抉择已增加的 源 和 指标 数据库点击下一步抉择 数据同步勾选 全量数据初始化抉择 开启一次性数据校验（可选）点击下一步抉择须要 迁徙同步的表点击下一步默认勾选所有列点击下一步确认创立工作工作 主动执行构造迁徙、全量迁徙 和 增量同步工作同步提早降到 10 秒以下时，主动执行数据校验，结果显示数据统一总结本文次要介绍了 CloudCanal 反对 GaussDB for MySQL 和 OpenGauss 指标端数据迁徙同步性能，通过这个能力，用户能够便当地将数据迁徙同步到 GaussDB for MySQL/OpenGauss 数据库，实现数据更宽泛、更实时的利用。 ...

作者：郑增权 爱可生南区数据库工程师，爱可生 DBA 团队成员，负责数据库相干技术支持。喜好：桌球、羽毛球、咖啡、电影。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。背景客户想在业务上线前记录现有 OceanBase 集群的 Parameters、Variables、ProxyCofnig 参数值。而后，将其与“默认值”或“DBA 被动刷的调优参数”进行比照，若是“默认值”或“DBA 被动刷的调优参数”则合乎预期，否则认为其是不合乎预期的值。最初，生成一份报表文件，标记出非预期的值，再由人工确认其合理性。 客户所用的 OceanBase 版本还没有提供追溯所有参数批改记录的办法，作者提供了利用 Shell 脚本 + Excel VLOOKUP 函数，疾速采集 OB 参数，并生成参数存档文件 的办法来实现该需要。上面将展现该办法的实现步骤。 实现2.1 筹备脚本和模板文件测试环境装置同版本的 OBServer、OBproxy，编写 Shell 脚本用于获取默认的 Parameters、Variables、ProxyCofnig 参数值，并将其提取进去，放至 Excel 作为“默认值模板”。 主备集群模式，主集群和备集群需别离执行脚本获取参数文件： 参数级别阐明Parameters集群级每个集群获取一份参数Variables租户级每个租户获取一份参数ProxyConfig节点级每个 OBProxy 节点获取一份参数三个脚本在文末出现并已传至 GIthub。 运行三个脚本，并下载后果文件。 整顿下载的文件，造成三个汇总文件。 Parameters 默认值模板 Variables 默认值模板 ProxyConfig 默认值模板 2.2 提取参数将 DBA 被动刷的参数提取进去，仿照“默认值模板”放至 Excel 作为“刷参数默认值模板”sheet。 2.3 获取比照参数在生产环境运行 Shell 脚本获取参数，将参数放至 Excel，基于 vlookup 进行跨 sheet 比照，将不合乎预期的参数值以红色底纹展现。 上面以 Variables 为例进行展现，Parameters 和 ProxyConfig 与其相似。 ...

【倡议珍藏】Windows 下如何装置最新版 MySQL 源码学习的调试环境步骤。 作者：芬达 《芬达的数据库学习笔记》公众号作者，开源爱好者，善于 MySQL、ansible。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。前言大多数研发人员应用 Mac 来调试代码，但我作为不懂研发的 DBA，并且作为 Windows 的粉丝，置信绝大多数运维同学也是应用 Win 的，那我必须应用 Win 了。从这篇文章开始，我尝试摸索 MySQL 源码的学习。 本文中，咱们将在 Win11 上装置 VSCode 用于调试 MySQL，装置 VMware，并在 VMware 里部署 CentOS7。在 CentOS7 里，咱们将通过 VSCode 部署和调试 MySQL 的 Debug 版本。通过应用装置在 Win11 的 VSCode 的 REMOTE 插件，咱们能够拜访 CentOS7，并装置 VSCode 的调试插件来调试 MySQL 的 Debug 版。须要留神的是，REMOTE 插件装置在 Win11 里，而调试插件则通过 REMOTE 插件装置在 CentOS7 里，这一点别弄错了。上面，咱们正式开始。 环境及软件筹备Win11VMware WorkStation 17 PROCentOS7.5（VMware 虚拟机上部署）VSCode 1.81.1MySQL 8.0.34 源码包以上软件版本均为文章编写时的最新版。 CentOS7 环境筹备实际上如果不是应用 Mac，那么应用 Ubuntu 应该是大多数研发人员的抉择，我应用 CentOS7 是因为我更相熟它，并且它更贴近于生产环境。但有一个大问题次要是 CentOS7 默认 YUM 源的开发依赖包太老旧了，我须要应用 epel-release 的包来装置更加新的 Debug 依赖包。 ...

MySQL 和 Elasticsearch 是两种不同的数据管理系统，它们各有优劣，实用于不同的场景。本文将从以下几个方面对它们进行比拟和剖析： 数据模型查询语言索引和搜寻分布式和高可用性能和扩展性应用场景数据模型MySQL 是一个关系型数据库管理系统（RDBMS），它应用表（table）来存储结构化的数据，每个表由多个行（row）和列（column）组成，每个列有一个预约义的数据类型，例如整数、字符串、日期等。MySQL 反对主键、外键、束缚、触发器等关系型数据库的个性，以保证数据的完整性和一致性。 Elasticsearch 是一个基于 Lucene 的搜索引擎，它应用文档（document）来存储半结构化或非结构化的数据，每个文档由多个字段（field）组成，每个字段能够有不同的数据类型，例如文本、数字、布尔、数组等。Elasticsearch 反对动静映射（dynamic mapping），能够依据数据主动推断字段的类型和索引形式。 MySQL 和 Elasticsearch 的数据模型有以下几点区别： MySQL 的数据模型是严格的，须要当时定义好表的构造和束缚，而 Elasticsearch 的数据模型是灵便的，能够随时增加或批改字段。MySQL 的数据模型是二维的，每个表只有行和列两个维度，而 Elasticsearch 的数据模型是多维的，每个文档能够有嵌套的对象或数组。MySQL 的数据模型是关系型的，能够通过连贯（join）多个表来查问相干的数据，而 Elasticsearch 的数据模型是非关系型的，不反对连贯操作，须要通过嵌套文档或父子文档来实现关联查问。举荐博主开源的 H5 商城我的项目waynboot-mall，这是一套全副开源的微商城我的项目，蕴含三个我的项目：经营后盾、H5 商城前台和服务端接口。实现了商城所需的首页展现、商品分类、商品详情、商品 sku、分词搜寻、购物车、结算下单、支付宝/微信领取、收单评论以及欠缺的后盾治理等一系列性能。 技术上基于最新得 Springboot3.0、jdk17，整合了 MySql、Redis、RabbitMQ、ElasticSearch 等罕用中间件。分模块设计、简洁易保护，欢送大家点个 star、关注博主。 github 地址：https://github.com/wayn111/waynboot-mall 查询语言MySQL 应用规范的 SQL 语言来查问和操作数据，SQL 语言是一种申明式的语言，能够通过简洁的语法来表白简单的逻辑。SQL 语言反对多种查问类型，例如抉择（select）、插入（insert）、更新（update）、删除（delete）、聚合（aggregate）、排序（order by）、分组（group by）、过滤（where）、连贯（join）等。 Elasticsearch 应用 JSON 格局的查问 DSL（Domain Specific Language）来查问和操作数据，查问 DSL 是一种基于 Lucene 查问语法的语言，能够通过嵌套的 JSON 对象来构建简单的查问。查问 DSL 反对多种查问类型，例如全文检索（full-text search）、结构化检索（structured search）、地理位置检索（geo search）、度量检索（metric search）等。 MySQL 和 Elasticsearch 的查询语言有以下几点区别： ...

在本文中，咱们将探讨 MySQL 和 MariaDB 服务生命周期和版本治理形式两个方面目前的情况及相干历史背景。 作者：Peter Zaitsev 本文起源：Percona 官网博客 爱可生开源社区出品。须要阐明的是 MySQL 和 MariaD B都有社区版和企业版。对于 MySQL，这两个版本都是由同一家公司（Oracle）提供，遵循雷同的版本编号体系，企业版蕴含更丰盛的性能。对于 MariaDB，社区版由 MariaDB 基金会提供，而企业版由 MariaDB PLC 提供，采纳独有的生命周期 与性能配置。为简略起见,咱们将重点关注社区版。 MariaDB你可能理解到，MariaDB 起初是 MySQL 的一个分支。晚期。两者倒退模式类似。但从 2014 年 MariaDB 10 版开始，状况大为不同。这一次，MariaDB 不再与 MySQL 版本匹配，从而摈弃了之前与 MySQL 5.1 和 MySQL 5.5 版本统一的模式。 取得独立的版本体系容许 MariaDB 以更快的节奏独立翻新，而不会因为与 MySQL 版本号雷同而产生用户误导。例如，MariaDB 已经有 5.2 和 5.3 两个版本，但 MySQL 没有对应的版本号。 MariaDB 倒退迅速。紧接着 2015 年公布了 MariaDB 10.1 版本，2017 年公布了 MariaDB 10.2 版本。尔后，主版本每个 1-2 年公布一次，2021 年公布了 MariaDB 10.6 版。不过，每一个版本都提供 5 年的长期反对期限，这给工程团队带来了额外负担。 ...

最近因需要改变新增了一些数据库表，然而在定义表构造时，具体列属性的抉择有些不知其所以然，索引的增加也有脱漏和不标准的中央，所以我打算为创立一个高性能表的过程以实战的模式写一个专题，以此来学习和坚固这些常识。 1. 实战我应用的 MySQL 版本是 5.7，建表 DDL 语句如下所示：依据需要创立接口调用日志数据库表，请大家浏览具体字段的属性信息，它们有不少可能优化的点。 CREATE TABLE `service_log` ( `id` bigint(100) NOT NULL AUTO_INCREMENT COMMENT '主键', `service_type` int(10) DEFAULT NULL COMMENT '接口类型', `service_name` varchar(30) DEFAULT NULL COMMENT '接口名称', `service_method` varchar(10) DEFAULT NULL COMMENT '接口方式', `serial_no` int(10) DEFAULT NULL COMMENT '音讯序号', `service_caller` varchar(15) DEFAULT NULL COMMENT '调用方', `service_receiver` varchar(15) DEFAULT NULL COMMENT '接管方', `status` int(3) DEFAULT '10' COMMENT '状态 10-胜利 20-异样', `error_message` varchar(200) DEFAULT NULL COMMENT '异样信息', `message` text DEFAULT NULL COMMENT '报文内容', `create_user` varchar(50) DEFAULT NULL COMMENT '创建者', `create_time` datetime NOT NULL COMMENT '创立工夫', `update_user` varchar(50) DEFAULT NULL COMMENT '更新者', `update_time` datetime NOT NULL COMMENT '更新工夫', `is_delete` tinyint(1) NOT NULL DEFAULT '0' COMMENT '刪除标记', `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '工夫戳', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='接口调用日志';我会在下文中将其中蕴含的问题和能够进行优化的中央一一进行解释，次要参考的书目是《高性能MySQL 第四版》，也心愿大家有精力去看原书。 ...

为什么mysql应用B+树作为索引索引的呈现其实就是为了进步数据查问的效率. 就像书的目录一样。一本500页的书，如果你想疾速找到其中的某一个知识点，咱们必定要先依据目录找到某个章节。同样，对于数据库的表而言，索引就是目录。 对于一个数据库索引来说， 一个好的索引构造实现一次查问须要有以下长处： 尽可能少的磁盘 I/O 操作高效地查问，能够反对范畴查问为什么呢？ 因为索引是保留到磁盘上的，当通过索引查找数据时，就须要先从磁盘读取索引到内存，再通过索引从磁盘中找到某行数据，而后读入到内存，也就是说查问过程中会产生屡次磁盘 I/O，而磁盘 I/O 次数越多，所耗费的工夫也就越大。 所以，咱们心愿尽可能少的磁盘 I/O。 另外mysql是反对范畴查问的， 所以也须要一个高效的范畴查问。 那当初咱们尝试看看哪一个索引构造能够满足这些需要。 数组咱们最开始接触的数据结构就是数组。 如果咱们用有序数组来贮存索引，看看后果如何。 为什么抉择是有序呢？ 因为咱们能够用二分查找在有序数组中疾速地找出指标索引，工夫复杂度能够降落到O（logn）。 二分查找法每次都把查问的范畴减半, 工夫复杂度也不算高。 仿佛看起来是一个不错的抉择。 然而插入新元素的时候性能太低 想想看这么一个例子， 咱们有几十万条数据， 在两头某个地位插入一个元素，为了让数组放弃有序，须要将这个元素之后的所有元素后移一位。 如果这个操作产生在磁盘中，这必然是灾难性的。因为磁盘的速度比内存慢几十万倍，所以咱们不能用一种线性构造将磁盘排序。 这样揭示了数组的一个特点： 查问快而增删慢。 所以，有序数组索引只实用于动态存储引擎，比方你要保留的是 2020 年某个城市的所有人口信息，这类不会再批改的数据。 二叉树有一种人造适宜二分查找的数据结构， 那就是二叉树。 把所有二分查找中用到的所有两头节点，把他们用指针连起来，并将最两头的节点作为根节点,那么就取得了一个二叉查找树。 二叉查找树的特点是 一个节点的左子树的所有节点都小于这个节点，右子树的所有节点都大于这个节点。 它能够解决了插入新节点的问题 二叉树不会像线性构造那样插入一个元素，所有元素都须要向后排列。 因而，二叉查找树解决了间断构造插入新元素开销很大的问题，同时又放弃着人造的二分构造。 然而又带来了新的问题：在极其状况下，二叉查找树会进化成链表。 因为每次插入的值，都比节点的值要大. 查问的工夫复杂度进化为O（n） 因为树是存储在磁盘中的，拜访每个节点，都可能会拜访一个新的数据块，所以树的高度越高，就会影响查问性能。 为了解决这种状况，均衡二叉查找树（AVL 树） 诞生了。 它的特点是： 每个节点的左子树和右子树的高度差不能超过 1 插入示例如下， 能够看到它会维持自均衡. 然而均衡二叉树还是解决不了，因树变高而影响查问效率的问题。 能够设想一下一棵100万节点的均衡二叉树，树高20。一次查问可能须要拜访20个数据块。 在机械硬盘时代，从磁盘随机读一个数据块大略可能须要10 ms左右的寻址工夫。也就是说，对于一个100万行的表，如果应用二叉树来存储，独自拜访一个行可能须要20个10 ms的工夫，这个查问可慢到家了。 为了让一个查问尽量少地读磁盘，就必须让查问过程拜访尽量少的数据块。那么，咱们就不应该应用二叉树，而是要应用“N叉”树。 B/B+树 B树B 树的每一个节点最多能够包含 M 个子节点，M 称为 B 树的阶，所以 B 树就是一个多叉树。 ...

本篇文章采纳 Docker 形式搭建 Grafana + Prometheus 实现对 DBLE 的 JVM 相干指标的监控零碎。 作者：文韵涵 爱可生 DBLE 团队开发成员，次要负责 DBLE 需要开发，故障排查和社区问题解答。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。前言本篇文章将采纳 Docker 形式搭建 Grafana + Prometheus 实现对 DBLE 的 JVM 相干指标（如：CPU、Memory Pool、GC、Thread）的监控零碎。 筹备Linux 服务器：10.186.63.8曾经装置 Docker搭建环境1. 部署 DBLE该局部参考参考自 Docker 疾速开始 筹备 MySQL 容器# 创立一个 Docker 网段 dble-net：172.18.0.0/16docker network create -o "com.docker.network.bridge.name"="dble-net" --subnet 172.18.0.0/16 dble-net# 创立两个 MySQL 容器，别离映射到主机的 33061 和 33062 作为 MySQL 的服务端口docker run --name backend-mysql1 --ip 172.18.0.2 -e MYSQL_ROOT_PASSWORD=123456 -p 33061:3306 --network=dble-net -d mysql:5.7 --server-id=1docker run --name backend-mysql2 --ip 172.18.0.3 -e MYSQL_ROOT_PASSWORD=123456 -p 33062:3306 --network=dble-net -d mysql:5.7 --server-id=2如果执行 docker run... 时呈现 408 Request Time-out 报错，请多尝试几次。 ...

MySQL 作为以后利用最宽泛的开源关系型数据库之一，具备高性能、稳定性和易用性等个性，是许多网站、利用和商业产品的次要数据存储。在一些场景中，如果呈现单表行数上亿的状况，就可能须要开发和 DBA 对大表进行优化：分表、归档或扩容操作，而在这些操作中都波及了对数据的迁徙。所以，提供高效、精确、稳固的大表迁徙能力是十分有必要的。 1. 传统的迁徙计划目前，数据迁徙次要分为逻辑迁徙和物理迁徙，逻辑迁徙次要有 mysqldump、mysqlpump 和 load data，物理迁徙次要有 XtraBackup。对于这类导入导出和拷贝文件的传统迁徙计划，在大表迁徙中会存在一些问题： 须要停机，对于物理迁徙，不能保障在线业务。性能差，对于逻辑迁徙，单线程导出表。可靠性差，导出异样后，不反对断点，须要从新导出。运维性差，迁徙期间，不能对导入导出进行暂停、限流等操作。2. 当先的迁徙计划NineData 提供的数据复制同时蕴含了数据迁徙和数据同步的能力，在不影响业务的前提下，提供了高效、稳固、可运维的大表迁徙能力。对大表（单表 227G，行数 10 亿）迁徙：NineData 约 30 分钟实现迁徙，均匀速率 124.2 MB/s，均匀 534188 RPS。 通过对 MySQL 大表迁徙的性能测试，和传统迁徙比，NineData 数据迁徙的劣势有： 简略易用：一分钟即可实现工作配置，并全自动化实现工作迁徙。强劲性能：欠缺的智能分片、行级并发、动静攒批等核心技术，无效保障迁徙性能。高牢靠：联合新型断点、异样诊断及丰盛的修复伎俩，对于迁徙过程中可能呈现软硬件故障，提供欠缺的容灾能力，大大提高了大表迁徙的成功率。通过上述劣势，保障了 NineData 在大表迁徙场景下的当先性。另外，NineData 还提供了比照性能，蕴含数据和构造的比照，以及全量、疾速和不统一复检的比照形式，并且也反对不同的比照频率。在迁徙或复制完结后，通过数据和构造比照，能无效的保障数据的一致性。 NineData 在提供弱小迁徙能力的同时，也保障了应用的简略性，只须要 1 分钟就能实现迁徙工作的配置，实现齐全自动化的数据迁徙过程。上面咱们来看下整个工作的配置过程： 迁徙链路的配置 配置工作名称，抉择要迁徙的源和指标实例。抉择复制类型，数据迁徙抉择构造和全量复制（数据迁徙）。依据须要，抉择适合的抵触解决策略。点击下一步，进行迁徙对象的抉择。抉择迁徙对象 抉择迁徙对象：针对不同粒度抉择迁徙对象：实例、库、表、视图等。 配置映射和过滤规定：指标实例能够自定义迁徙的库名、表名和依照过滤条件进行局部数据迁徙，也能够针对表的列名进行映射和局部列迁徙。 预查看 通过丰盛的查看项，保障了迁徙工作的稳定性及和数据的一致性。到此，咱们就实现了一个高性能迁徙工作的配置。 同时，为了提供更好的迁徙体验，NineData 针对迁徙过程提供了欠缺的观测、干涉能力。其岂但提供对象迁徙的具体状态、停顿、详情，还通过监控和日志走漏后盾线程的外部执行状况，帮忙用户全方位追踪迁徙停顿。同时，还针对运行过程中可能呈现的异常情况，提供根底诊断能力，及修复、跳过、移除等多种修复策略和迁徙限流能力，让用户可能自主疾速得诊断并修复链路，保障迁徙稳定性。 3. 总结NineData 提供的高效、疾速、稳固的 MySQL 大表迁徙能力，很好的补充了传统迁徙计划的有余。以后，NineData 曾经反对数十种常见数据库的迁徙复制，同时，除了 SAAS 模式外，还提供了企业专属集群模式，满足企业最高的数据安全合规要求。目前，NineData 已在运营商、金融、制造业、地产、电商等多个行业实现大规模利用实际。如果您感兴趣的话，能够登录官网 https://www.ninedata.cloud/dbmigration，立刻开始收费应用。

好消息，石原子旗下新一代离在线一体化实时数仓 StoneData 2.0 正式上线阿里云云市场了！云市场版本交付形式为计算巢私有化部署，主动实现云资源的创立和利用部署，相比传统部署计划，大幅升高配置复杂度。此外，StoneData 2.0 还配合了由石原子科技自研的多数据库智能云管平台 StoneDMP，极大地优化了私有化部署体验，让数据库运维治理省心又简略，欢送大家返回阿里云市场进行试用，首次下单可收费体验30天！ 阿里云市场地址https://market.aliyun.com/products/56024006/cmgj00059975.html... StoneData 产品介绍StoneData 是石原子自研的基于全场景的新一代高性能、低成本的离在线一体化实时数仓，高度兼容 MySQL 语法，毫秒级更新，亚秒级查问，满足准实时和实时剖析需要，一体化架构将实时和离线交融，缩小数据冗余和挪动，具备简化技术栈架构的能力；实现业务与技术解耦，反对自助式剖析和麻利剖析；无论是数据湖中的非结构化或半结构化数据，还是数据库中的结构化数据，都可应用 StoneData 构建企业的数据分析平台，同时实现高吞吐离线解决和高性能在线剖析，实现降本增效。 阿里云市场 StoneData 购买与部署指南接下来，本文将领导企业用户如何从阿里云市场购买、应用石原子科技的 StoneData 企业级实时数仓产品。 1、购买1.1 找到商品通过阿里云官网的云市场类目进入云市场首页，搜寻 StoneData 即可发现产品，如下图。 1.2 抉择规格点击云市场的商品，进入 StoneData 商品详情页，在商品详情页能够抉择须要购买的 StoneData 规格、期限和所属区域。 抉择实现后点击购买，如果没有登录请依据阿里云的疏导实现登录，点击购买胜利后将进入规格配置界面。 1.3 配置进入配置页，界面展现如下： 依据右侧的填写疏导条，须要别离填写根本配置如下图，依据客户的理论状况填写地区、根本配置、实例配置： 地区：填写 StoneData 须要部署的区域 根本配置：ECS 替换区可用区、现有 VPC 的实例 ID、网络交换机 ID实例配置： 付费类型：按量付费和包月包年两种，指的是运行 StoneData 对应的云计算资源的付费类型 是否申请 eip：默认开启，申请 eip 将容许用户通过公网拜访 StoneData 的控制台 集群名称：购买胜利后部署的集群名称 集群明码：拜访集群的管理员账号 kepler 的明码，请牢记，后续登录控制台或用 JDBC 连贯 StoneData 须要应用 如下图所示： 1.4 核查价格信息在配置页实现地区、根本配置、实例配置后，阿里云将计算对应的云计算资源价格，如下图所示： 1.5 下单付款在配置页确定信息无误后，点击页面最下方的返回领取 展现订单领取界面 ...

StoneDB开源地址https://github.com/stoneatom/stonedb 设计：小艾审核：丁奇、李浩编辑：宇亭 作者：王若添中国科学技术大学-软件工程-在读硕士、StoneDB 内核研发实习生 performance_schema 简介MySQL 启动后会主动创立四个 database mysql> show databases;+--------------------+| Database           |+--------------------+| information_schema || mysql              || performance_schema || sys                |+--------------------+其中的 performance schema 用于监控 MySQL server 在一个较低级别的运行过程中的资源耗费、资源期待等状况。它提供了一种在数据库运行时实时查看 server 的外部执行状况的办法，该数据库次要关注数据库运行过程中的性能相干的数据，与更为常见的 information_schema 不同，information_schema 次要关注 server 运行过程中的元数据信息。 performance_schema 中的事件只记录在本地 server 的 performance_schema 中，其表中数据发生变化时不会被写入 binlog 中，也不会通过复制机制被复制到其余 server 中。 表的分类能够将 performance_schema 库下的表依照监督不同的纬度就行分组。 语句事件记录表，这些表记录了语句事件信息mysql> show tables like '%statement%';+----------------------------------------------------+| Tables_in_performance_schema (%statement%)         |+----------------------------------------------------+| events_statements_current                          || events_statements_histogram_by_digest              || events_statements_history                          || events_statements_summary_by_digest                || events_statements_summary_by_host_by_event_name    || ...                                                |期待事件记录表，与语句事件类型的相干记录表相似mysql> show tables like '%wait%';+-----------------------------------------------+| Tables_in_performance_schema (%wait%)         |+-----------------------------------------------+| data_lock_waits                               || events_waits_current                          || events_waits_history                          || events_waits_history_long                     || ...                                           |事务事件记录表，记录事务相干的事件的表mysql> show tables like '%transaction%';+------------------------------------------------------+| Tables_in_performance_schema (%transaction%)         |+------------------------------------------------------+| binary_log_transaction_compression_stats             || events_transactions_current                          || events_transactions_history                          || ...                                                  |应用场景对于语句事件记录表中的 events_statements_summary_by_digest 表举例，这个表记录了基于 SQL 语句摘要的统计信息。如果咱们想要理解该 stonedb 过程上执行过的所有类型 SQL 的频次，咱们能够应用 SELECT DIGEST_TEXT,COUNT_STAR FROM events_statements_summary_by_digest 查问该表，其中 DIGEST_TEXT: 这个列是 SQL 语句的标准化版本，即删除了 SQL 语句中的特定数据（例如，具体的值、表名、列名等）后的 SQL 语句。所有逻辑上雷同的 SQL 语句（即便具体的值不同）都会有雷同的 DIGEST_TEXT。这使得咱们能够统计和剖析雷同逻辑 SQL 语句的执行状况。COUNT_STAR: 这个列是每个 SQL 语句摘要的执行次数。这能够帮忙咱们辨认哪些 SQL 语句被执行的次数最多，可能对系统的性能影响最大。这个查问返回的后果就是每种 SQL 语句的标准化版本及其执行次数。这能够帮忙咱们了解哪些类型的 SQL 语句最常被执行，进而能够对这些 SQL 语句进行优化以进步零碎的性能。 ...

当数据页毁坏，如何依据实例的健康状况抉择不同的策略定位损坏文件并复原。 作者：徐文梁 爱可生 DBA 成员，一个执着于技术的数据库工程师，次要负责数据库日常运维工作。善于 MySQL，Redis 及其他常见数据库也有涉猎；喜爱垂钓，看书，看风光，结交新敌人。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。问题背景四月份的时候，遇到一次实例异样 crash 的问题。过后数据库主动重启，未对生产造成影响，未做解决，然而还是记录了下错误信息，谬误日志中有如下信息: InnoDB: End of page dumpInnoDB: Page may be an index page where index id is 81962023-04-11T07:57:42.508371+08:00 0 [ERROR] [FATAL] InnoDB: Apparent corruption of an index page [page id: space=3859, page number=842530] to be written to data file. We intentionally crash the server to prevent corrupt data from ending up in data files.2023-04-11 07:57:42 0x7fe4d42cf080 InnoDB: Assertion failure in thread 140620788985984 in file ut0ut.cc line 921InnoDB: We intentionally generate a memory trap.因为过后主动复原了，并未器重这个问题，而后六月份的时候实例又 crash 了。查看报错信息，报错信息如下： ...

作者：肖圣龙 | StoneData 技术架构师审核：王博 引言：随着数据分析在企业和组织中的重要性一直减少，数据仓库成为解决大规模数据集和反对简单剖析的首选解决方案，如何保障数据安全由此成为了在数据分析过程中不可漠视的重要问题。身份认证与拜访控制策略是构建安全可靠的数仓环境的外围因素，StoneData 作为一款新一代高性能、低成本的一站式实时数仓，已具备健全的身份认证与访问控制能力。 本文将围绕着账号合规、明码策略、主机名校验和基于角色的访问控制模型等，具体介 StoneData 的身份认证与访问控制能力。 一、身份认证身份认证模块是确保账号平安的外围组成部分。 该模块综合利用了账号合规、明码策略和主机名校验等性能，提供了弱小的身份认证机制。以下是具体论述这些内容在身份认证模块中的整合和利用： 1.1. 账号合规性账号合规性即要求用户创立符合规范的账号。这包含应用非法的字符、防止敏感信息作为账号名等。通过账号合规要求，StoneData 能够确保账号的可识别性和一致性，进步治理的便捷性和安全性。 图1-1: 账号名和明码校验逻辑 1.1.1. 非法字符要求为了确保账号的规范性和可识别性，咱们要求用户只能应用非法字符来创立账号。 非法字符指的是那些合乎安全性和兼容性要求的字符集。StoneData 限度账号只能蕴含大小写字母和数字以及短横线，这样的限度有助于防止可能导致数据仓库故障或安全漏洞的非法字符应用。 1.1.2. 敏感信息防止为了爱护账号的安全性和隐衷，用户在创立账号时应尽量避免在账号中应用敏感信息，如集体身份证号码、银行账号等，以此来缩小可能导致的身份偷盗和欺诈行为的危险。 1.1.3. 账号治理性能为了不便管理员对账号进行治理和监控，StoneData 提供了账号治理性能。 管理员能够通过该性能对账号进行增加、批改、删除等操作。以此帮忙管理员更好地管制和保护账号，确保账号的合规性和安全性。 1.2. 明码 策略身份认证模块中的明码策略要求用户设置强明码，以避免明码被猜想或被破解。 此外，咱们激励用户定期更换明码，以升高明码被破解的危险。在明码存储方面，StoneData 采纳密文存储，以此进步账号的安全性。图1-2: 明码存储逻辑示意 1.2.1. 强明码策略强明码策略是爱护账号平安的首要步骤。StoneData 的明码策略要求明码长度不少于8个字符，蕴含大小写字母、数字或特殊字符这4种元素中的至多3种。 1.2.2. 明码存储与加密StoneData 采纳平安的明码存储和加密机制，以爱护用户明码的安全性。存储用户明码时，StoneData 采纳加密算法对明码进行哈希运算，再存储其哈希值。这样即便数据库受到未经受权的拜访，黑客也无奈取得用户的明文明码。 1.3. 机名校验账号和主机名同步校验是一项重要的安全措施。StoneData 账号名中的主机名策略容许管理员限度特定账号只能从特定的主机名或 IP 地址进行登录。 通过灵便的主机名匹配规定能够确保管理员可能依据具体需要进行定制化的主机名限度策略。以下是具体论述这一安全措施的工作原理和施行办法： 1.3.1. 主机名限度策略在 StoneData 中，账号名采纳“用户名@主机名”的格局，其中主机名能够是 IP 地址或特定域名。 咱们能够为每个账号设置特定的主机名限度，这意味着该账号只能从与其关联的特定主机名或 IP 地址进行登录。 1.3.2. 同步校验过程在登录过程中，StoneData 首先会验证账号和明码的正确性。一旦账号和明码通过验证，接下来会进行账号和主机名的同步校验。 1.3.3. 主机名匹配规定StoneData 应用灵便的主机名匹配规定，以确保与账号关联的主机名限度失去无效利用。 管理员能够依据具体需要抉择适当的匹配模式，确保账号与主机名的限度达到预期成果。现反对以下几种主机名匹配模式：（1）准确匹配准确匹配要求登录申请的主机名与账号设置的主机名齐全匹配。只有在主机名齐全相符的状况下，登录申请才会被承受。 本机拜访（localhost）：限度账号仅能在本机拜访IP 地址拜访（仅反对IPv4地址）：准确匹配单个IP地址，如 10.1.0.23、192.168.32.1（2）通配符匹配通配符匹配容许应用通配符来含糊匹配主机名。StoneData 当初仅反对百分号通配符： 百分号（%）通配符：容许来自任一主机发动的申请。1.3.4. 安全性加强账号和主机名同步校验的措施加强了 StoneData 的安全性，提供了额定的保护层。 既能避免对数据库的歹意拜访，也能加重企业外部可能带来的威逼。（1）避免歹意拜访通过限度账号只能从特定的主机名或 IP 地址进行登录，StoneData 能够无效避免歹意用户通过其余主机或IP 地址尝试非受权拜访数据库。即便攻击者取得了正确的账号和明码，因为主机名不匹配，他们也无奈胜利登录。（2）加重外部威逼通过限度账号只能从指定的 IP 登录，StoneData 能够缩小内部人员滥用权限的危险。即便内部人员获取了其他人的账号和明码，因为 IP 不匹配，他们也无奈登录到零碎。 二、访问控制StoneData 的拜访控制策略通过 RBAC（Role-Based Access Control）模型实现，这是一种基于角色的访问控制模型。 RBAC 定义了一套明确的权限治理规定，通过角色的受权来治理用户对数据库资源的拜访权限。在此基础上，为不便对用户的组织治理，咱们引入了用户组的概念，以进一步提高权限治理的效率和灵活性。同时，咱们兼容了 MySQL 的用户专属权限性能，以适应 MySQL 权限生态体系。 以下是 StoneData 拜访控制策略的组成部分及其性能阐明：图2-1: RBAC模型关系示意 ...

设计：小艾审核：丁奇、宇亭编辑：宇亭 作者一：徐鑫强（花名：无花果）电子科技大学-计算机技术-在读硕士、StoneDB 内核研发实习生 作者二：柳湛宇（花名：乌淄）浙江大学-软件工程-在读硕士、StoneDB 内核研发实习生 一、MySQL 连贯形式简介MySQL 反对天然连贯、等值连贯（内连贯）、左连贯、右连贯、穿插连贯五种连贯形式，不反对全外连贯，全外连贯能够通过 Union 并集操作实现。连贯算法：简略嵌套循环、索引嵌套循环、块嵌套循环以及哈希连贯。 简略嵌套循环（Simple Nested-Loop Join，SNLJ）驱动表中的每一条记录与被驱动表中的所有记录顺次比拟判断，驱动表遍历一次，被驱动表遍历屡次。此算法开销十分大，假如驱动表的行数为 M，被驱动表的行数为 N，则算法工夫复杂度为 O(M*N)。实际上，MySQL 并不会应用此算法。 基于索引的嵌套循环（Indexed Nested-Loop Join，INLJ）通过在被驱动表建设索引，缩小被驱动表的扫描次数。个别 B+树的高度为 3~4 层，也就是说匹配一次的 I/O 耗费也就 3~4 次，因而索引查问的老本是比拟固定的，故优化器都偏向于应用记录数少的表作为驱动表。在有索引的状况下，MySQL 会尝试应用此算法。整个过程如下图所示： 基于块的嵌套循环（Block Nested-Loop Join，BNLJ）扫描一个表的过程其实是先把这个表从磁盘上加载到内存中，而后在内存中比拟匹配条件是否满足。但内存里可能并不能齐全寄存的下表中所有的记录。为了缩小拜访被驱动表的次数，咱们能够首先将驱动表的数据批量加载到 Join Buffer（连贯缓冲），而后当加载被驱动表的记录到内存时，就能够一次性和多条驱动表中的记录做匹配，这样可大大减少被驱动表的扫描次数，这就是 BNL 算法的思维。当被驱动表上没有建设索引时，MySQL 会尝试应用此算法。整体效率比拟：INLJ > BNLJ > SNLJ。整个过程如下图所示： 哈希连贯（Hash Join）嵌套循环连贯对于被连贯的数据集较小的状况是较好的抉择，而对于大数据集 Hash Join 是更好的形式。优化器应用两个表中的较小表在内存中根据 Join Key 建设哈希表，而后顺次扫描较大表并探测哈希表，找出能与哈希表匹配的行。Hash Join 会毁坏表数据的有序性和局部性，因而它只能利用于等值连贯。 二、哈希连贯的优化方向简述随着 MySQL 8.0 对 Hash Join 反对，在内表面均无索引或大表驱动小表的状况下，Hash Join 显然是比 BNLJ 更好的抉择，而在 AP 场景下，大量数据多表 Join 的刚需也使得 Hash Join 有了多种方向的优化门路。本章简要介绍一部分对 Hash Join 优化的方向和思路。 ...

前言：为了缩小三维数据中心可视化管理系统的复工工夫，放弃其服务的高度可用性。同时部署多套同样的三维可视化零碎，让三维数据中心可视化零碎同时部署并运行到多个服务器上。同时提供一个虚构IP，而后里面通过这个虚构IP来拜访三维可视化管理系统，当一台实体服务器挂掉时会主动的切到另一条服务器，然而这个虚构IP仍然能提供服务。 要实现高可用性，须要保证数据的统一，因而须要保障这几台服务器上的数据库中的数据统一；同时还须要保障上传的文件信息统一。最初须要通过软件监听程序来监听并且挂掉时进行主动切换。一、什么是高可用?高可用HA（High Availability）是分布式系统架构设计中必须思考的因素之一，它通常是指，通过设计缩小零碎不能提供服务的工夫。 假如零碎始终可能提供服务，咱们说零碎的可用性是100%。 如果零碎每运行100个工夫单位，会有1个工夫单位无奈提供服务，咱们说零碎的可用性是99%。52.56分钟。 百度的搜寻首页，是业内公认高可用保障十分杰出的零碎，甚至人们会通过www.baidu.com 能不能拜访来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通顺，百度就能拜访”，“百度打不开，应该是网络连不上”的印象，这其实是对百度HA最高的贬责。-----摘选自知乎 二、如何保障系统的高可用咱们都晓得，单点是零碎高可用的大敌，单点往往是零碎高可用最大的危险和敌人，应该尽量在零碎设计的过程中防止单点。方法论上，高可用保障的准则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其余backup可能顶上。 保证系统高可用，架构设计的外围准则是：冗余。 有了冗余之后，还不够，每次呈现故障须要人工染指复原势必会减少零碎的不可服务实际。所以，又往往是通过“主动故障转移”来实现零碎的高可用。-----摘选自知乎 人话:两台服务器启动着雷同的服务，如果有一台故障，另一台主动接管,咱们将这个称之为高可用;相似服务器:冗余,相似服务器有2-4个电源,然而比拟贵 上图: 装置keepalived:离线装置办法：因为咱们的大部分客户都是属于数据中心，并不会连贯外网，所以采取离线装置的形式比拟多，在线装置的办法非常简单，如下命令即可，在装置keepalived之前确保装置了摄像头的那一套货色，因为这里波及到须要装置openssl的模块，如果没有装请先装nginx摄像头相应的软件keepalived的运行模式:筹备条件: 须要三个ip,并且保障是局域网,相互之间ping的通,后面两个ip好了解,两台服务器,第三个ip就是一个虚构ip,就是空余ip没被启用的即可,咱们拜访零碎的话就是通过这个虚构ip拜访 优先级VRRP依据优先级来确定虚构路由器中每台路由器的位置; 非抢占形式如果Backup路由器工作在非抢占形式下，则只有Master路由器没有呈现故障Backup路由器即便随后被配置了更高的优先级也不会成为Master路由器; 抢占形式如果Backup路由器工作在抢占形式下，当它收到VRRP报文后，会将本人的优先级与通告报文中的优先级进行比拟。如果本人的优先级比以后的Master路由器的优先级高，就会被动抢占成为Master路由器；否则，将放弃Backup状态. yum install keepalived-y1.上传文件1.首先把文件传到opt上面 2.解压装置cd /opt tar -zxvf keepalived-2.0.20.tar.gz 3.编译cd keepalived-2.0.20 ./configure --prefix=/usr/local/keepalived会发现有一个报错 4.报错信息而后装置cd /optrpm -ivh libnl-1.1.4-3.el7.x86_64.rpm --force --nodepsrpm -ivh libnl-devel-1.1.4-3.el7.x86_64.rpm --force --nodepscd keepalived-2.0.20./configure --prefix=/usr/local/keepalived 没有报错了,持续往下执行 make && make install输出下面的命令会报以下谬误 解决: cd /usr/local/lib64export LIBRARY_PATH=/usr/local/lib64cd /opt/keepalived-2.0.20./configure --prefix=/usr/local/keepalived make && make install执行完之后也报错了 5.初始化keepalived cp /opt/keepalived-2.0.20/keepalived/etc/init.d/keepalived /etc/init.d/ cp /opt/keepalived-2.0.20/keepalived/etc/sysconfig/keepalived /etc/sysconfig/cp /usr/local/keepalived/sbin/keepalived /usr/sbin/mkdir -p /etc/keepalivedcp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/chmod +x /etc/init.d/keepalived6.增加keepalived到开机启动chkconfig —add keepalived ...

数新网络——让每个人享受数据的价值官网已全副降级，欢送拜访！https://www.datacyber.com前言在MySQL中，有三个重要的日志文件，别离是undolog、redolog和binlog。这三个日志文件在MySQL中扮演着不同的角色。 01 undo Log在数据库事务的四大个性中，原子性是指事务中的所有操作要么全副胜利，要么全副失败回滚。实现原子性的底层机制之一就是通过应用Undo Log。 undolog是innodb引擎独有的日志，次要是为事务而筹备的,采纳循环写笼罩的形式提供回滚能力。它用于记录批改操作的反向操作。 当MySQL执行一个事务时，它将对数据进行批改，同时也将反向操作（如果咱们执行了insert操作，那么日志中就会新增一条相同的delete的sql）记录到 undolog 中。如果MySQL在执行事务的过程中呈现故障或者回滚操作，它能够通过 undolog 中的信息进行复原。另外，undolog 还有一个作用，通过 ReadView + undo log 实现多行版本控制(MVCC)：当读取的某一行被其余事务锁定时，它能够从undolog中剖析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。 02 redo logMySQL 的数据都是存在磁盘中的，当咱们要更新一条记录的时候，得先要从磁盘读取该记录，而后在内存中批改这条记录。批改完这条记录不是间接写回到磁盘，而是缓存起来。为此，Innodb 存储引擎设计了一个缓冲池（Buffer Pool），来进步数据库的读写性能。 Buffer Pool 是进步了读写然而Buffer Pool 是基于内存的，而内存总不牢靠，万一MySQL在执行事务的过程中遇到系统故障或者解体，还没来得及落盘的数据就会失落。为了解决这个问题，引入了redo log， undo log也是innodb引擎独有的日志，次要是为事务而筹备的，应用了 WAL 技术（Write-Ahead Logging），也就是预写日志。 它的关键点就是先写日志，再写磁盘。对应到Mysql中具体操作，就是每次更新操作，先写日志，而后更新内存数据，最初等零碎压力小的时候再进行IO更新磁盘数据。防止了每一次更新都须要进行IO操作。redo log 是保障了事务持久性的要害。 当咱们从数据库中获取到数据并对其进行批改操作之后，这个批改操作就会优先被寄存到redo log buffer中，最终就会被写入到redo log file中。后续，InnoDB 引擎会在适当的时候将redo log的写入磁盘，写入磁盘的机会是由MySQL零碎参数设置决定的，咱们能够键入上面这条SQL查看 SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';innodb_flush_log_at_trx_commit有3种值：0、1、2，默认为1。 当设置为1的时候：事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()刷到log file on disk中。这种形式即便零碎解体也不会失落任何数据，然而因为每次提交都写入磁盘，IO的性能较差。 当设置为0的时候：事务提交时不会将log buffer中日志写入到os buffer，而是每秒写入os buffer并调用fsync()写入到log file on disk中。也就是说设置为0时是(大概)每秒刷新写入到磁盘中的，当零碎解体，最多会失落1秒钟的数据。 当设置为2的时候：每次提交都仅写入到os buffer，而后是每秒调用fsync()将os buffer中的日志写入到log file on disk。 redo log 和 undo log都属于 InnoDB 存储引擎的日志，并且次要是为事务而筹备的，他们的区别在于 : redo log 记录了此次事务「实现后」的数据状态，记录的是更新之后的值； ...

本文作者具体阐明了 MySQL 8.0.34 版本在明码治理上的改良。 作者：Sri Sakthivel 本文起源：Percona 官网博客 爱可生开源社区出品。MySQL 8.0.34为咱们带来了新的明码验证参数 validate_password.changed_characters_percentage。应用此性能，咱们能够管制在 validate_password 承受用户帐户的新密码之前用户必须更改的明码中的最小字符数。本文中，提供了一些场景，展现了参数 validate_password.changed_characters_percentage 如何影响用户明码更改。 要求为了实现这一点，咱们应该启用“明码验证策略”（在 MySQL 8.0.13 中引入）。咱们能够通过应用参数 password_require_current 或在创立或更改用户时指定 PASSWORD REQUIRE CURRENT 来全局容许它。Brain Sumpter 在他的文章 MySQL 8：明码验证策略 中曾经很好地解释了这个主题。我建议您浏览它以理解无关“明码验证策略”的更多信息。就我而言，我只是启用了参数 password_require_current 来全局强制执行“明码验证策略”。 percona labs MySQL 8.0.34 > set persist password_require_current = 1;Query OK, 0 rows affected (0.05 sec) percona labs MySQL 8.0.34 > select @@password_require_current;+-----------------------------------+| @@password_require_current |+-----------------------------------+| 1 |+-----------------------------------+1 row in set (0.00 sec)一旦咱们启用 password_require_corrent 选项，咱们应该在 REPLACE 子句中提供旧明码。否则，它将不容许更改明码。将收到以下谬误： percona labs MySQL 8.0.34 > alter user 'test'@'localhost' identified by 'Test@321';ERROR 3892 (HY000): Current password needs to be specified in the REPLACE clause in order to change it.留神：对系统数据库 mysql 库具备全局 CREATE USER 和 UPDATE 权限的用户依然能够更改明码，而无需指定以后明码。创立测试环境在测试服务器中装置了 MySQL 8.0.34 版本，并装置了 validate_password 组件。 ...

作者通过一个主从复制过程中 1590 的谬误，阐明了 MySQL 8.0 在创立用户受权过程中的注意事项。 作者：王祥 爱可生 DBA 团队成员，次要负责 MySQL 故障解决和性能优化。对技术执着，为客户负责。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。故障形容DMP 收到告警：从库的 SQL 线程进行工作，MySQL 版本为 5.7.32，登录到从库查看复制信息报错如下： mysql> show slave status\G*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event …… Last_Errno: 1590 Last_Error: The incident LOST_EVENTS occured on the master. Message: REVOKE/GRANT failed while granting/revoking privileges in databases. Skip_Counter: 0 Exec_Master_Log_Pos: 12531 Relay_Log_Space: 69304 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULLMaster_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 1590 Last_SQL_Error: The incident LOST_EVENTS occured on the master. Message: REVOKE/GRANT failed while granting/revoking privileges in databases. ……从库谬误日志信息如下： ...

作者分享了一条慢 SQL 剖析和优化的过程，总结出切实有效的优化伎俩。 作者：马文斌 MySQL 爱好者。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。背景开发同学丢了一条 SQL 过去。“马哥，看看这个 SQL 是否优化，业务那边反馈很慢！”看了下执行打算+表构造，索引都没问题。那到底是怎么回事呢？咱们一起来瞧瞧。 剖析原 SQLexplain SELECT count(0)FROM invoice_sales_application aWHERE ( shop_order_id LIKE '23060919546335%' OR ( EXISTS ( SELECT 1 FROM invoice_sales_application_detail b WHERE a.application_no = b.application_no AND a.invoice_category = b.invoice_category AND b.del_flag = 0 AND b.shop_order_id LIKE '23060919546335%' ) AND a.is_merge = 1 ) )先来看看这个 SQL 是什么意思： 在 invoice_sales_application 表中，shop_order_id 以 '23060919546335%'结尾，或者存在一个相干的 invoice_sales_application_detail 表中的记录，该记录的 application_no 和 invoice_category 与 invoice_sales_application 表中的雷同，并且 shop_order_id 以 '23060919546335%' 结尾，同时 invoice_sales_application 表中的 is_merge 字段为 1。 ...

本文作者分享了Oceanbase工夫与数值类型隐式转换导致查问后果不合乎预期或“不正确”问题的排查思路。 作者：任仲禹 爱可生 DBA 团队成员，善于故障剖析和性能优化，文章相干技术问题，欢送大家一起探讨。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。之前在 OceanBase 应用中碰到了一个“令人费解”的数据类型隐式转换问题。论断比较简单，特跟大家分享下排查思路。 问题形容某客户项目组执行更新 SQL 语句时会偶发失败，报错如下： 脱敏解决后 ERROR bad SQL grammar [update renzy set at=current_timestamp,expire_at=(cast(unix_timestamp(current_timestamp(3) as unsigned) +?)), order_id= ? where id = ? and (expire_at < current_timestamp or order_id = ?)] java.sql.SQLSyntaxErrorException: (conn=1277168) Incorrect value. 查问 OceanBase 版本。 ./observer -Vobserver (OceanBase 3.2.3.2)REVISION: 105000092022092216-445151f0edb502e00ae5839dfd92627816b2b822查看表构造和数据。 MySQL [test]> show create table renzy\G*************************** 1. row *************************** Table: renzyCreate Table: CREATE TABLE `renzy` ( `id` varchar(64) NOT NULL, `at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `order_id` varchar(64) NOT NULL, `expire_at` bigint(20) NOT NULL, `vt` timestamp NOT NULL, PRIMARY KEY (`id`)) DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = 'zstd_1.3.8' REPLICA_NUM = 3 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0MySQL [test]> select * from renzy;+----+---------------------------+---------------+------------+---------------------------------+| id | at | order_id | expire_at | vt |+----+---------------------------+---------------+------------+---------------------------------+| 1 | 2023-07-07 14:57:13 | 0:16632@172.1 | 1716040750 | 2023-07-07 14:57:13 |+----+---------------------------+---------------+------------+---------------------------------+1 row in set (0.02 sec)问题排查问题 1：报错语句间接执行报错的 SQL 语句。 ...

本文将通过复制场景下的异样剖析，介绍手工搭建MySQL主从复制时须要留神的要害细节。 作者：秦福朗 爱可生 DBA 团队成员，负责我的项目日常问题解决及公司平台问题排查。酷爱互联网，会摄影、懂厨艺，不会厨艺的 DBA 不是好司机，didi~ 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。背景有人反馈装了一个数据库，来做现有库的从库。做好主从复制关系后，在现有主库上应用 show slave hosts; 治理命令去查问从库的信息时，发现从库的 IP 地址竟是本人的 IP 地址，这是为什么呢？ 因生产环境波及 IP，端口等窃密信息，以下以本地环境来还原景象。 本地复现根本信息 主库从库IP10.186.65.3310.186.65.34端口66076607版本8.0.188.0.18问题景象不多说，先上图，以下为在主库执行 show slave hosts; 呈现的景象： 能够看到这里的 Host 是主库的 IP 地址。 咱们登陆从库查看一下 show slave status\G： mysql> show slave status\G*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.186.65.33 Master_User: universe_op Master_Port: 6607 Connect_Retry: 60 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 74251749 Relay_Log_File: mysql-relay.000008 Relay_Log_Pos: 495303 Relay_Master_Log_File: mysql-bin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes咱们看到的确从库是在失常运行的，且复制的源就是主库。 ...

本文为大家整顿了墨天轮数据社区2023年6月公布的优质技术文章/文档，主题涵盖Oracle、MySQL、PostgreSQL等数据库的装置配置、故障解决、性能优化等日常实际操作，以及罕用脚本、注意事项等总结记录，分享给大家： Oracle优质技术文章概念梳理&装置配置 利用 DG 单机转RAC - 迁徙实操篇Exadata to RAC(x86) ADG（20230605）保姆级EMCC搭建教程（20230606）Oracle12c当前的在线分区操作具体解析实战oracle 19c rac部署rman备份策略ORACLE 19c Job 迁徙oracle中scn与实例复原ORACLE OEM13.5装置配置具体文档Oracle RAC Flex ASM 个性测试转行DBA，给你分享数据库运维的N条倡议（随时更新）故障解决与性能优化 【Oracle】一条看不出会删哪个表的delete语句谬误执行打算导致主机内存资源耗尽分区统计信息生效导致数据库整体性能降落案例一则)Oracle HASH JOIN 引起的TEMP爆满剖析总结Oracle中delete误操作的抢救办法非归档模式下非current redo 损坏处理办法测试Oracle期待事件curror：mutex故障剖析CRS-1006：OCR损坏导致CRSD无奈启动故障解决)11g通过xtts迁徙降级到19c（U2L）ORA-600报错解决Oracle OEM13.5装置配置具体文档性能调优:SQL执行打算扭转因为Height Balanced Histogram 的Popular ValueOracle性能优化根底MySQL、PG及国产数据库相干技术文章MySQL相干技术文章 MySQL备库复制提早的起因及解决办法mysqldump引发数据库炸裂的血案MySQL Limits 列和行大小MySQL中必须要晓得的小细节MySQL中GTID和mysqldump中set-gtid-purged到底干了什么一文具体阐明MySQL中的变量一个MySQL监控与CONNECTION_CONTROL引起的问题MySQL semi半同步模式下 模仿从库插件导致crash剖析MySQL Multi-threaded Replication并行形式解读MySQL可传输表空间性能的应用介绍【MySQL 5.7 停服影响与应答计划】徐轶韬：从MySQL5.7降级到MySQL 8.0.pdfMySQL 降级到 8.0 变慢问题剖析PG相干技术文章 PostgreSQL个性—深刻了解full-page-writes (全页写)PostgreSQL-16新个性之普通用户的保留连贯个数（reserved_connections）PostgreSQL问答-第25期PostgreSQL之主备搭建（PostgreSQL 14.2）PG 的小版本如何降级PostgreSQL16新个性之standby节点逻辑复制验证PostgreSQL对SQL:2023规范反对状况国产数据库相干技术文章 搭建TiDB负载平衡环境-HAproxy+KeepAlived实际国产数据库|GBase 8c 常见对象及数据类型和函数学习笔记GBCA (Galaxybase) 认证学习材料内参如何在openGauss/PostgreSQL手动清理XLOG/WAL 文件?西方通 | 基于TongWeb中间件适配革新实战)达梦数据库读写拆散集群原理和注意事项信创适配 | SQL Server 迁徙适配人大金仓这些文章中有大家日常会遇到的操作、故障解决，文章构造残缺、逻辑清晰，其中故障解决主题类文章均蕴含问题景象（具体报错等）、问题定位与剖析 、 问题解决、问题总结等几个方面，可参考价值很强，心愿对大家有所帮忙。 墨天轮数据社区是一个业余的数据技术内容分享社区，会集了来自各行业的专家大咖、一线技术人员，他们勤于记录、乐于分享，公布了泛滥国内外数据库技术相干的优质实操文章、文档。在这里，咱们定期将为大家整顿墨天轮网站上的优质内容，以月度进行公布展现。若您想每日获取最新技术干货，也可增加墨天轮小助手（VX：modb666）理解征询。 另外，墨天轮社区正在举办“墨力原创作者打算”，收集了不少对于Oracle、MySQL、PG以及国产数据库相干的实操文章投稿，欢送大家点击此处查阅全副文章。另外也欢送大家退出投稿，咱们筹备了合格奖、新人奖、勤更奖等的现金、礼品的处分，点击此处理解流动详情。

作者：卢文双 资深数据库内核研发 序言： 以前对 MySQL 测试框架 MTR 的应用，次要集中于 SQL 正确性验证。近期因为工作须要，深刻理解了 MTR 的方方面面，发现 MTR 的能力不仅限于此，还反对单元测试、压力测试、代码覆盖率测试、内存谬误检测、线程竞争与死锁等性能，因而，本着分享的精力，将其总结成一个系列。 次要内容如下： 入门篇：工作机制、编译装置、参数、指令示例、举荐用法、增加 case、常见问题、异样调试进阶篇：高阶用法，包含单元测试、压力测试、代码覆盖率测试、内存谬误检测、线程竞争与死锁源码篇：剖析 MTR 的源码语法篇：单元测试、压力测试、mysqltest 语法、异样调试因为集体程度无限，所述不免有谬误之处，望雅正。 本文是第四篇语法篇。 本文首发于 2023-07-05 21:53:21MTR 系列基于 MySQL 8.0.29 版本，如有例外，会特地阐明。 单元测试简介前文「MySQL 测试框架 MTR 系列教程（二）：进阶篇 - 内存/线程/代码覆盖率/单元/压力测试」已介绍了单元测试的概念及应用办法，简略回顾一下： MySQL 应用 TAP（Test Anything Protocol） 和 Google Test Framework 来实现单元测试。 TAP 是 Perl 与测试模块之间所应用的简略的基于文本的接口。为了实现 C/C++ 的单元测试，MySQL 开发了一个用于生成 TAP 文本的库libmytap.a，源码门路位于unittest/mytap/。应用办法：在执行 cmake 的目录执行 make test或make test-unit 指令（内容具体，更举荐）。注意事项：在执行单元测试时，不倡议启用 ASAN，否则会因 ASAN 检测到单元测试代码有内存透露而导致 case 失败。unittest/ 目录介绍： CMakeLists.txtexamples # 寄存单元测试示例gunit # 寄存所有单元测试用例的代码mytap # 寄存 MyTAP 协定代码如果新加的测试用例与存储引擎或插件无关，则别离寄存在unittest/engine_name 和unittest/plugin_name目录或它们的子目录中。 ...

作者：卢文双 资深数据库内核研发 序言： 以前对 MySQL 测试框架 MTR 的应用，次要集中于 SQL 正确性验证。近期因为工作须要，深刻理解了 MTR 的方方面面，发现 MTR 的能力不仅限于此，还反对单元测试、压力测试、代码覆盖率测试、内存谬误检测、线程竞争与死锁等性能，因而，本着分享的精力，将其总结成一个系列。 次要内容如下： 入门篇：工作机制、编译装置、参数、指令示例、举荐用法、增加 case、常见问题、异样调试进阶篇：高阶用法，包含单元测试、压力测试、代码覆盖率测试、内存谬误检测、线程竞争与死锁源码篇：剖析 MTR 的源码语法篇：单元测试、压力测试、mysqltest 语法、异样调试因为集体程度无限，所述不免有谬误之处，望雅正。 本文是第三篇源码篇。 本文首发于 2023-06-05 22:03:44MTR 系列基于 MySQL 8.0.29 版本，如有例外，会特地阐明。 简介首先回顾一下MySQL 测试框架次要蕴含的组件： mysql-test-run.pl ：perl 脚本，简称 mtr，是 MySQL 最罕用的测试工具，负责管制流程，包含启停、辨认执行哪些用例、创立文件夹、收集后果等等，次要作用是验证 SQL 语句在各种场景下是否返回正确的后果。mysqltest ：C++二进制程序，负责执行测试用例，包含读文件、解析特定语法、执行用例。用例的非凡语法（比方，--source，--replace_column等）都在command_names和enum_commands两个枚举构造体中。mysql_client_test ：C++二进制程序，用于测试 MySQL 客户端 API（mysqltest 无奈用于测试 API）。mysql-stress-test.pl ：perl 脚本，用于 MySQL Server 的压力测试。反对 gcov/gprof 代码覆盖率测试工具。除此之外，还提供了单元测试工具，以便为存储引擎和插件创立独自的单元测试程序。 各个组件的地位如下： 源码地位装置目录地位mysql-test/mysql-test-run.plmysql-test/mysql-test-run.plclient/mysqltest.ccbin/mysqltesttestclients/mysql_client_test.ccbin/mysql_client_testmysql-test/mysql-stress-test.plmysql-test/mysql-stress-test.pl源码剖析基本原理简要回顾一下 MTR 的基本原理： SQL 正确性：比照（diff）冀望输入和理论输入，若完全一致，则测试通过；反之，测试失败。 高级用法：以下工具都须要在编译时启用对应的选项。 valgrind：mtr 依据传参拼接 valgrind 指令的形式来测试。ASAN：蕴含编译器插桩模块，还有一个运行时的库用来替换 malloc 函数。插桩模块次要用在栈内存上，而运行时库次要用在堆内存上。MSAN：外围是编译插桩，同时还有一个运行时库，用来在启动时，将低地址内存设置为不可读，而后映射为影子内存。UBSAN：在编译时对可疑操作进行插桩，以捕捉程序运行时的未定义行为。同时，还有一个额定的运行时库。gcov/gprof：mtr 依据传参拼接相干指令来测试。单元测试：通过 mtr 调用 mysqltest，再调用 xx-t 等生成的二进制文件。更多内容请参考本系列「（一）入门篇」及「（二）进阶篇」。 ...

作者通过全面零碎的测试，揭秘 lower_case_table_names 设置对数据一致性的影响。 作者：刘安 爱可生测试团队成员，次要负责 DTLE 开源我的项目相干测试工作，善于 Python 自动化测试开发。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。背景最近有客户询问：源端 MySQL 和指标端 MySQL 的 lower_case_table_names 的配置不统一时，DTLE 是否能失常同步数据？ 本文就这个问题测试一下 lower_case_table_names 的设置对 DTLE 同步数据的影响。 为了简化场景这里只探讨 Linux 环境下 lower_case_table_names 配置为 0 或 1 的状况。环境筹备部署 DTLE 4.23.04.2两个 MySQL 实例，lower_case_table_names 配置不同# lower_case_table_names=0$ dbdeployer deploy single 5.7 --port 3306 --sandbox-directory sandbox --port-as-server-id --remote-access % --bind-address 0.0.0.0 -c skip-name-resolve -c binlog_format=ROW -c binlog_row_image=FULL -c log_slave_updates=ON --gtid -c lower_case_table_names=0# lower_case_table_names=1$ dbdeployer deploy single 5.7 --port 3306 --sandbox-directory sandbox --port-as-server-id --remote-access % --bind-address 0.0.0.0 -c skip-name-resolve -c binlog_format=ROW -c binlog_row_image=FULL -c log_slave_updates=ON --gtid -c lower_case_table_names=1第一种状况源端 MySQL @@lctn=0指标端 MySQL @@lctn=1依据 DTLE 的开发文档 可知，此种状况下的 DTLE 行为： ...

到底是什么起因，导致主从切换过程中存在一个无奈 kill 的会话？ 作者：秦广飞 爱可生 DBA 团队成员，负责我的项目日常问题解决及公司平台问题排查，对数据库有趣味，对技术有想法。一入 IT 深似海，从此节操是路人。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。背景照例要先讲下本文档背景的，不过在介绍背景之前，先简略说下 MySQL 主从切换的过程。 失常来说，当要产生主从切换时，主库要做上面几个动作： 断开流量入口（解绑 VIP）设置只读Kill 掉数据库残留连贯而从库，要做上面几个动作： 补全与主库差别的 binlog 日志敞开只读革除复制信息开启流量入口（绑定 VIP）咱们公司自研的数据库集群治理平台 云树® DMP 大略也是这么个切换过程，而这个切换过程跟本文的关联点，就在主库 Kill 掉残留连贯上。 偶然间发现，DMP 在切换过程中 Kill 残留连贯时，日志中有时会呈现 warn 信息：[warn] kill process warning：Error 1094：Unknown thread id：4 起初察看到，MySQL 5.7 的主从切换时，就不会呈现这个 warning 信息，而 MySQL 8.0 就会稳固复现。进一步测试验证后，终于发现了这个 Unknown thread id 的真面目，就是 USER 为 event_scheduler 的这个"连贯"。 什么是 event_scheduler？event_scheduler 到底是什么呢？毕竟从 processlist 信息中能够看到，它与一般的会话仿佛不太一样。 其实它是 MySQL 中的一个非凡线程，次要负责执行 MySQL 事件调度器所创立的事件。咱们晓得 MySQL 是有 event 的，能够像 Linux 中 crontab 一样，定时执行一些工作。 ...

buffer pool进步读写性能缓冲池是一片内存区域，存储引擎在读取数据时，会先将页读取到缓冲池中。下次读取时，先判断是否在缓冲池，如果在，则间接读取，否则从磁盘中读取。在批改数据时，如果缓冲池中不存在所需的数据页，则从磁盘读入缓冲池，否则间接对缓冲池中的数据页进行批改。因为这个刷脏页的过程还是异步的，这样更新操作就不须要期待磁盘的 IO 操作了。因而这些特点极大地晋升了 InnoDB 的性能。 大小默认是128MB,能够依据物理内存调整,个别倡议设置为60%~80% 内容 治理 如何进步缓存命中率采纳相似LRU算法,然而LRU算法有两个问题 预读生效MySQL 在加载数据页时，会提前把它相邻的数据页一并加载进来，目标是为了缩小磁盘 IO。然而可能这些被提前加载进来的数据页，并没有被拜访，相当于这个预读是白做了，这个就是预读生效解决:改良了 LRU 算法，将 LRU 划分了 2 个区域：old 区域 和 young 区域。 过程:划分这两个区域后，预读的页就只须要退出到 old 区域的头部，当页被真正拜访的时候，才将页插入 young 区域的头部。如果预读的页始终没有被拜访，就会从 old 区域移除，这样就不会影响 young 区域中的热点数据。 buffer pool净化比方，在一个数据量十分大的表，执行了这条语句： select * from t_user where name like "%xiaolin%";过程: 从磁盘读到的页退出到 LRU 链表的 old 区域头部；当从页里读取行记录时，也就是页被拜访的时候，就要将该页放到 young 区域头部；接下来拿行记录的 name 字段和字符串 xiaolin 进行含糊匹配，如果符合条件，就退出到后果集里；如此往返，直到扫描完表中的所有记录。通过这一番折腾，本来 young 区域的热点数据都会被替换掉。怎么解决呈现 Buffer Pool 净化而导致缓存命中率降落的问题？MySQL 是这样做的，进入到 young 区域条件减少了一个停留在 old 区域的工夫判断。具体是这样做的，在对某个处在 old 区域的缓存页进行第一次拜访时，就在它对应的管制块中记录下来这个拜访工夫： 如果后续的拜访工夫与第一次拜访的工夫在某个工夫距离内，那么该缓存页就不会被从 old 区域挪动到 young 区域的头部；如果后续的拜访工夫与第一次拜访的工夫不在某个工夫距离内，那么该缓存页挪动到 young 区域的头部；binlogbinlog 是 MySQL 服务器层面实现的一种二进制日志，用于记录所有对数据库的增删改操作,次要有两个作用 ...

本文次要记录了MySQL治理端口无奈登录的排查过程，以及预防 too many connections 的一些倡议。 作者：吕虎桥 爱可生DBA 团队成员，次要负责 DMP 平台和 MySQL 数据库的日常运维及故障解决。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。背景形容MySQL 8.0.14 版本中引入了 admin_port 参数，用于提供一个治理端口来解决 too many connections 报错。最近一套 MySQL 8.0 实例呈现 too many connections 报错，尝试通过治理端口登录，然而依然提醒该报错。跟业务部门协商之后，调大了连接数，重启数据库复原业务。为什么配置了 admin_port 却没有失效呢，带着疑难做了如下测试。 场景复现治理端口相干参数--创立一个独自的 listener 线程来监听 admin 的连贯申请create_admin_listener_thread = 1 --监听地址admin_address = localhost --监听端口，默认为 33062，也能够自定义端口admin_port = 33062 --配置好参数，重启数据库失效systemctl restart mysqld_3306 --测试 root 账号是否能够通过 33062 端口登录[root@mysql ~]# mysql -uroot -p -S /data/mysql/data/3306/mysqld.sock -P33062 -e 'select version()'Enter password:+-----------+| version() |+-----------+| 8.0.33 |+-----------+模仿故障景象调小 max_connections 参数，模仿呈现 too many connections 报错。 ...

拜访办法的概念设计MySQL的大叔把MySQL执行查问语句的形式称为拜访办法（access method）或者拜访类型。同一个查问语句能够应用多种不同的拜访办法来执行，尽管最初的查问后果都是一样的，然而不同的执行形式话费的工夫老本可能差距甚大。就像是从北京南锣鼓巷到什刹海，你能够打车去，也能够坐地铁去，坐公交去，还能够骑共享单车去，当然也能够走着去。 表构造CREATE TABLE single_table( id int not null auto_increment, key1 VARCHAR(100), key2 int, key3 VARCHAR(100), key_part1 VARCHAR(100), key_part2 VARCHAR(100), key_part3 VARCHAR(100), common_field VARCHAR(100), PRIMARY KEY(id), key idx_key1(key1), unique key uk_key2(key2), key idx_key3(key3), key idx_key_part(key_part1,key_part2,key_part3))engine=INNODB charset=utf8mb4const有时须要通过主键列定位一条记录，如下： select * from single_table where id = 12;MySQL会间接利用主键值在聚簇索引中定位对应的用户记录，如下： 与之相似，咱们依据惟一二级索引列来定位一条记录的速度也是贼快的。比方上面的查问： select * from single_talbe where key2 = 12;这个查问的执行过程的示意图如下： 能够看到这个查问的执行分为上面两步： 步骤1. 在uk_key2对应的B+树索引中，依据key2列与常数的等值比拟条件定位到一条二级索引记录。步骤2. 而后再依据该记录的id值到聚簇索引中获取到残缺的用户记录。设计MySQL的大叔认为，通过主键或者惟一二级索引列与常数的等值比拟来定位一条记录像是坐火箭一样快的，所以他们把这种通过主键或者惟一二级索引列来定位一条记录的拜访办法定义为const（意思是常数级别的，代价是能够忽略不计的）。不过这种const拜访办法只能在主键列或者惟一二级索引列与一个常数进行等值比拟时才无效。如果主键或者惟一二级索引的索引列由多个列形成，则只有在索引列中的每一个列都与常数进行等值比拟时，这个const拜访办法才无效（这是因为只有在该索引的每一个列都采纳等值比拟时，才能够保障最多只有一条记录合乎搜寻条件）。 对于惟一二级索引来说，在查问列为null值时，状况比拟非凡。比方上面这样： select * from single_table where key2 is null;因为惟一二级索引列并不限度null值的数量，所以上述语句可能拜访到多条记录。也就是说下面这个语句不能够应用const拜访办法来执行。

OceanBase 环境根本都会先装置 OCP 来部署、监控、运维数据库集群。但如果有机器过保等问题，就须要有安稳的 OCP 节点的替换计划。 作者：张瑞远 上海某公司 DBA，已经从事银行、证券数仓设计、开发、优化类工作，现次要从事电信级 IT 零碎及数据库工作。有三年以上 OceanBase 工作教训。取得的专业技能与认证包含 OceanBase OBCP、Oracle OCP 11g、OracleOCM 11g 、MySQL OCP 5.7。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。前言OceanBase 云平台（OceanBase Cloud Platform，OCP），是以 OceanBase 为外围的企业级数据库治理平台。 咱们生产环境根本都是须要先创立 OCP 平台，而后依赖 OCP 去创立及治理监控生产集群，所以装置 OCP 个别是零碎上线的第一步。之后可能随着机房布局等问题，就会有须要搬迁或者替换 OCP 的机器的需要。 别离介绍两种 OCP 节点的替换办法。一种是应用 OAT 平台（OceanBase Admin Toolkit，管理者工具）来替换；另一种就是应用 ANTMAN 工具替换。上次咱们介绍了第一种 OAT 的计划，本文介绍第二种。 PS：我的环境的 OCP 负载平衡应用的 F5，所以新的机器须要先配置 F5，其余负载平衡场景同理。环境背景大家如果有接触 OB 生产环境的教训的话，可能会理解，后期版本在装置 OCP 的时候，须要装置 OCP 软件/metadb/obproxy 三个 Docker 包，前期 OCP 版本将 DB+Proxy 集成在了一个 Docker 包里，OAT 的话只能纳管 DB + Proxy。集成的 metadb，离开的状况还须要应用 ANTMAN 工具来替换。 ...

MySQL数据库提供了多种工夫类型，能够依据需要抉择适宜的类型。以下是MySQL数据库中常见的工夫类型： DATE：用于存储日期，包含年、月、日。范畴是从'1000-01-01'到'9999-12-31'。TIME：用于存储工夫，包含时、分、秒。范畴是从'-838:59:59'到'838:59:59'。DATETIME：用于存储日期和工夫的组合，包含年、月、日、时、分、秒。范畴是从'1000-01-01 00:00:00'到'9999-12-31 23:59:59'。TIMESTAMP：用于存储日期和工夫的组合，包含年、月、日、时、分、秒。范畴是从'1970-01-01 00:00:01'到'2038-01-19 03:14:07'。特地的，TIMESTAMP类型会主动转换为UTC工夫进行存储和检索，但在显示时会依据以后会话的时区进行转换。YEAR：用于存储年份，只包含年。范畴是从1901到2155。依据具体的需要，抉择适合的工夫类型： 如果只需存储日期，如生日等，能够抉择DATE类型。如果只需存储工夫，如持续时间等，能够抉择TIME类型。如果须要同时存储日期和工夫，但不须要时区转换和自动更新性能，能够抉择DATETIME类型。如果须要存储日期和工夫，并心愿主动转换为UTC工夫和自动更新性能，能够抉择TIMESTAMP类型。如果只须要存储年份，能够抉择YEAR类型。须要留神的是，在抉择工夫类型时，还要思考数据存储的范畴、精度和性能等因素。对于较大的工夫范畴和更高的精度要求，能够抉择DATETIME或TIMESTAMP类型。对于较小的工夫范畴和更低的精度要求，能够抉择DATE或TIME类型。 综合思考需要和数据个性，抉择适合的工夫类型能够更好地满足数据库设计和利用需要。

MYSQL介绍主从架构— —概念binlog日志MySQL的二进制日志能够说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查问语句)语句，以事件模式记录，还蕴含语句所执行的耗费的工夫。 复制原理主库操作保留binlog日志从库的IO线程从主库拉取binlog日志，并生成中继日志(relay log)从库的SQL线程解析中继日志，并在自身回放 状态查看次要通过判断IO线程和SQL线程是否处于Running判断复制是否失常,判断Seconds_Behind_Master参数代表数据同步是否提早：mysql> show slave status\G...       Slave_IO_Running: YesSlave_SQL_Running: YesSeconds_Behind_Master: 0...  主从架构— —衍生各种扩大的主从架构1. 一主多从2. 双主复制 级联复制 等等读写拆散大部分场景下，读的频率比写的频率会高很多。所以能够通过扩大多个SLAVE节点进步整体的使用性能。数据备份传统的备份包含三种形式：1. lvm snapshot(LVM快照备份)2. mysqldump3. Xtarbackup那么要如何实现数据的一致性备份呢(一致性备份是所有数据/文件/磁盘 须要在同一个工夫点进行备份)LVM SNAPSHOT1. 执行FTWRL(FLUSH TABLES WITH READ LOCK)1.1上全局读锁(lock_global_read_lock)1.2清理表缓存(close_cached_tables)1.3上全局COMMIT锁(make_global_read_lock_block_commit)2. 执行lvcreate 创立lv快照.3. UNLOCK TABLES解锁 MYSQLDUMP开启可反复读事务隔离开启事务建设数据快照(能够了解为select  from )完结事务 XTRABACKUP1. 不是整体采纳备份锁，只有特定阶段。2. indodb阶段不须要加锁，ACID的C(持续性)是通过Redo log实现，通过线程增量记录redo log实现。

在 2023 年 10 月 21 日，MySQL 5.7将达到其生命周期的起点（EOL,End of Life）。这意味着Oracle将不再为MySQL 5.7提供官网更新、谬误修复或安全补丁。 自公布以来，MySQL 5.7成为了许多利用开发者的首选的数据库，但突飞猛进的数据利用场景和技术也对数据库技术栈提出了新的需要。随着 MySQL 5.7 EOL 到来，降级到一个更高版本、且有官网反对的 MySQL 仿佛是最间接的计划，但是否有其余抉择呢？咱们是否能够找到一个既能满足当下一直倒退的数据处理需要，又能克服以后 MySQL 技术限度的完满代替计划？ 本文将介绍一些可能的代替计划的优缺点，重点探讨分布式数据库（如 TiDB）的架构劣势。 MySQL的倒退及面临的挑战当下，数据价值越来越受到企业的器重，“数据驱动”也成为了一个重要的课题，事务性数据处理形式在过来十年中产生了巨大变化，实时、海量的事务处理日益成为支流，同时对从这些数据中取得即时的剖析和洞察的需要也仍然存在。然而，MySQL在应答这些一直演进的需要时存在一些局限性： 扩展性：面向写入密集型应用程序，MySQL的性能变得不稳固。当数据规模超过单个节点的容量时，性能会受到影响。高可用性：尽管MySQL提供了复制和集群等性能以实现高可用性，但要无效地设置和治理这些性能须要认真布局、配置和继续监控。此外，传统的MySQL复制可能呈现提早，进而导致数据不统一。实时剖析：随着企业对事务性数据的实时洞察的需要减少，在MySQL架构中将联机事务处理（OLTP）和在线剖析解决（OLAP）零碎拆散的架构会产生性能上的瓶颈。剖析查问可能会影响事务处理的性能。而应用独自的剖析数据库解决这些查问则减少了技术栈复杂性。应答古代架构：古代架构向云原生和微服务的转变对 MySQL 这样的单机零碎提出了挑战。当企业的基础设施无奈满足需要，数据规模从1TB增长到100TB+，同时仍冀望放弃雷同的性能时，这些限度带来的不便就愈发显著。 摸索代替计划：MySQL 5.7 EOL 后，何去何从？随着 MySQL 5.7 EOL 行将到来，当初是从新评估抉择并为将来的数据处理能力做好筹备的时候了。 Option 1：降级到官网反对的 MySQL 版本这波及从MySQL 5.7迁徙到较新版本，如MySQL 8.0，由Oracle 提供保护和反对。 长处：这个选项确保了对现有 MySQL 架构的继续反对，可能继续获取新性能和性能改良。通常，这是最简略的抉择，因为它对现有基础设施和利用代码的改变较少。 毛病：降级到较新版本的MySQL并不能解决 MySQL 架构导致的扩展性、高可用性和解决古代云原生架构相干的固有挑战。同时，它还依赖于Oracle接下来的策略方向，比方对MySQL产品的反对力度。 Option 2: 采纳第三方 MySQL 商业版本像MariaDB 和 Percona Server这样的MySQL分支版本是由第三方公司独立开发，为MySQL用户提供了代替门路。 长处：这些分支版本通常可能比MySQL自身更快地引入性能和性能改良。转向分支版本能够仍旧获取继续的反对、与MySQL兼容的个性的相熟性以及潜在的加强性能。 毛病：与MySQL一样，这些分支版本在解决高并发的写入密集型工作负载，或在分布式架构中部署时仍面临挑战。此外，反对的力度可能有所不同，一些企业可能不违心对由社区驱动的我的项目提供更多的反对。 Option 3: 迁徙到分布式数据库如果现有的应用程序须要超出单个 MySQL 实例所能提供的可扩展性和高可用性，那么分布式数据库（如 TiDB）可能是一个适合的抉择。 长处：分布式数据库将传统关系型数据库管理系统（RDBMS）的长处（ACID 个性、对 SQL 的反对）与 NoSQL 零碎的长处（程度可扩展性、高可用性）联合在一起。特地是 TiDB，齐全兼容 MySQL 5.7，使得迁徙变得更加容易。 ...

mysql 中的事务提交autocommit 的阐明默认autocommit=ON 是开启的，开启状态下如果没有显示的的进行事务begin, 每条sql 语句都会主动提交事务； 敞开状态下， 如果没有手动进行commit, 那么sql 不会提交；show variables like 'autocommit'；set @@autocommit=1;begin 与autocommit 的关系；begin 显示的开启事务，会禁用autocommit;屡次begin如果第一个begin 事务没有被动提交，第二个begin会提交第一个begin 的事务；pymysql 中的事务提交；autocommit 的阐明默认pymysql 的连贯， autocommit=False 的，因而须要手动提交commit, 否则你的sql将不会提交哦pymysql 的autocommit 实质上，是连贯通过批改mysql 的autocommit 属性来实现的；可通过Connection 的初始化参数autocommmit 来批改默认配置；避免屡次begin 的解决因为个别应用pymysql，会搭配连接池来应用，因为如果一个线程，begin的事务处理到一半，产生了异样，你只是开释了连贯(开释的解决中没有rollback操作)，没有进行rollback, 另外一个线程获取到这个连贯后进行begin,会造成后面一个事务进行提交，从而可能产生脏数据；通常，咱们会解决__exit__ 办法，当产生异样是，进行rollback;

应用mysql 将数据迁徙到pgsql1. 间接应用在线的脚本转化器 sqllines online 地址     长处就是疾速麻利,在线编辑;毛病在于,有的转换可能不准,只有学习的意义.且在线工具如果粘贴的文本过大会很卡 且翻译不进去(能够下载它的客户端工具进行操作) 2. 应用navicate在线迁徙这种搞法就是适宜有源库,且表的个数超过了100(比拟多),间接点开客户端工具中的数据迁徙 这里的操作因人而异 值得要留神的一点就是navicate的同步过程中会有一些问题,我遇到的:1.全副的索引间接失败,报错找不到对应的表2.转换的对象的大小写须要设置一下(懂的都懂)3.转换的建表语句中的默认值间接没了?4.外键束缚中的delete cascade 间接变成了 delete no action 所以我倡议如果遇到这种状况,间接先只同步构造和数据 实现当前再独自同步索引和(外键)束缚 和自增序列 2.1 获取主键自增序列SELECT concat('create sequence ',a.name,'_seq',' INCREMENT 1 START 1 NO MINVALUE NO MAXVALUE;')FROM (SELECT table_name as name FROM information_schema.columns WHERE table_schema = 'your_schema_name' -- schema的名称and COLUMN_NAME = 'id' -- 字段为id)a; 2.2 获取索引的创立SELECT CONCAT('CREATE ',if(a.non_unique = 1,'INDEX ','UNIQUE INDEX '),a.INDEX_NAME,' ON ',a.TABLE_NAME,' using btree',' (',a.index_column,');')FROM (select TABLE_NAME, non_unique,INDEX_NAME, GROUP_CONCAT(COLUMN_NAME) as INDEX_COLUMNfrominformation_schema.statisticswheretable_schema='your_schema_name' -- 数据库名AND index_name <> 'PRIMARY' -- 将主键去掉GROUP BY TABLE_NAME, INDEX_NAME,non_unique) a ...

作者通过一个慢日志问题，引出 MySQL 半一致性读的概念及理论利用场景。 作者：龚唐杰 爱可生 DBA 团队成员，次要负责 MySQL 技术支持，善于 MySQL、PG、国产数据库。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。背景某零碎执行更新操作发现很慢，发现有大量慢日志，其中 Lock time 工夫占比很高，MySQL 版本为 5.7.25，隔离级别为 RR。 剖析查看表构造以及 UPDATE 语句的执行打算： mysql> show create table test;+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| Table | Create Table |+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| test | CREATE TABLE `test` (`id` int(11) NOT NULL AUTO_INCREMENT,`name` varchar(30) COLLATE utf8mb4_bin DEFAULT NULL,PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=2621401 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin |+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+1 row in set (0.00 sec)mysql> explain update test set name ='test' where name='a';+----+-------------+-------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+-------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+| 1 | UPDATE | test | NULL | index | NULL | PRIMARY | 4 | NULL | 2355988 | 100.00 | Using where |+----+-------------+-------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+1 row in set (0.00 sec)通过执行打算发现，该 SQL 是走的主键全索引扫描，并且对于 name 列未加索引，当多个事务同时执行时，就会察看到有阻塞呈现。 ...

本文次要以 MySQL 和 OceanBase 比照的形式，来介绍 OceanBase（MySQL 模式）平安体系中对于用户治理和访问控制的相干内容，包含用户治理、用户操作权限管制、网络安全访问控制、行级权限管制、角色治理。 作者：金长龙 爱可生测试工程师，负责 DMP 产品的测试工作。 本文起源：原创投稿 * 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文次要以 MySQL 和 OceanBase 比照的形式，来介绍 OceanBase（MySQL 模式）平安体系中对于用户治理和访问控制的相干内容，包含用户治理、用户操作权限管制、网络安全访问控制、行级权限管制、角色治理。 用户治理1.1 基本概念租户OceanBase 数据库租户是一个逻辑概念，是资源分配的单位。OceanBase 数据库租户间的数据是齐全隔离的，每个租户都相当于传统数据库的一个数据库实例。 OceanBase 数据库租户分为：零碎租户和一般租户。 OceanBase 数据库预约义了用于治理的零碎租户（sys 租户），其兼容模式为 MySQL一般租户又分为 Oracle 模式租户和 MySQL 模式租户用户OceanBase 数据库用户分为：零碎租户用户和一般租户用户。 零碎租户的内置系统管理员为用户 rootMySQL 租户的内置租户管理员为用户 rootOracle 租户的内置租户管理员为用户 sys创立用户时，如果以后会话的租户为零碎租户，则新建的用户为零碎租户用户，反之为一般租户用户1.2 用户名称语法用户名称呈现在 SQL 语句中（如：CREATE USER, GRANT, SET PASSWORD）须要遵循一些规定，测试这些规定在 OceanBase 和 MySQL 中的体现是否统一。 OceanBase# 用户名称语法为 'user_name'@'host_name'obclient [oceanbase]> create user 'test01'@'%' identified by '123456';Query OK, 0 rows affected (0.017 sec) # @'host_name' 局部是可选的obclient [oceanbase]> create user test02;Query OK, 0 rows affected (0.017 sec) # 如果用户名和主机名作为不带引号的标识符是非法的，则无需将其引号括起来。如果 user_name 字符串蕴含特殊字符（如空格或 -），或者 host_name 字符串蕴含特殊字符或通配符（如 . 或 %），则必须应用引号obclient [oceanbase]> create user test02@%;ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your OceanBase version for the right syntax to use near '%' at line 1obclient [oceanbase]> create user test02@sun;Query OK, 0 rows affected (0.027 sec) # 主机值能够是主机名或 IP 地址（IPv4 或 IPv6）obclient [oceanbase]> create user 'test02'@'127.0.0.1';Query OK, 0 rows affected (0.021 sec) # 主机名或 IP 地址值中容许应用 % 和 _ 通配符obclient [oceanbase]> create user 'test02'@'%.mysql.com';Query OK, 0 rows affected (0.016 sec) # 对于指定为 IPv4 地址的主机值，能够提供一个网络掩码来批示要用于网络号的地址位数obclient [oceanbase]> CREATE USER 'test02'@'198.51.100.0/255.255.255.0';Query OK, 0 rows affected (0.017 sec) # 指定为 IPv4 地址的主机值能够应用 CIDR 表示法写入obclient [oceanbase]> CREATE USER 'test02'@'198.51.100.0/24';Query OK, 0 rows affected (0.028 sec)MySQL# 用户名称语法为'user_name'@'host_name'mysql [localhost:8031] {msandbox} ((none)) > create user 'test01'@'%' identified with mysql_native_password by '123456';Query OK, 0 rows affected (0.03 sec) # @'host_name' 局部是可选的mysql [localhost:8031] {root} ((none)) > create user test02;Query OK, 0 rows affected (0.03 sec) # 如果用户名和主机名作为不带引号的标识符是非法的，则无需将其引号括起来。如果 user_name 字符串蕴含特殊字符（如空格或 -），或者 host_name 字符串蕴含特殊字符或通配符（如 . 或 %），则必须应用引号mysql [localhost:8031] {root} ((none)) > create user test02@%;ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '%' at line 1mysql [localhost:8031] {root} ((none)) > create user test02@sun;Query OK, 0 rows affected (0.03 sec) # 主机值能够是主机名或 IP 地址（IPv4 或 IPv6）mysql [localhost:8031] {root} ((none)) > create user 'test02'@'127.0.0.1';Query OK, 0 rows affected (0.01 sec) # 主机名或 IP 地址值中容许应用 % 和 _ 通配符mysql [localhost:8031] {root} ((none)) > create user 'test02'@'%.mysql.com';Query OK, 0 rows affected (0.03 sec) # 对于指定为 IPv4 地址的主机值，能够提供一个网络掩码来批示要用于网络号的地址位数mysql [localhost:8031] {root} ((none)) > CREATE USER 'test02'@'198.51.100.0/255.255.255.0';Query OK, 0 rows affected (0.02 sec) # 从 MySQL 8.0.23 开始，指定为 IPv4 地址的主机值能够应用 CIDR 表示法写入mysql [localhost:8031] {root} ((none)) > CREATE USER 'test02'@'198.51.100.0/24';Query OK, 0 rows affected (0.04 sec)测试后果：体现统一。 ...

作者：余振兴 爱可生 DBA 团队成员，热衷技术分享、编写技术文档。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。背景信息在数据迁徙或者数据库低版本升级到高版本过程中，常常会遇到一些因为低版本数据库参数设置过于宽松，导致插入的工夫数据不符合规范的状况而触发报错，每次报错再发现解决起来较为麻烦，是否有提前发现这类不标准数据的办法，以下基于 Oracle 和 MySQL 各提供一种可行性计划作为参考。Oracle 工夫数据校验办法2.1 创立测试表并插⼊测试数据CREATE TABLE T1(ID NUMBER,CREATE_DATE VARCHAR2(20));INSERT INTO T1 SELECT 1, '2007-01-01' FROM DUAL;INSERT INTO T1 SELECT 2, '2007-99-01' FROM DUAL; -- 异样数据INSERT INTO T1 SELECT 3, '2007-12-31' FROM DUAL;INSERT INTO T1 SELECT 4, '2007-12-99' FROM DUAL; -- 异样数据INSERT INTO T1 SELECT 5, '2005-12-29 03:-1:119' FROM DUAL; -- 异样数据INSERT INTO T1 SELECT 6, '2015-12-29 00:-1:49' FROM DUAL; -- 异样数据2.2 创立对该表的谬误日志记录Oracle 能够调用 DBMS_ERRLOG.CREATE_ERROR_LOG 包对 SQL 的谬误进行记录，用来记录下异样数据的状况，非常好用。参数含意如下 ...

在开发中，咱们常常会见到指标的数据库不间接凋谢3306到公网，然而在某些场景下又得须要指标数据库的数据，备份导出又存在诸多不便的状况。 近程数据库数据上有规范数据，本地只有MOCK数据近程数据库体量大，导入导出数据慢须要合作配合，本地数据库不共享当初介绍一种计划，使得本地直连近程数据库，然而又不开发3306端口到公网 筹备清单 一台公开的服务器，凋谢22端口即可，可能内网连贯指标数据库启动终端，执行 ssh -N -L 3309:数据库IP:3306 username@服务器ip -p 22下面的代码代表 通过 服务器IP的22端口，作为通道，将本地的 3309端口映射到 数据库IP的3306端口上。 这样子，你的开发程序就能够间接连贯本地 3309 端口上的服务器，相当于连贯了线上的服务器了。

mvccmvcc的次要作用:在特定隔离级别下,进步mysql的读写的并发能力 快照读读未提交事务不须要隔离 读已提交mvcc+view实现:查问一条数据时，事务生成这个ReadView,依据视图和undoLog中的版本号和删除版本号来判断是否可见,同时满足上面两个条件才对本事务可见 undolog的creator_id满足条件delete_id须要大于本事务id可反复读mvcc+view实现:开启事务时，事务生成ReadView,依据视图和undoLog中的版本号和删除版本号来判断是否可见,同时满足上面两个条件才对本事务可见 undolog的creator_id满足条件delete_id须要大于本事务id以后读读未提交事务不须要隔离 读已提交可应用与快照读雷同计划 可反复读应用mvcc+间隙锁实现,尽量避免幻读 能防止幻读的场景在可反复读的隔离级别下,应用以后读,innodb会应用间隙锁来锁住全表或者某几个间隙(看应用什么索引)例如select for update where id > 8;db会生成间隙锁,防止其余事务插入id>8的记录,这样防止幻读 不能防止幻读场景对于快照读， MVCC 并不能完全避免幻读景象。因为当事务 A 更新了一条事务 B 插入的记录，那么事务 A 前后两次查问的记录条目就不一样了，所以就产生幻读。对于以后读，如果事务开启后，并没有执行以后读，而是先快照读，而后这期间如果其余事务插入了一条记录，那么事务后续应用以后读进行查问的时候，就会发现两次查问的记录条目就不一样了，所以就产生幻读。所以，MySQL 可反复读隔离级别并没有彻底解决幻读，只是很大水平上防止了幻读景象的产生。 参考:https://www.xiaolincoding.com/mysql/transaction/phantom.html#...

作者通过源码剖析 truncate 语句造成慢 SQL 的起因和解决方案，并与 MySQL 5.7就相干实现逻辑进行比照。 作者：李锡超 一个爱笑的江苏苏宁银行 数据库工程师，次要负责数据库日常运维、自动化建设、DMP 平台运维。善于 MySQL、Python、Oracle，喜好骑行、钻研技术。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。问题景象收到反馈某测试环境执行批量操作时，有 truncate 语句存在于慢查问日志中。放心上线后可能影响数据库，申请 DBA 配合剖析。 要害配置配置项阐明数据库版本MySQL 5.7参数 long_query_time <br/> 慢查问阈值，单位为秒0.1（100 毫秒）参数 innodb_adaptive_hash_indexON问题剖析总结总结下来次要有如何几个问题： Q1: TRUNCATE 语句是如何执行的？fd 句柄不变动？为什么执行工夫长？TRUNCATE 语句如何执行？要害堆栈： 要害操作 debug： 为什么执行工夫长？ 从以上堆栈能够看到，耗时过程次要是 row_drop_table_for_mysql、os_file_delete_func。 其中：row_drop_table_for_mysql 次要是调用 btr_drop_ahi_for_table 执行 AHI 的 page 页的删除。os_file_delete_func 次要调用 unlink 执行文件的清理。 句柄为什么不变动？如果须要 truncate 的表调配的 fd 为 43，truncate 过程中，会先将表 rename。这个时候这个 fd 会被敞开，43 就被开释了。而后执行 create table 操作。个别这个间隙过程很短，因而新建设的表能够应用被开释的 43 了，所以会看到 fd 没有变动。 如果 rename 之后，在外部执行 create table 之前，又关上了新文件，那这时候 fd 43 就会被其它关上的文件持有，truncate 之后表的 fd 也就会发生变化。 ...

事件背景生产环境发现有查问超时，通过异样日志获取查问sql并进行排查，explain后发现该sql应用了filesort，导致查问效率问题 查问sql & 索引状况查问sql select * from table where column1 = 'xxx' and column2 in ('a','b','c') order by id asc limit 100现有索引 主键索引 联结索引column1，column3优化过程通过explain发现，上述sql应用到了column1，column3的联结索引，然而查问中并不蕴含column3列，猜想可能是因为这个优化引擎应用了该索引才导致的filesort 于是删除column1，column3的联结索引，并建设column1，column2，column3的独自索引，并再次执行explain查看性能，发现曾经不存在filesort，解决了性能问题

本文为大家整顿了墨天轮数据社区2023年5月公布的优质技术文章，主题涵盖Oracle、MySQL、PostgreSQL等数据库的装置配置、故障解决、性能优化等日常实际操作，以及罕用脚本、注意事项等总结记录，分享给大家： Oracle优质技术文章概念梳理&装置配置 Oracle的rwp之旅Oracle之Hash JoinOracle之排序归并连贯（Sort Merge Joins）一场数据库的葬礼Oracle设置开机自启.docx Centos 7 静默装置Oracle 11.2.0.4 单机版装置指南数据库治理-第七十六期 如何降级19c RAC（20230516）Oracle 19C RAC 19.14 不停机滚动降级至19.18操作记录.pdfSQL大全（四）数据库迁徙降级时罕用 SQL 语句如何从高版本数据库导出dmp至低版本数据库导入？应用rman duplicate active数据库故障剖析与解决 ASM磁盘头损坏无奈mount[存档故障]Oracle 11g 生产库因明码过期批改明码产生library cache lock期待事件导致用户hang问题剖析及解决Oracle 11g ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O故障解决记录Oracle RAC敞开实例时service的行为Oracle 如何修复被批改的存储过程？)exp/imp及expdp/impdp只导入元数据时统计信息锁定 SQL文本一样，执行打算一样，执行效率有快有慢？Oracle数据库系统平安加固标准.docoraapxaudit.log日志文件过大导致磁盘空间告警.docxMySQL、PG及国产数据库相干技术文章MySQL相干技术文章 MySQL Limit实现解读MySQL InnoDB ClusterSet解读MySQL8.0 Performance Schema的threads与OS层对齐MySQL参数优化系列之- join\_buffer\_size 记录一次MHA的搭建MySQL还原死锁事务残缺的语句--文末附上疾速查看模板MySQL5.7 拜访Information_schema.TABLES 导至内存持续增长my2sql闪回工具-通过binlog实现MySQL误操作数据恢复MYSQL 通过治理端口解决ERROR 1040 (HY000): Too many connections 问题PG相干技术文章 PG里常见的字段有索引但没有应用索引的起因Ppostgresql学习笔记三--源码编译装置及常用命令)PostgreSQL-14底细挖呀挖学习笔记PostgreSQL表用户列最大个数DOMAIN域对象的应用介绍)PostgreSQL源码剖析——索引扫描IndexScan国产数据库相干技术文章 Centos 7 静默装置Oracle 11.2.0.4 单机版装置指南达梦数据库DM8+异机复原+不同目录构造opengauss 5.0 CM新个性之 vip配置)openGauss - 解决MTU设置过大导致scp无奈传输文件故障一则「OceanBase 4.1 体验」疾速体验 OceanBase 4.1 数据库 web 白屏部署集群环境GBase 8a MPP Cluster V9 集群装置 for RHEL 7 平台集成标准国产数据库|GBase 8s 装置卸载与简略应用StarRocks 3.0 存算拆散测试国产化数据库选型验证简略总结这些文章中有大家日常会遇到的操作、故障解决，文章构造残缺、逻辑清晰，其中故障解决主题类文章均蕴含问题景象（具体报错等）、问题定位与剖析 、 问题解决、问题总结等几个方面，可参考价值很强，心愿对大家有所帮忙。 ...

夏天来了，没想到连 ibdata1 文件也要开始“减肥”了~~~ 作者：杨彩琳 爱可生华东交付部 DBA，次要负责 MySQL 日常问题解决及 DMP 产品反对。喜好跳舞，追剧。 本文起源：原创投稿 有句话是这么说的：“在 InnoDB 存储引擎中数据是依照表空间来组织存储的”。其实潜台词就是：表空间是表空间文件，是理论存在的物理文件，MySQL 中有很多表空间，上面一起来理解一下吧。 人物介绍在说“减肥”的故事之前，让咱们先理解一下须要“减肥”的文件蕴含哪些局部，都是什么。 零碎表空间首先要说的是本文的配角，零碎表空间。它外面存储的有： InnoDB 表元数据doublewrite bufferchange bufferundo logs若在未配置 innodb_file_per_table 参数状况下有新建表的操作，那么零碎表空间也会存储这些表和索引数据信息。后面有说过表空间也是理论存在的表空间文件，同样零碎表空间它能够有一个或多个数据文件，默认状况下，是在数据目录中创立一个名为 ibdata1 文件的零碎表空间数据文件，其文件大小和数量能够由参数 innodb_data_file_path 来定义。 独立表空间由 innodb_file_per_table 参数定义。启用后，InnoDB 能够在 file-per-table 表空间中创立表，这样新创建的数据库表都独自的表空间文件。该参数在 MySQL 5.6.7 及更高版本曾经默认启用了。 通用表空间能够通过 CREATE tablespace 语法创立的共享 InnoDB 表空间。与零碎表空间相似，它能存储多个表的数据，也可将数据文件搁置在 MySQL 数据目录之外独自治理。 UNDO 表空间次要存储 undo logs，默认状况下 undo logs 是存储在零碎表空间中的，可通过参数 innodb_undo_tablespaces 来配置 UNDO 表空间的数量，只能在初始化 MySQL 实例时能力设置该参数，并且在实例的使用寿命内是固定的，MySQL 8.0 可反对动静批改。 长期表空间非压缩的、用户创立的长期表和磁盘上产生的外部长期表都是存储在共享的长期表空间存储的，能够通过配置参数 innodb_tmp_data_file_path 来定义长期表空间数据文件的门路、名称、大小和属性，如果没有指定，默认是在数据目录下创立一个名为 ibtmp1的大于 12M 的主动扩大数据文件。 前情提要客户反馈 MySQL 5.7 的配置文件中没有开启 UNDO 表空间和 UNDO 回收参数，导致 ibdata1 文件过大，并且始终在增长。须要评估下 ibdata1 文件大小如何回收及 UNDO 相干参数配置。 ...

原文https://ubiq.co/database-blog/how-to-increase-max-connections-in-mysql/ 引言有时候连贯Mysql时候咱们会遇到“Too many connections”这样的报错，当然更多可能是在生产过程中碰到这样的问题，默认状况下Mysql的整体服务器连接数设置过低。 Sometimes MySQL server may give “Too many connections” error message when you try to connect to a MySQL database. Here’s how to increase max connections in MySQL to fix this problem.Too many connections 的影响这意味着所有可用的连贯曾经被各种客户端应用，你的MySQL服务器不能关上任何新的连贯，直到任何现有的连贯被敞开。 By default, MySQL 5.5+ can handle up to 151 connections. This number is stored in server variable called _max_connections_. You can update max_connections variable to increase maximum supported connections in MySQL, provided your server has enough RAM to support the increased connections.max_connections默认值By default, MySQL 5.5+ can handle up to 151 connections. This number is stored in server variable called _max_connections_. You can update max_connections variable to increase maximum supported connections in MySQL, provided your server has enough RAM to support the increased connections.在Mysql5.5+的版本中，这个值只有151，咱们能够通过show variables like "max_connections";查看本人的Mysql服务器最大连接数。依据以后的机器配置和理论状况，咱们能够拉大这个参数。 ...

原文How to store UTF8 characters in MySQL - Ubiq BI 引言对于 《如何在MySQL中存储UTF8字符》 的一篇英文博客浏览和集体实战笔记。留神集体试验过程中应用了docker的Mysql 5.7 版本，读者能够依据本身状况调整。 1. Shell 查看字符集如果不习惯Linux的小黑框，最简略的形式是用navicat的命令行工具查问，留神用户须要具备对应的系统配置权限，倡议用root操作： 首先咱们右击navicat的数据库连贯配置（已筹备好），抉择“命令列界面”： 之后是navicat仿照的Shell，期待用户输出： 运行上面的命令能够查看所有字符集配置： SHOW VARIABLES LIKE 'character_set%';集体的试验后果如下： mysql> SHOW VARIABLES LIKE 'character_set%';+--------------------------+----------------------------+| Variable_name | Value |+--------------------------+----------------------------+| character_set_client | utf8mb4 || character_set_connection | utf8mb4 || character_set_database | utf8 || character_set_filesystem | binary || character_set_results | utf8mb4 || character_set_server | latin1 || character_set_system | utf8 || character_sets_dir | /usr/share/mysql/charsets/ |+--------------------------+----------------------------+8 rows in set (0.03 sec)能够看到字符集并不对立。 ...

SELECT ROUND((COUNT(DISTINCT second_day_users.user_id) / COUNT(DISTINCT first_day_users.user_id)) * 100, 1) AS conversion_rateFROM ( SELECT user_id FROM `order` WHERE DATEDIFF(create_date, (SELECT MIN(create_date) FROM `order`)) = 1) second_day_usersright JOIN ( SELECT user_id FROM `order` WHERE create_date = (SELECT MIN(create_date) FROM `order`)) first_day_usersON second_day_users.user_id = first_day_users.user_id;INSERT INTO `order` ( order_id, user_id, create_date, total_amount ) SELECT1,101,'2021-09-27',29000.00 UNION ALLSELECT 2, 103, '2020-10-02', 28000.00 UNION ALLSELECT 3, 101, '2021-09-28', 29000.00 UNION ALLSELECT 4, 101, '2021-09-30', 29000.00 UNION ALLSELECT 5, 103, '2020-10-03', 28000.00 UNION ALLSELECT 6, 103, '2020-10-04', 28000.00 UNION ALLSELECT 7, 104, '2020-10-02', 28000.00 UNION ALLSELECT 8, 104, '2020-10-02', 28000.00 UNION ALLSELECT 9, 104, '2020-10-03', 28000.00 UNION ALLSELECT 10, 104, '2020-10-04', 28000.00

上篇文章结尾和小伙伴们留了一个小问题，就是对于 optimize table 命令，明天我想花点工夫再来和小伙伴们聊一聊这个话题。 1. 删除空洞1.1 案例展现首先咱们先来看这样一个例子。 我当初有一个名为 sakila 的数据库，该库中有一个 film 表，这个表中有 1000 条记录，我么先来看下这 1000 条记录占用了多少存储空间： 小伙伴们能够看到，这个文件大小是 360448 个字节。 咱们当初执行 delete 命令将这个表清空： delete from film;而后再来查看这个文件的大小： 小伙伴们看到，这个表中的数据没有缩小，甚至还减少了！这是咋回事？ 1.2 剖析以下所说的删除皆指通过 delete 命令删除，不包含通过 truncate/drop 删除。MySQL 中的数据删除操作有点像咱们素日里做业务开发时用的逻辑删除，当你想要删除掉一行数据的时候，这行数据其实并没有被真正的删除掉，只是临时给标记为删除了而已。 通过后面文章的介绍，小伙伴们应该曾经分明，MySQL 表中的数据最终是以 B+Tree 的模式保留在磁盘中的，当你要删除一条记录的时候，那么对应的叶子上的数据就会被标记为已删除，相似上面这样： 当 ID 为 6 的记录被删除掉之后，这块空间并不会立马被释放出来，MySQL 只是在这个地位做一个删除标记，未来要是还有一个 ID 为 6 的数据被插入进来，就会插入到这里。 因而咱们看到，一张表在通过 N 屡次删除之后，就会呈现大量这种状况，这种就称之为删除空洞。 2. 插入空洞后面所说的删除会造成空洞，其实插入也会造成空洞。 松哥在之前的文章中和小伙伴们分享过，InnoDB 引擎的表中不倡议应用随机字符串作为 ID，因为随机字符串插入会造成页决裂。页决裂之后，在决裂之前的叶子中，也有可能会空进去新的空间，造成空洞。 例如上面这个例子： 在上图这个 B+Tree 中，持续插入 5，就会造成页决裂，页决裂之后，2 所在的数据页（InnoDB 操作磁盘的最小单位是数据页）就会有空余，这也是空洞的一种。 当然更新索引上的值也会造成空洞，因为更新相当于插入+删除。 3. optimize table想要解决这个问题，咱们能够应用 optimize table 命令来实现。该命令能够用来从新整理表空间，并优化文件碎片。接下来咱们针对后面 1.1 大节中的案例，来试试 optimize table 命令是否无效： ...

后面几篇文章和小伙伴们聊的基本上都是从索引的角度去优化 MySQL 查问，然而，索引创立的好，并不意味着查问就肯定快，影响查问效率的因素特地多，明天咱们就来聊一聊这些可能影响到查问的因素。 1. 查问流程开始明天的内容之前，先来和小伙伴们大略捋一捋 MySQL 的查问流程。咱们来看如下一张图： 首先，用户通过连接器和服务端之间建设通信连贯，这个说白了就是一个 Socket 通信，用户名/明码的校验，用户权限的判断等等，都是在这个连接器中实现的。接下来须要对我么传入的 SQL 进行解析，这块跟代码的执行流程其实差不多，先做词法剖析，辨认出各种关键字，而后再做语法分析，语法分析就是依据 MySQL 的各种语法规定，去判断 SQL 是否满足语法规定。接下来就是查问优化器出场，查问优化器就是剖析要执行的 SQL，判断应该抉择哪一个索引，包含在多表联结查问的时候，各个表的连贯程序也是由查问优化器来决定的，优化器执行结束之后，会生成查问执行打算，咱们平时通过 explain 关键字查看到的就是这个。最初就是执行器了，执行器调用搜索引擎提供的具体接口去获取数据。这张图大家大略有个印象，在后续的 MySQL 查问和优化中，很多货色就容易了解了。 接下来咱们就来看看什么状况下查问会变慢。 2. 查问了不须要的记录数据按需取用。有时候咱们会疏忽多拿数据对查问性能的影响，然而优化是一个斤斤计较的事件，须要多少数据就查问多少，要尽量避免数据库查问 100 条，后果前端只展现 10 条这种状况。如有须要，能够通过 limit 来限度数据库查问进去的数据总量。 如果在查问的时候应用了唯一性索引的话，那么查问到记录之后 MySQL 就进行扫描了；然而如果查问的时候应用的是非唯一性索引的话，那么扫描到第一条记录之后，还会持续向后扫描，直到扫描到第一条不满足条件的记录为止，对于这种状况，如果咱们确定查问的后果只有一条，则能够通过 limit 进行限度，设置 limit 1，那么扫描到第一条满足条件的记录之后，就不会持续扫描了。3. 返回须要的列查问的时候尽量避免 select *，这个问题在之前的文章中松哥其实和大家聊过了，因为很多时候咱们在前端其实并不需要应用到那么多字段，可能只是为了查问简略，间接来一个 select *，有时候列数和数据总量都比拟少的时候，这么写也看不出来性能显著的差别，然而当列数和数据量大了，那么 select * 带来的影响就会比拟大了。 特地是有的时候多表联结查问，如果用 select * 就会把多张表的查问后果拼接到一起，那么此时查问后果的列数就会成倍增加。 在后面的文章中，松哥也和大家提到过笼罩索引，如果索引设计切当，那么在查问的时候能够通过笼罩索引来进步查问的性能，然而如果应用了 select * 那么大概率是用不了笼罩索引了。 4. 恰到好处的缓存这里举一个 TienChin 我的项目的例子，用户登录胜利之后，在后续的流程中，常常会用到以后登录用户的信息，如果每次都去数据库查问，每次查问返回后果都是统一的，没有必要，此时咱们能够将用户信息存入到 Redis 缓存中，须要的时候从 Redis 中提取就能够了。 在我的项目中，对于这些须要屡次频繁查问，且每次查问返回后果一样的数据，都能够抉择将之存入到缓存中以进步查问性能。 5. 关注扫描行数在查问的时候，咱们能够通过 explain 来查看执行打算，执行打算中有一个指标是扫描行数，如下图中的 rows，这个就示意查问优化器预估要扫描多少行记录，filtered 则示意预估满足条件的比例。 ...

聚簇(汇集)索引聚簇索引(InnoDB)是对磁盘上的数据从新组织以按指定的一个或多个列的值排序的算法，聚簇索引的叶子节点就是其数据节点，其特点是数据的存储程序和索引程序统一。个别状况下默认以主键为聚簇索引，且一张表只容许存在一个聚簇索引，因为，数据一旦存储，其程序只能有一种。如果未设置主键，会抉择一个符合条件的 Unique-key 做主键；如果找不到符合条件的 Unique-key，InnoDB 会生成一个外部的rowid做主键; 非聚簇(汇集)索引非聚簇索引(MyISAM)的叶子节点依然是索引文件，只是这个索引文件中蕴含指向对应数据块的指针。 二者区别（征引自数据库原理一书）：聚簇索引的叶子节点就是其数据节点，而非聚簇索引的叶子节点依然是索引节点，该索引节点指向对应数据块的指针。 聚簇索引的优缺点：长处: 依据主键查问条目比拟少时，不必回表(数据就在主键节点下)；毛病: 如果碰到不规则数据插入时，造成频繁的页决裂； 对于聚簇索引的长处：InnoDB 的二级索引的叶子节点寄存的是索引key值和主键值；因而执行相似 select * 查问全量字段时，会先通过二级索引定位到主键值，再依据查到的主键值执行一遍主键索引找到相应的数据块，这个过程叫做回表;可见，回表的实质是两次二叉树查问，所以个别不倡议应用 select *；而如果查问的字段就是索引key自身，则称之为笼罩索引；比方学生表里除了学生ID，还有学生姓名、班级ID、业余ID等，假如以 学生ID、班级ID 做了联结索引，那么当咱们 select 学生ID、班级ID from 班级表 时，通过二级索引，就会找到咱们须要的值，无需再应用主键回表，会大大节省时间。MyISAM 的主键和二级索引的叶子节点，保留的都是其数据的物理地址；因而，MyISAM，无论是用主键还是二级索引，都要回表查问；也因这个个性，MyISAM 能够不设主键！于 MyISAM 而言，主键索引和二级索引，其实没啥区别，只不过主键因其定义的特殊性，需保障惟一、非空； 对于聚簇索引的毛病：InnoDB 环境下，页决裂会产生在插入或更新，为满足索引逻辑，可能会产生频繁的页决裂，从而导致更新效率变低；MyISAM 不存在页决裂的问题：只需在更新数据之后挪动索引节点即可； 什么是页决裂？咱们要晓得，InnoDB 不是按行来操作数据的，它可操作的最小单位是页，页加载进内存后才会通过扫描页来获取行记录。比方查问id=111，是获取111所在的数据页，加载进内存后取出111这一行。页的默认大小为16KB，64个间断的数据页称为一个extent（区），64个页组成一个区，所以区的大小为1MB(16*64=1024)，间断的256个数据区称为一组数据区；两个数据页之间会有指针指向上一个和下一个数据页，造成一个双向链表，数据页中的每个数据行之间会有单向指针连贯，组成一个单向链表；当一个数据页中的数据行太多放不下的下，就会生成一个新的数据页来存储，同时应用双向链表来相连； 应用索引时，一个最根底的条件是，前面数据页中的数据行的主键值要大于前一个数据页中数据行的主键值；至于起因，其实索引简略来说，就是一遍一遍过筛子，通过二分法的逻辑一直缩小要筛选的数据，而实在数据是按主键顺序存储的，所以主键值就是筛选规范，以便尽快定位咱们须要的数据；咱们假如如下的前两行数据已满足凑成一页的条件：如果咱们设置了主键ID自定义，非自增，在曾经插入了1、5、6、7(已分为两页)等ID的状况下，再插入ID2，就会触发页决裂；因为咱们须要保障，后一个数据页中的所有主键值要比前一个数据页中的主键值大；这时我咱们须要把2插入到1的前面，5、6、7等ID顺次后移；留神，这里不是单纯的挪动ID，而是要带着数据一起搬家！另外，每一行数据所占用的空间是不固定的，有可能挪动之后，一页空间存不下5、6、7三条数据，须要同时生成第三页寄存7ID;如果第三页曾经存在了咋办，那就得生成第N页，同时批改第二、三页和第N页的指针，调整到符合要求；所以如果插入的主键是乱序，为满足索引条件，可能会产生频繁的页决裂，从而导致更新效率变低；当然了，真正的页决裂要比下面所说的简单很多，但实质是通过这种逻辑来实现页决裂的。 文档参考：https://www.percona.com/blog/innodb-page-merging-and-page-splitting文档翻译参考：https://zhuanlan.zhihu.com/p/98818611页决裂的大抵流程假如当初有 9、10、11 等3页数据，在页#10中插入了乱序的主键ID，或者更新了一条长文本数据导致当没有足够空间存储：因为页#10没有足够空间去包容新（或更新）的记录，依据“下一页”逻辑，记录应该由页#11负责。然而：页#11也同样满了，为了保障主键的程序，也不可能乱序插入。这时候该怎么办呢？B+树的每一层都是双向链表，页#10有指向页#9和页#11的指针，InnoDB的做法是（简化版）： 创立新页判断当前页（页#10）能够从哪里进行决裂（记录行层面）挪动记录行从新定义页之间的关系新的页#12被创立(假如只存在#13页，#12页被合并后删除了)，页#11放弃原样，只有页之间的关系产生了扭转： Page #10 will have Prev=9 and Next=12Page #12 Prev=10 and Next=11Page #11 Prev=12 and Next=13B树在程度方向的一致性依然满足，然而，在物理上，页面的地位却是无序的，而且大概率会落到不同的区。总结：页面拆分产生在插入或更新时，并会导致页的错位（dislocation，落入不同的区）。 InnoDB用INFORMATION_SCHEMA.INNODB_METRICS表来跟踪页的决裂数。能够查看其中的index_page_splits和index_page_reorg_attempts/successful统计。 一旦产生了决裂的页，MySQL本身(无人为干涉)惟一将原先程序复原的方法就是新决裂进去的页因为低于合并阈值（merge threshold）被删掉。这时候InnoDB会应用页合并将数据从新合并回来。人为干涉的形式就是用 OPTIMIZE 从新整理表。这可能是个很重量级和耗时的过程，但通常是惟一将大量扩散在不同区的页理顺的办法。 另一方面，在页的合并和决裂期间，InnoDB 会获取索引树的 x-latch。它可能会导致索引的锁争用（index latch contention）。 如果没有合并和拆分(有写操作)，称为“乐观”更新，只需应用读锁（S）。带有合并和决裂的操作则称为“乐观”更新，需应用写锁（X）。 衍生知识点：页合并依据 B-Tree 的个性，InnoDB 能够自顶向下遍历，也能够在各叶子节点之间程度遍历，因为每个叶子节点都有一个指向下一条（程序）记录页的指针；例如，页-5 有指向 页-6 的指针，页-6 有指向前一页（5）的指针和后一页（7）的指针；如果是基于自增主键进行插入，这种机制能够做到疾速程序扫描（如范畴扫描），但如果你不仅插入还进行删除呢？ ...

@[toc]对于 MySQL 中的索引，松哥后面曾经和小伙伴们聊了不少了，不过在索引应用的时候，还是有一些须要留神的细节，如果疏忽了这些细节，可能会让索引的应用成果大打折扣。 1. 冗余索引留神我这里应用了冗余索引，没有应用反复索引，因为我感觉在小伙伴们应用索引的过程中，创立反复索引的概率应该还是比拟小，同一个字段上创立多个截然不同的索引，应该很少有人会犯这种谬误。然而，会有一些容易被大家疏忽的冗余索引，咱们来捋一捋。 1.1 联结索引右边列例如我创立了一个联结索引 (A,B,C)，依照咱们之前跟大家讲的最左匹配准则，当咱们应用 A、（A、B）或者 （A、B、C）去查问数据的时候，都会用到这个联结索引，所以咱们就没有必要再去独自针对 A 字段创立一个索引，或者针对 A、B 字段创立一个联结索引。 1.2 索引中退出主键假如我有一张表，该表有如下字段 （ID、A、B、C），其中 ID 是主键，当初又针对 A 和 ID 两个字段创立了联结索引（A、ID）。 依据松哥后面的介绍，小伙伴们晓得，在二级索引中，叶子结点上存储的数据就是 ID，所以，这个联结索引中的 ID 字段显然是多余的。 大部分状况下咱们都不须要冗余索引，然而也有一些非凡状况可能让咱们不得不创立一些冗余索引，这个小伙伴们还是要具体问题具体分析。 另外须要留神一点，针对雷同的字段，如果索引类型不同，则不能算是反复索引，例如一个一般索引和一个全文索引，同一个字段上同时有这两个索引，不算反复索引。2. 暗藏的索引排序上篇文章松哥刚刚和大家聊了索引排序的问题。 联合上篇文章的内容，小伙伴们思考这样一个问题：假如我有一张表，表中蕴含如下字段（ID、A、B），其中 ID 是主键，当初我针对 A 字段建设一个索引，如果我有如下查问 SQL： select ... from table where A=xxx order by ID因为在 A 这个二级索引中就蕴含了 ID 字段，所以下面这个查问是能够应用到索引排序的。此时，如果因为其余需要，咱们将 A 这个索引扩大成联结索引（A、B）了，那么很显著，再执行下面的查问的时候就用不了索引排序了，只能 filesort 了。这样的问题小伙伴们在创立或者批改索引的时候很容易疏忽，所以肯定要认真。 3. 删除不应用的索引有的索引可能是因为适度思考创立了，创立胜利之后就没用过，这样的索引也应该删除掉。 小伙伴们晓得，索引尽管能够进步查问速度，然而却会升高插入和批改速度。在 MySQL 的元数据库 sys 中有一个名为 schema\_unused\_indexes 的视图，该视图中就保留了各种创立了然而未应用的索引： 4. 手动更新索引统计信息当咱们想要查看一条 SQL 的执行打算时，这个执行打算中会展现进去这个 SQL 执行过程中大略会扫描多少行数据，如下： ...

对于这个问题，村长我查过很多信息，有说来自官网，有本人剖析的，无所适从，要么太发散，要么有几分牵强，当初村长试解答一下。 这个问题其实挺有意思，实践上来说，能够存一条数据，那为啥要有这么个规定呢？咱们晓得，一页的大小默认为 16*1024=16384 字节，然而，MySQL 容许的一行数据的存储下限却为 65535！当然了，这 65535 个字节除了列自身的数据外，还包含一些其余数据（storage overhead），比方 变长字段长度列表、NULL值列表、记录头信息 等，但归根结底，还是远大于 16384 的。如果至多要存储两条记录，简略做个除法，16384/2=8192，这远小于上限值啊！ 有意思吧？ 如果咱们设置行类型为 text, 实践上会呈现一页可能存不下一行数据的状况誒。比方，超过 一页大小的二分之一，8192，那怎么办？ 这种状况称之为 行溢出，和内存溢出相似MySQL 是怎么解决行溢出的呢？ 这波及到 行格局 问题，MySQL 反对4种不同类型的行格局：Compact、Redundant（比拟老）、Dynamic、Compressed。Compact和Redundant行格局中，记录的实在数据处会存储该列的一部分数据(前768个字节)， 残余数据存储在其余页(溢出页)，再应用20个字节存储指向溢出页的地址；Dynamic(MySQL默认)和Compressed行格局中，不会在记录的实在数据处寄存前768个字节，而是将所有字节都存储在其它页面中，本身只存储一个指向溢出页的地址；略有不同的是，Compressed 行格局会采纳压缩算法对页面进行压缩，以节俭空间。 言而总之，要么存 前缀+溢出页地址，要么只存 溢出页地址。 当初问题来了，咱们假如一个场景： 某一行数据，占 10000 个字节，加上额定信息，一页也是能够存下的，为啥非得搞个溢出页寄存，这不给本人找事儿吗？咱们再持续假如，如果容许寄存一行，且所有数据都是 10000 个字节，那就变成有多少行就有多少页了。这种状况有啥问题呢？ 咱们要晓得，MySQL 是以页作为磁盘和内存之间交互的根本单位的，也就是，个别状况下一次起码从磁盘中读取16KB的内容到内存中；如果咱们执行 select * from tbl, 连个筛选条件也不加，而且是读取全量字段，感觉一页存几条都没啥区别，就是可劲儿造呗；但理论状况中，千万量级的表，不可能呈现这么傻叉的查问逻辑，别问村长为啥，你本人试试就晓得如许痛的领悟了。 通常来讲，大量级的表，咱们查问数据，个别要设定筛选条件，也就是依据索引来放大查问范畴，以达到只取必要数据的目标；而造成行溢出的，根本都是 text 或 超长的 varchar 字段，这类字段个别是不会被高频次查问的；如果有一个学生表，里边有学生ID、名称、班级、业余等信息，还有一个兴趣爱好的字段，被设定为 text，且大家为了交朋友，都很踊跃填写，兴趣爱好都超过了 10000 个字节，但小于一页数据大小； 当初问题又来了：MySQL 容许一页存一行数据，一共存了 2000 条学生记录，也就是 2000 页；大领导来视察了，想查问学生根本信息，不必带上 兴趣爱好 形容啥的，领导没趣味看，就学生本人玩儿的；假如一次从磁盘读取16kb，也就是一页数据，那就得从磁盘读取 2000 次吧？如果记录数扩大为 2000万 呢？那就得读取 2000万 次吧？这效率可想而知。。。但如果限度了一页至多存两条记录呢？你会发现，读取次数间接降了一半誒。 这就是二分逻辑的神奇之处，相似经济学中的"荷塘效应"， 假如池塘的荷叶一天增长一倍，那在在它铺满池塘之前的前一天，才只占了池塘的一半面积呢。 剖析到这里，都有些心灵鸡汤的玄学滋味了；这个限度，大概就是为了提前拆散长文本数据，以实现更高效的查问吧； ...

作者：李鹏博爱可生 DBA 团队成员，次要负责 MySQL 故障解决和 SQL 审核优化。对技术执着，为客户负责。本文起源：原创投稿爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。MySQL 的 commit 命令提交事务时，外部会进行两阶段（Prepare 和 Commit）提交，这篇文章基于 MySQL 8.0.33 对 MySQL 的两阶段提交进行源码剖析，带你理解提交事务过程中都经验了什么。 一、Prepare 阶段1. Binlog Prepare获取上一个事务最大的 sequence number 工夫戳。 2. InnoDB Prepare事务状态设置为 prepared；开释 RC 及以下隔离级别的 GAP Lock；将 Undo log segment 的状态从 TRX_UNDO_ACTIVE 批改为 TRX_UNDO_PREPARED；Undo log 写入事务 XID。二、Commit 阶段1. Stage 0保障从实例的 commit order。 2. Flush Stage依据 innodb_flush_log_at_trx_commit 参数进行 redo log 的刷盘操作 获取并清空 BINLOG_FLUSH_STAGE 和 COMMIT_ORDER_FLUSH_STAGE 队列存储引擎层将 prepare 状态的 redo log 依据 innodb_flush_log_at_trx_commit 参数刷盘不再阻塞 slave 的 preserve commit order 的执行调用 get_server_sidno() 和 Gtid_state::get_automatic_gno() 生成 GTIDFlush binlog_cache_mngr ...

作者：Mutlis CSDN & 阿里云 & 知乎 等平台优质作者，善于Oracle & MySQL等支流数据库系统的保护和治理等 本文起源：原创投稿 前言对于 MySQL 5.6 以及之前的版本来说，查问优化器就像是一个黑盒子一样，你只能通过 EXPLAIN 语句查看到最初优化器决定应用的执行打算，却无奈晓得它为什么做这个决策。这对于一部分喜爱刨根问底的⼩搭档来说几乎是劫难：“我就感觉应用其余的执行计划⽐ EXPLAIN 输入的这种计划强，凭什么优化器做的决定和我想的不一样呢？”这篇文章次要介绍应用 optimizer trace 查看优化器生成执行打算的整个过程。 optimizer trace 表的神奇效用在 MySQL 5.6 以及之后的版本中，设计 MySQL 的大叔贴⼼的为这部分小伙伴提出了一个 optimizer trace 的性能，这个性能能够让咱们不便的查看优化器生成执行打算的整个过程，这个性能的开启与敞开由零碎变量 optimizer_trace 决定，咱们看一下： mysql> show variables like 'optimizer_trace';+-----------------+--------------------------+| Variable_name | Value |+-----------------+--------------------------+| optimizer_trace | enabled=off,one_line=off |+-----------------+--------------------------+1 row in set (0.01 sec)能够看到 enabled 值为 off，表明这个性能默认是敞开的。 小提示： one_line 的值是管制输入格局的，如果为 on 那么所有输入都将在一行中展现，不适宜⼈浏览，所以咱们就放弃其默认值为 off 吧。 如果想关上这个性能，必须⾸先把 enabled 的值改为 on，就像这样： mysql> SET optimizer_trace="enabled=on";Query OK, 0 rows affected (0.00 sec)而后咱们就能够输出咱们想要查看优化过程的查问语句，当该查问语句执行实现后，就能够到 information_schema 数据库下的 OPTIMIZER_TRACE 表中查看残缺的优化过程。这个 OPTIMIZER_TRACE 表有 4 个列，别离是： ...

1 引言大家好，接着上次和大家一起学习了《MySQL DDL执行形式-Online DDL介绍》，那么明天接着和大家一起学习另一种MySQL DDL执行形式之pt-soc。 在MySQL应用过程中，依据业务的需要对表构造进行变更是个广泛的运维操作，这些称为DDL操作。常见的DDL操作有在表上减少新列或给某个列增加索引。 DDL定义： Data Definition Language，即数据定义语言，那相干的定义操作就是DDL，包含：新建、批改、删除等；相干的命令有：CREATE，ALTER，DROP，TRUNCATE截断表内容（开发期，还是挺罕用的），COMMENT 为数据字典增加备注。 留神：DDL操作是隐性提交的，不能rollback，肯定要审慎哦！ 下图是执行形式的性能比照及阐明： 图1 易维平台阐明图 上面本文将对DDL的执行工具之pt-osc进行简要介绍及剖析。如有谬误，还请各位大佬们批评指正。 2 介绍pt-online-schema-change - ALTER tables without locking them. pt-online-schema-change alters a table’s structure without blocking reads or writes. Specify the database and table in the DSN. Do not use this tool before reading its documentation and checking your backups carefully. pt-online-schema-change是Percona公司开发的一个十分好用的DDL工具，称为 pt-online-schema-change，是Percona-Toolkit工具集中的一个组件，很多DBA在应用Percona-Toolkit时第一个应用的工具就是它，同时也是应用最频繁的一个工具。它能够做到在批改表构造的同时（即进行DDL操作）不阻塞数据库表DML的进行，这样升高了对生产环境数据库的影响。在MySQL5.6之前是不反对Online DDL个性的，即便在增加二级索引的时候有FIC个性，然而在批改表字段的时候还是会有锁表并阻止表的DML操作，这样对于DBA来说是十分苦楚的，好在有pt-online-schema-change工具在没有Online DDL时解决了这一问题。 Percona 公司是成立于2006年，总部在美国北卡罗来纳的Raleigh。由 Peter Zaitsev 和 Vadim Tkachenko创建， 这家公司宣称他们提供的软件都是收费的，他们的支出次要来与开源社区，企业的反对，以及应用他们软件的公司的领取他们提供support的费用。 而实际上这家公司"垄断"了业内最风行数据库反对类的软件，并且还开发了一些其余的与数据库相干的货色。 Percona-Toolkit工具集是Percona反对数据库人员用来执行各种MySQL、MongoDB和零碎工作的高级命令行工具的汇合，这些工作太难或太简单而无奈手动执行。这些工具是公有或“一次性”脚本的现实替代品，因为它们是通过业余开发、正式测试和残缺记录的。它们也是齐全独立的，因而装置疾速简便，无需装置任何库。 Percona Toolkit 源自 Maatkit 和 Aspersa，这两个最驰名的 MySQL 服务器治理工具包。它由 Percona 开发和反对。 ...

感激各位朋友们对《Klustron Tech Talk》直播系列的反对与青睐，咱们始终在致力做得更好。 为了帮忙到更多数据库相干从业者并与大家独特成长，咱们诚邀您做一个问卷调查，理解您对数据库技术的哪些方面的内容感兴趣并且心愿咱们在每周的线上技术分享来解说。 您的问卷反馈将助力咱们继续晋升《Klustron Tech Talk》的课程品质，给敌人们带来更好的直播体验，发明更大的价值。您能够点击下方链接填写考察问卷或者通过扫描以下二维码进行填写。 问卷链接：https://wj.qq.com/s2/12433995/6dfe/ 《Klustron Tech Talk》直播选题问卷二维码 所有参加问卷调查并留下邮箱联系方式的，咱们将在6月16日后对立随机抽取 10 名无效填写者作为侥幸参与者，给予MySQL系列丛书。咱们将在流动截止（截止工夫：6月16日24点）后的7个工作日内送出书籍。 感谢您的反对与参加！心愿与各位朋友们一起砥砺前行，共攀顶峰！

概念介绍事物：用来保障一组操作，要么全副胜利要么全副失败隔离：因为在高并发状况下大概率会呈现多个事物同时操作同一个数据，如果事物之间不进行隔离可能会呈现意想不到的问题InnoDB四种事物隔离级别针对并发状况下的多事物之间相互影响的问题Mysql提供了四种事物隔离级别，别离如下: 读未提交（READ_UNCOMMITTED） 容许读取其余事物未提交的写操作；因而如果其余事物做了回滚那么对于以后事物来说读到的数据就是脏数据读已提交（READ_COMMITTED） 只容许读取其余事物已提交的操作；在同一个事物内屡次读取到的数据不能保持一致，也就是不可反复读可反复读（REPEATABLE_READ） 只能读取事物开启时的数据状态该隔离级别下能够保障每次读到的数据是统一的，然而如果事物内要插入却会呈现主键抵触序列化（SERIALIZABLE） 最高级隔离，事物操作串行化执行，不能最大化利用数据库资源，吞吐量很低实战1. 数据筹备## 首先创立一张企业账户表create table corp_account( id int not null, account_name varchar(20) not null comment '账户名', amount decimal default 0.0 comment '账户余额', constraint corp_account_pk primary key (id)) comment '企业账户表';## 插入一条数据INSERT INTO test.corp_account (id, account_name, amount) VALUES (1, 'cocoo', 100);2. 验证各隔离级别下脏读、不可反复读和幻读的问题2.1 读未提交：READ-UNCOMMITTED## 开启一个事物:ASTART TRANSACTION; ## 批改amount为90 update corp_account set amount = 90 where id = 1; ## 此时本事物内查问amount为90 select * from corp_account where id = 1; ## 不提交该事物rollback ; ## 这句暂不执行在事物A没提交的前提下，新开一个数据库连贯的session## 设置本session的事物隔离级别为读未提交set tx_isolation = 'READ-UNCOMMITTED';## 查问本session的事物隔离级别，确认事物隔离级别是否批改胜利SELECT @@tx_isolation;## 开启一个新事物:BSTART TRANSACTION; ## 查问id为1的记录，显示amount=90，阐明读取到了事物A未提交的数据 ## 此时如果事物A执行回滚(rollback)，事物B拿到的这个90就是脏数据了 select * from corp_account where id = 1;总结：读未提交会呈现脏读的问题2.2 读已提交: READ-COMMITTED## 开启一个事物:ASTART TRANSACTION; ## 批改amount为90 update corp_account set amount = 90 where id = 1; ## 此时本事物内查问amount为90 select * from corp_account where id = 1; commit ; ## 这句暂不执行同样的在事物A没提交的前提下，新开一个数据库连贯的session## 设置本session的事物隔离级别为读已提交set tx_isolation = 'READ-COMMITTED';## 查问本session的事物隔离级别，确认事物隔离级别是否批改胜利SELECT @@tx_isolation;## 开启一个新事物:BSTART TRANSACTION; ## 查问id为1的记录，显示amount=100，阐明未读取到了事物A未提交的数据， ## 解决了读未提交中的脏读问题 select * from corp_account where id = 1; ## 事物A执行提交(commit)后，再来查问会发现amount=90,阐明读取到了事物A提交的变更 select * from corp_account where id = 1; ## 此时咱们会发现在同一个事物内两次读取同一条数据，后果不样： ## 第一次读取amount=100,第二次读取变成90了，不满足数据库事物ACID个性的数据一致性(consistency)，即不可反复读总结：读已提交尽管解决了读未提交中的脏读问题，然而会呈现不可反复读的问题2.3 可反复读：REPEATABLE-READ## 开启一个事物:ASTART TRANSACTION; ## 批改amount为90 update corp_account set amount = 90 where id = 1; ## 此时本事物内查问amount为90 select * from corp_account where id = 1; commit ; ## 这句暂不执行同样的在事物A没提交的前提下，新开一个数据库连贯的session## 设置本session的事物隔离级别为可反复读set tx_isolation = 'REPEATABLE-READ';## 查问本session的事物隔离级别，确认事物隔离级别是否批改胜利SELECT @@tx_isolation;## 开启一个新事物:BSTART TRANSACTION; ## 1. 查问id为1的记录，显示amount=100，阐明未读取到了事物A未提交的数据， ## 解决了脏读问题 select * from corp_account where id = 1; ## 2. 事物A执行提交(commit)后，再来查问会发现amount还是100,阐明无奈读取到了事物A提交的变更 ## 解决了不可反复读的问题 select * from corp_account where id = 1; ## 3. 这里会有一个疑难，既然读取不到其余事物已提交的批改， ## 那如果本事物也执行更新操作不是会笼罩前一个事物已提交的数据吗？ ## 假如你的更新逻辑是先select amount，而后在程序里计算出一个具体的值，再作为参数传递给update，那的确会呈现笼罩的状况，所以只需向上面这样更新就没问题了 update corp_account set amount = amount - 10 ## 4. 这是因为RR级别解决不可反复读的问题只是针对select *这种查问应用了快照读，而对于udpate、delete、insert这类操作应用的以后读。而幻读就是因为写操作的以后读导致了RR隔离级别无奈解决RR隔离级别重现幻读## 开启一个事物:ASTART TRANSACTION; ## 新增一条id为2的数据 INSERT INTO test.corp_account (id, account_name, amount) VALUES (2, 'google', 1000); commit ; ## 待事物B开启后提交同样的在事物A没提交的前提下，新开一个数据库连贯的session## 设置本session的事物隔离级别为可反复读set tx_isolation = 'REPEATABLE-READ';## 查问本session的事物隔离级别，确认事物隔离级别是否批改胜利SELECT @@tx_isolation;## 开启一个新事物:BSTART TRANSACTION; ## 1. 提交事物A ## 2. 查问id为2的记录，从下面那个例子咱们曾经晓得此时是查不到。因为事物B开启的时候事物A还没提交。 ## 3.1 这里页插入一条id为2的记录，上面的insert 回报主键抵触，select查不到insert却又抵触，这不就是像幻觉一样吗 INSERT INTO test.corp_account (id, account_name, amount) VALUES (2, 'google', 1000); ## 3.2 咱们还能够胜利update事物A提交的那条ID为2的数据。很魔幻，查问不到却能够批改，这就是幻读 update test.corp_account set amount = 900 where id = 2;总结：可反复读尽管解决了读已提交中的不可反复读的问题，然而会呈现幻读2.4 序列化：SERIALIZABLE新开一个事物：A，批改id为1的账户金额为80，但临时不提交start transaction ; update corp_account set amount = 80 where id = 1; select * from corp_account where id = 1;commit ; # 暂不提交同样的在事物A没提交的前提下，新开一个数据库连贯的session# 设置以后session的事物隔离级别为serializableset tx_isolation = 'serializable';# 确认是否设置胜利select @@tx_isolation;# 开启新的事物：B，start transaction; select * from corp_account where id = 1;commit ;能够看到咱们的事物B只是查问Id为1的这条记录，来看下执行后果：能够看到事物B里的执行逻辑被阻塞了；接着咱们把事物A提交了再看下事物B的执行后果：此时查问出的后果刚好是事物B提交的，这个时候如果事物B不提交，再次执行事物A，会发现事物A也同样会产生阻塞 ...

表构造CREATE TABLE single_table( id int not null auto_increment, key1 VARCHAR(100), key2 int, key3 VARCHAR(100), key_part1 VARCHAR(100), key_part2 VARCHAR(100), key_part3 VARCHAR(100), common_field VARCHAR(100), PRIMARY KEY(id), key idx_key1(key1), unique key uk_key2(key2), key idx_key3(key3), key idx_key_part(key_part1,key_part2,key_part3))engine=INNODB charset=utf8mb4只为用于搜寻、排序或分组的列创立索引咱们只为呈现在where子句中的列、连接子句中的连贯列，或者呈现在ORDER BY或者GROUP BY子句中的列创立索引。仅呈现在查问列表中的列就没必要建设索引。比方这样一个查问语句： SELECT common_field,key_part3 FROM single_table WHERE key1 = 'a';查问列表中的common_field、key_part3这两个列就没必要创立索引。咱们只须要为呈现在WHERE字句中的key1列创立索引就能够了。 思考索引列中不反复值的个数在通过二级索引进+回表的形式执行查问时，某个扫描区间中蕴含的二级索引记录数量越多，就会导致回表操作的代价越大。咱们在为某个列创立索引时，须要思考列中不反复值的个数占全副记录条数的比例。如果比例太低，则阐明该列蕴含过多的反复值，那么在通过二级索引+回表的形式执行查问时，就有可能执行太屡次回表操作。 索引的类型尽量小能应用INT就不要应用BIGINT。因为数据类型越小，索引占用的存储空间就越少，在一个数据页就能够寄存更多的记录，磁盘I/O带来的性能损耗也就越小（一次页面I/O就能够将更多的记录加载到内存中），读写效率也就越高。 这个倡议对于表的主键来说更加实用，因为不仅聚簇索引会存储主键值，其余所有的二级索引的节点都会存储一份记录的主键值。如果主键应用更小的数据类型，也就意味着能节俭更多的存储空间。

前言：在波及商品类的我的项目时，为了给同一类商品定位，往往会分等级或者成色。而等级/成色有时是用相似A，A+，A+1，K，L1，L2等英文与数字的组合进行表述。既然是等级，天然就会辨别高等级，低等级。有高有低，又给商品定了等级，所以到了商品列表展现，等级排序天然少不了。      我的项目在开始做的时候对于商品等级字段是间接存储的下面的字母数字，也就是A，A+1之类的。所以在须要以等级排序的时候，以英文字母的形式升序倒序就呈现了问题，比方大部分等级中，S是最高级，而英文倒序S排在了前面。  抵触：间接以英文字母排序很显然是不行的，于是首先想到的是数据表的等级字段改为int，存入数字。在配置里或者独自建一张表与对应数字关联一个等级。相似K对应1之类的，须要升序降序就对数字排序，这样就解决了S排序问题。然而，事实的是商品表的数据量极大，如果要给原来的等级做关联，就要小心的写SQL替换或者手动一个一个改。不晓得有没有在不须要批改表的状况下解决那种特殊字符排序的办法，起初还真想到了一个办法。  解决办法：通过应用MySQL的find_in_set函数，通过自定义的程序进行排序，所以后续将某个等级提前改变都不会那么被动了，如下示例。 1. 能够先定义升序，倒序的排列"grade_desc" => ["S","A+","A1","A2","B+1","B+2","B1","B2","C+1","C+2","C1","C2","D+1","D+2","D1","D2","D3","E+1","E+2","E1","E2","F","G+","G1","G2","H+","H1","H2","I+","I1","I2","J+","J","K+","K"]"grade_asc" => ["K","K+","J","J+","I2","I1","I+","H2","H1","H+","G2","G1","G+","F","E2","E1","E+2","E+1","D3","D2","D1","D+2","D+1","C2","C1","C+2","C+1","B2","B1","B+2","B+1","A2","A1","A+","S"]2. 查问示例 3. ThinkPHP5的应用形式3.1. 升序 $list = GoodsItem::where('delete_time','=',0) ->field('id,grade') ->orderRaw("find_in_set(grade,'K,K+,J,J+,I2,I1,I+,H2,H1,H+,G2,G1,G+,F,E2,E1,E+2,E+1,D3,D2,D1,D+2,D+1,C2,C1,C+2,C+1,B2,B1,B+2,B+1,A2,A1,A+,S')") ->select();return $list->toArray();3.2. 倒序 $list = GoodsItem::where('delete_time','=',0) ->field('id,grade') ->orderRaw("find_in_set(grade,'S,A+,A1,A2,B+1,B+2,B1,B2,C+1,C+2,C1,C2,D+1,D+2,D1,D2,D3,E+1,E+2,E1,E2,F,G+,G1,G2,H+,H1,H2,I+,I1,I2,J+,J,K+,K')") ->select(); return $list->toArray();3.3.成果 4. find_in_set函数这个函数能够放在where中应用，查问字段是否存在某个范畴内，有点像IN，但还是有区别，具体的前期补上。

之前一期说过在centos下装置宝塔控制面板，当登陆进去新建了数据库，而后在windows应用navicat for mysql 近程连贯数据库始终失败，没有解决就先用阿里的RDS先用着，直到近期找到了办法。    BBC服务器版本(命令# lsb_release -a):     LSB Version:    :core-4.1-amd64:core-4.1-noarch    Distributor ID:    CentOS    Description:    CentOS Linux release 7.5.1804 (Core)     Release:    7.5.1804    Codename:    Core    上面我就还原一下之前遇到问题的步骤：    宝塔控制面板新建数据库 2.设置数据库权限(当然这个数据库的用户是新建的不是root)  本地电脑应用navicat for mysql 连贯数据库，连贯时很慢，大略要一分钟才弹出10038的谬误提醒 我开始是去设置mysql用户组的近程连贯受权权限，(BBC服务器在新装置mysql的root都没有明码所以要先设置一下，具体操作见前几期《如何筛选适合的百度BCC，并装置宝塔控制面板》)，然而不是，其实是mysql的默认端口3306被防火墙拦住了。1.登陆服务器，如果没有nmap工具(端口查看工具)，能够下载一下，命令: yum install nmap    #输出y装置 2.输出命令: nmap 182.161.41.XXX -p3306;     status为open表关上，filtered则是icmp无奈判断该端口的状态，可能是拦了 3.查看防火墙是否开启，留神centos 7.5.1804的防火墙是firewalld服务而不是传统的iptables了，命令: systemctl status firewalld 4.下面“active(running)”示意开启中，上面就新增凋谢端口，命令: firewall-cmd --zone=public --add-port=1000-2000/tcp --permanent // 永恒失效,没有此参数重启后生效也能够间接进入服务器的目录，在根目录下找到firewall的文件夹，而后找到public.xml文件关上  5.新增实现后，重载防火墙，命令: firewall-cmd --reload  重载胜利后，而后再用nmap工具扫一下3306的端口状态当初是什么，open就示意OK了  附:删除防火墙凋谢记录，命令: firewall-cmd --zone=public --remove-port=80/tcp --permanent批改mysql用户组的近程或操作权限，蕴含root。    (1) 登陆数据库: mysql -uroot -p    (2) GRANT ALL PRIVILEGES ON . TO 'root'@'%' IDENTIFIED BY                              'youpassword' WITH GRANT OPTION;　容许地址202.11.10.253上用root用户，明码dboomysql来连贯mysql的所有数据           库，付给select,insert,update,delete权限。    (3) FLUSH privileges; ...

背景:数据库的并发场景下,当读和写并发时,该读到什么样的数据,mvcc就呈现了,不过它只反对Read-Commited和Repeatable-Read两种事务隔离级别. 写写并发和读读并发比较简单,一个加锁,一个不必管.前提条件1:select for update属于以后读,单纯不加for update的select是快照读. 以后读是须要锁的,行锁或者间隙锁,mvcc是无锁的解决快照读的计划前提条件2:db的crud都会当时申请一个事务编号,由数据库治理,递增,这个事务编号会在ReadView里呈现.波及到的元素:版本链:一条数据有隐含字段:最新更新的事务id,undolog的指针;undolog:更新前,把历史数据保留的中央;ReadView:蕴含以后为提交事务id数组,以及该数组中最小/下一个事务id.版本链+undolog:回滚时应用版本链+ReadView:mvcc外围逻辑.外围逻辑:从版本链里找一个 已提交的事务id那条记录,就是能够读到的数据.RR和RC的区别:RR是可反复读,所以ReadView要保持一致,也就是每次读都应用第一次读时创立的ReadView.RC就是每次读都创立ReadView,因为读之间可能会产生数据提交.参考:https://www.bilibili.com/video/BV1hL411479T/?spm_id_from=333....

作者：许祥 爱可生 MySQL DBA 团队成员，负责解决客户 MySQL 及我司自研 DMP 平台日常运维中的问题。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。背景之前碰到客户征询定位 DDL 阻塞的相干问题，整顿了一下办法，如何解决 DDL 被阻塞的问题。上面，就这个问题，整顿了一下思路： 怎么判断一个 DDL 是不是被阻塞了？当 DDL 被阻塞时，怎么找出阻塞它的会话？1. 如何判断一个 DDL 是不是被阻塞了？测试过程如下： mysql> use test;Database changedmysql> CREATE TABLE `test` ( -> `id` int(11) AUTO_INCREMENT PRIMARY KEY, -> `name` varchar(10) -> );Query OK, 0 rows affected (0.01 sec)# 插入数据mysql> insert into test values (1,'aaa'),(2,'bbb'),(3,'ccc'),(4,'ddd');Query OK, 1 row affected (0.01 sec)mysql> begin;Query OK, 0 rows affected (0.01 sec)mysql> select * from test;+----+------+| id | name |+----+------+| 1 | aaa || 2 | bbb || 3 | ccc || 4 | ddd |+----+------+4 rows in set (0.00 sec)# 模仿元数据锁阻塞# 会话 1mysql> lock tables test read;Query OK, 0 rows affected (0.00 sec)# 会话 2mysql> alter table test add c1 varchar(25);阻塞中# 会话 3mysql> show processlist;+-------+-------------+---------------------+------+------------------+--------+---------------------------------------------------------------+-------------------------------------+| Id | User | Host | db | Command | Time | State | Info |+-------+-------------+---------------------+------+------------------+--------+---------------------------------------------------------------+-------------------------------------+| 1 | universe_op | 127.0.0.1:28904 | NULL | Sleep | 12 | | NULL || 2 | universe_op | 127.0.0.1:28912 | NULL | Sleep | 12 | | NULL || 5752 | universe_op | 10.186.64.180:51808 | NULL | Binlog Dump GTID | 605454 | Master has sent all binlog to slave; waiting for more updates | NULL || 28452 | root | 10.186.65.110:10756 | test | Sleep | 73 | | NULL || 28454 | root | 10.186.64.180:45674 | test | Query | 7 | Waiting for table metadata lock | alter table test add c1 varchar(25) || 28497 | root | 10.186.64.180:47026 | test | Query | 0 | starting | show processlist |+-------+-------------+---------------------+------+------------------+--------+---------------------------------------------------------------+-------------------------------------+DDL 一旦被阻塞了，后续针对该表的所有操作都会被阻塞，都会显示 Waiting for table metadata lock。 ...

背景生产环境中 select count(*) from table 语句执行很慢，曾经远超 long_query_time 参数定义的慢查问工夫值，然而却没有记录到慢日志中。在测试环境也很容易复现出该问题，慢查问日志的确没有记录 select count(*) 语句。 慢查问相干参数设置如下： slow_query_log = 1 #开启慢查问日志slow_query_log_file = /mydata/3306/log/mysql.slow.log #慢查问日志文件目录log_queries_not_using_indexes = 1 #开启记录未应用索引的SQLlog_slow_admin_statements = 1 #开启记录治理语句log_slow_slave_statements = 1 #开启主从复制中从库的慢查问log_throttle_queries_not_using_indexes = 10 #限度每分钟写入慢日志的未用索引的SQL的数量long_query_time = 2 #定义慢查问的SQL执行时长min_examined_row_limit = 100  #该SQL检索的行数小于100则不会记录到慢日志select count(*) 执行原理能够总结如下：InnoDB 存储引擎在执行 select count(*) 时，Server 层遍历读取 InnoDB 层的二级索引或主键，而后按行计数。 因而，慢查问日志不应该没有记录到执行工夫超过long_query_time 的 select count(*) 语句。 慢查问日志源码分析为了一探到底，在 MySQL 源码中找到了以下记录慢查问日志的相干函数，本文所波及的 MySQL 数据库版本为 8.0.32。 sql_class.cc 文件中的 update_slow_query_status 函数： void THD::update_slow_query_status() {  if (my_micro_time() > start_utime + variables.long_query_time)    server_status |= SERVER_QUERY_WAS_SLOW;}my_micro_time 函数返回的是以后工夫，如果以后工夫大于这条 SQL 执行的开始工夫加 long_query_time 参数定义的时长，则更新这条 SQL 的 server_status 为 SERVER_QUERY_WAS_SLOW。 log.cc 文件中的 log_slow_applicable 和 log_slow_statement 函数： bool log_slow_applicable(THD *thd) {......  bool warn_no_index =      ((thd->server_status &        (SERVER_QUERY_NO_INDEX_USED | SERVER_QUERY_NO_GOOD_INDEX_USED)) &&       opt_log_queries_not_using_indexes &&       !(sql_command_flags[thd->lex->sql_command] & CF_STATUS_COMMAND));  bool log_this_query =      ((thd->server_status & SERVER_QUERY_WAS_SLOW) || warn_no_index) &&      (thd->get_examined_row_count() >= thd->variables.min_examined_row_limit);  // The docs say slow queries must be counted even when the log is off.  if (log_this_query) thd->status_var.long_query_count++;  /*    Do not log administrative statements unless the appropriate option is    set.  */  if (thd->enable_slow_log && opt_slow_log) {    bool suppress_logging = log_throttle_qni.log(thd, warn_no_index);    if (!suppress_logging && log_this_query) return true;  }  return false;}判断该 SQL 是否满足记录慢查问日志的三个条件： server_status 标记为 SERVER_QUERY_WAS_SLOW;warn_no_index 没有应用索引;该 SQL 检索的行数 >= min_examined_row_limit 参数定义的行数。如果该 SQL 满足记录慢查问日志的条件，那么则调用 log_slow_do 函数写慢查问日志。 ...

此文为了确定MySQL联结索引的笼罩问题。 首先联结索引是建设在「最左前缀」准则之上。 其次select字段也须要被索引笼罩，否则会进行回表查问。 测试筹备MySQL 版本 8.0.32-arm64版本，InnoDB引擎。 创立一张表名test_index，有 a、b、c、d、e 共5个字段。其中a、b、c、d 4个字段按程序组成的联结索引，索引名称为idx_abcd。e为非索引字段。 explain select * from test_index where a = 1;（笼罩a） explain select * from test_index where a = 1 and b = 1;（笼罩a、b） 后果：type=ref, key = idx_abcd, Extra = null where条件笼罩索引前导列，但select字段未被索引笼罩 explain select a,b,d from test_index where a = 1;（笼罩a） explain select a,b,c from test_index where a = 1 and b = 1;（笼罩a、b） 后果：type=ref, key = idx_abcd, Extra = Using index ...