ActionTech的博客

我发现应用有一根访问数据库的连接有异常流量，如何判断是应用哪个逻辑导致了异常行为

问有没有简单的方法，判断 IO 延迟对 MySQL 性能的影响大小实验我们找一台 IO 比较差的虚拟机，如果找不到，那么你确实很有钱。依旧宽油起一个 MySQL 实例：先用 sysbench 准备一张表：然后测一下性能记得多跑几次预热，此处只取最后一次的结果运行压力时，同时取一下 iostat：我们发现磁盘 IO 并没有饱和，那么磁盘 IO 的正常延迟， 会对这组 MySQL 的性能造成多大影响呢？我们来用内存模拟一下磁盘，使用以下命令：我们停下数据库，将数据目录移到模拟.

问在 MySQL 运行时，我们调整系统时间，会造成什么影响么？实验按惯例，我们造个数据库：在一个会话里，进行vsleep：在 sleep 的同时，我们将服务器的时间向未来调整 10 秒：我们会发现，sleep 立刻退出，只执行了0.82 秒：我们在业务中很少会用到 sleep，那么调整系统时间会有更大的影响么？我们再来看看：我们在一个会话中，锁住一张表：在另一个会话中, 我们做如下几件事:先打印一个时间戳调整 lock_wait_timeout访问 test.a 表.

问我们在 第12问 中介绍了 table cache 的作用: 在同一个线程内， 减少了重复读取表定义的成本，包括读取表定义文件的 IO 成本， 和 构造内存结构的 CPU 成本。(要注意 table cache 是线程级别的)同时我们发现了一个问题， 即使没有命中 table cache ，MySQL 也不一定会从表定义文件中读取。这就是因为命中了 table definition cache (之后我们简称为 TDC)，TDC 是全局级别的表定义缓存本期我们就来介绍一下 table defin.

问MySQL 使用的文件句柄数 突然增加, 我们该如何诊断实验我们接着宽油起一个数据库:翻倍法造表 a :将 a 表造的大一点:给 a 表追加一列:再造个表 b :让我们来下一个 SQL :在 SQL 执行的过程中, 观察 MySQL 的文件句柄数, 发现文件句柄在不断上升:现在我们来诊断 为什么 MySQL 的文件句柄数会上升.我们动用 perf , 来追踪 打开句柄的系统调用然后我们调用 perf script , 经过一段等待后我们会得到不少结果, 我们摘取其.

问在 第44问 中, 我们使用 tcmalloc 提供的工具, 来查看 MySQL 的内存分配该方法对性能影响不大, 可以在生产环境运行, 但需要将 MySQL 的分配器配置成 tcmalloc在本次实验中, 我们介绍另外一种方法, 针对于 MySQL 的内存突增情况进行诊断实验我们依然宽油起一个数据库:本实验中, 我们需要模拟MySQL的内存突增的情况. 我们从 MySQL 的 bug 库里找到一个易于复现的相关 bug: https://bugs.mysql.com/bug.php?id.

问当 MySQL 内存异常上涨, 我们可以通过 performance_schema 观察内存的使用, 我们在**实验5**中进行过介绍。但我们也会发现操作系统统计的 MySQL 内存用量比 performance_schema 统计的 MySQL 内存用量要多。那么 MySQL 的内存消耗, 有哪些是不在 performance_schema 统计内的呢?本期我们设计实验来观察这个问题实验我们先安装 google-perftools:安装后, 可以找到相关的库:宽油起一个数据库:.

问当我们使用一个事务操作很多数据时, MySQL 有时会报错: The total number of locks exceeds the lock table size根据官方文档, 我们需要调大 buffer pool 的大小:本期实验, 我们来探索一下锁用得多与 buffer pool 大小的关系实验我们用老方法建一个数据库, 并将 buffer pool 大小调整到了最小值5M, 方便我们复现问题现在来模拟一个用锁特别多的事务:我们还是用老方法让表翻倍, 来不停地占用锁.看一.

问在 MySQL 8.0 中, 使用临时表时, 会发现有1G的磁盘空间"消失"了实验我们先宽油做一个 MySQL 8.0.25 的实例. 此处我们忽略创建的步骤, 大家可参考以前的实验.还是用我们熟悉的翻倍法, 造一张表:不停执行最后一句 SQL , 让表中含有足够多的记录:这里我们设置两个临时表的配置参数, 稍后再解释其作用:我们还需要设置好 performance_schema , 用来观察整个过程:还需要记录一下目前的磁盘容量:现在我们下一个使用临时表的 SQL , 参考.

问在图解系列中, 我们介绍过组提交的概念 (https://mp.weixin.qq.com/s/_WVE1xtGdtXEcwkTf7j_rA), 这次我们通过实验来观察其作用实验照例宽油起一个数据库:这里我们调整了刷盘节奏, 使得现象会更明显一些. 同时, 双一的刷盘配置也是生产环境保持数据可靠的推荐配置.我们进行一次压测:开启压测的同时, 使用 pt-ioprofile 监控 IO :我们再进行一次压测, 这次将压力并发调大一倍:压测的同时, 还是使用 pt-ioprofile.

问MySQL 中在运行一个 DDL , 此时我们对这个 DDL 进行 kill , 那这个 DDL 多久会被 kill 掉?要讨论这个问题, 我们需要拆分问题: DDL 多久会被 kill 掉 = DDL 多久会开始 kill + DD L的回滚收尾操作进行了多久本实验只讨论如何观察: DDL 多久会开始 kill实验参考第16问, 我们起一个数据库, 并让其在调试模式运行.首先宽油起一个数据库实例:改一下 start 脚本, 配置成调试模式:重启数据库, 启动的时候增加 –debug.

问我们在第16问中使用过 mysql 内置的调试版本 mysqld-debug ，但有些 MySQL 版本中没有内置的调试版本.这次介绍一下如何编译一个调试版本实验我们先准备一个安装了 docker 的环境, 之所以用容器, 是因为我们在进行各种试验后, 可以将容器毁掉重建, 保持系统环境干净统一, 非常便利.首先开启一个 devtoolset 容器:确认自己在容器内:下载 MySQL 源码包并解压:接下来安装依赖包, 一共分为 3 类依赖: 编译用的工具, MySQL 的依赖包, .

问为什么我使用分区表, 有时候是几个锁, 有时候是几百把锁, 阴晴不定实验我们先宽油起一个数据库:建一个分区表:我们希望根据 timestamp 的日期进行分区, id 作为主键. 由于分区键必须是主键, 所以我们将 timestamp 加入主键中.下面我们来研究一下使用分区表时, 分区表到底会用多少个锁.先插入两条数据:场景1:我们用 RC 隔离级别, 锁定 id = 1 的记录此时, 查看锁信息:可以看到:由于我们在 where 条件里没有用到分区键 timesta.

问题追求 MySQL 的性能时，总听说要调整自旋锁的参数: innodb_spin_wait_delay 和 innodb_sync_spin_loops，是真的么？实验首先我们要知道自旋锁的优点：自旋锁要上锁时，如果需要等待其他线程释放锁，那么：在等待锁的过程中会先线程会先自旋一段时间自旋阶段，线程不会放弃 CPU自旋过后：如果可以获取锁了，那么响应会比较快（自旋没发生上下文切换）如果还需要等待锁，再用更高成本的方式进行锁等待innodb_spin_wait.

问题用 mysqlslap 压测 SQL 的结果，好像比用 sysbench 压测 SQL 的结果更平稳，为什么？实验随便找个数据库，我们用以下 SQL 进行压测：select sleep(@val := coalesce(@val, 0) + 1) from dual;这个 SQL 每运行一次，sleep 的时间都会加一秒。第一次是 sleep(1)，第二次是 sleep(2)，…我们先用 mysqlslap 进行压测：查看结果：解读一下 mysqlslap 的结果：每轮 .

问题：InnoDB 刷脏页刷得比较慢，我的业务会受到影响么？如何进行试验验证？实验先宽油建个数据库：找到这个数据库负责刷脏页的线程号：我们起一个 gdb，（别害怕，本实验没有什么太深的调试技巧。）我们输入以下命令：前三行命令，允许 gdb 只停下一个线程，而不是停下所有线程。最后一行 attach，我们让 gdb 管控我们的 MySQL 实例。经过一堆看不懂的输出，gdb 已经管控了 MySQL 实例，可以输入命令了。我们先输入 info thread，拿到 MySQL 的线.

问题这是一个同行问的问题：有一张表，带一个联合索引，SQL 不满足最左匹配，为什么执行计划显示能用到这个联合索引？叨叨叨有经验的 DBA 此刻已经知道原因了。本文立意主要是介绍诊断的方法，方便大家在没有相关知识时找到线索。实验起手先来个数据库：造个表：看一下执行计划：看上去确实有点怪，我们来分析一下：这个 SQL 不满足索引的最左匹配的原则（跳过了 b 列，直接使用 c 列），不应该选择联合索引。但执行计划确实选择了联合索引，可能是优化器在起作用。我们在实验 27 中介绍过如何.

问题随着 MySQL 使用的内存越来越大，我们建议使用多个 buffer pool instance。那么我们的问题是: 一张表有多少在 buffer pool 中，一张表只能在一个 buffer pool instance 中么？实验这期的实验很短很简单，先宽油起一个数据库：接下来，我们建一个有数据的表，建表的方法参考实验 11：反复执行 insert，让表里有更多数据：我们查询一下 buffer pool 的分布：这里会输出 196 行，我们将结果手工简化一下来分析（如果是 .

问题：MySQL 官方文档说 innodb_log_buffer_size 是 redo log 的写缓存，设置大一点能减少写操作。我们用实验来学习一下这个参数的作用。实验：宽油起个数据库：先将 innodb_log_buffer_size 设置为最小值。接下来，我们先建一个有数据的表，建表的方法参考实验 11：重复执行最后一句 insert，直到表中有 65536 行数据：接下来我们复制一张表，因为我们要做两次实验：接下来我们开启 innodb metrics 和 perfor.

问题：在小伙伴们学习的过程中，执行了一个 insert，然后发现了以下现象：首先在 binlog 中，发现这条 SQL 运行了 2 秒 (上一问中, 我们知道 BEGIN 的 exec_time 等于事务第一个 SQL 的 exec_time，本例中就是 insert 的 exec_time)但在慢日志中,发现这条 SQL 的 query_time 为 10 秒:那么 binlog 和慢日志谁的时间更准确一些？实验首先我们按照第 02 问的步骤，准备一个慢 IO 的设备，使读操作和写操作都.

问题一段 binlog 如上图，为什么这个 BEGIN 执行了 5 秒，是数据库卡了还是统计错了？实验先宽油做一个数据库：为了实验方便，我们改一下 mysql 的提示符，将命令行的当前时间显示在上面，将 binlog 格式改为 statement：创建一个实验表：跑一个事务：解开对应的 binlog：得到结果：我们看到三组时间：1. 黄色部分：每个 binlog event 前都会带有一个时间戳，这个时间戳和我们执行每个语句时的开始时间对应（截图中会偶尔偏差 1s，是.

问题最近年底，大家的数据库经常跑批量大事务，会发现复制突然断开，报错“心跳与本地信息不兼容”： 会是什么原因？实验我们先来复现一下，再进行分析。宽油，做一对主从数据库：我们先造一个 500M 的空文件，下一步有用： 再制造一张大表，这里用到了之前的造表法，不同的是使用了一个 longblob 字段，让少数的几行记录就能占用很大的 binlog 空间，方便我们后面做实验。这里的 longblob 字段，用到了上一步我们做的空文件， 这样我们获得了一个行数较少，但体积很大的表。现在起两个.

问题我们经常使用浮动 IP（SIP，或叫 VIP），来完成数据库的高可用部署。业务通过访问浮动 IP，始终访问主数据库。如果业务正在访问数据库时，数据库主从发生切换，导致 SIP 漂移，那正在使用的数据库连接会受到影响么?实验我们创建同子网的两台虚拟机，分别安装 MySQL。再准备一台额外的虚拟机，用来模拟业务，访问数据库，此处省略安装过程。这两台虚拟机的 IP 分别是 x.x.x.37 和 x.x.x.39，为了容易区分，我们设置 PS1，来区分两个 linux 的会话。下图以 37 为例.

问题在 26 问中，我们看到了如下 SQL 在 MySQL 5.7 中跑得很慢：我们还分析了执行计划改写后的 SQL，通过猜测，增加了 hint 来解决问题：这一期，我们通过工具来分析一下：MySQL 为什么会使用一个低效的执行计划，以致于我们不得已用 hint 来调优 SQL？实验我们接着使用 26 问中的环境，使用 optimizer trace 工具，观察 MySQL 对 SQL 的优化处理过程。我们先调大 optimizer trace 的内存容量（否则 trace 的输出会被截.

问题我们有一个 SQL，用于找到没有主键 / 唯一键的表，但是在 MySQL 5.7 上运行特别慢，怎么办？实验我们搭建一个 MySQL 5.7 的环境，此处省略搭建步骤。写个简单的脚本，制造一批带主键和不带主键的表：执行一下脚本：现在执行以下 SQL 看看效果：…执行了 16.80s，感觉是非常慢了。现在用一下 DBA 三板斧，看看执行计划：感觉有点惨，由于 information_schema.columns 是元数据表，没有必要的统计信息。那我们来 show war.

问题在 09 问中，我们开启了 coredump 功能，在 MySQL 崩溃时获得了有用的 coredump 信息。那如果没开启 coredump，仅有 error log 中的堆栈信息，我们如何分析有效的信息？实验我们沿用 09 问中的 MySQL 崩溃的场景，此处忽略复现崩溃的步骤，大家参看 09 问查看 error log：我们拿到了崩溃位置 0xee36f1，如何找到与之相对的代码位置呢？找台测试机，获取对应版本的安装包：解压：然后用 GDB 打开 mysqld：在 0xe.

问题我们都知道，半同步复制中，如果 slave 比较慢，会拖慢 master 的提交性能。那么，在一主多从的半同步架构中，如果 master 的提交性能慢，如何判断是哪个 slave 拖慢了性能？实验先通过 dbdeployer 快速搭建一主两从半同步集群：下面给 master 施加一些压力：然后我们用 strace，拖慢 slave2 的运行速度。由于半同步复制的原因，现在 slave2 拖慢了 master 的提交性能。我们开始诊断，设置半同步插件的日志级别为 16：查看 ma.

问题我们都知道，MGR 用了类 Paxos 机制的协议，协商过程只要多数节点同意即可达成一致。那么对于 3 节点的 MGR 集群，我们能不能让某一个节点延迟较高（放在地球另一端），而不影响整体性能？实验我们省略搭建 MGR 集群的过程，得到一个 3 节点的集群：将 3 个节点的流控功能全关掉，让数据压力能尽情跑：下面来跑一个 sysbench 压力，这里用 ts 命令，给命令输出的每一行增加了时间戳：然后我们给 mgr-3 节点增加一些网络延迟：运行一段时间后，取消网络延迟：来.

问题在 实验 8 中，我们为表生成了测试数据。有小伙伴问：如果两个表有外键关系，我们生成的随机数据没法满足外键关系，怎么办？实验先来建一个测试库：建两张有外键关系的表：先为 office 表灌入一些基础数据：然后为 user 表灌入支持外键的数据：来看一下我们生成的效果：可以看到生成工具为 office1 和 office2 两个外键列都生成了符合外键规范的数据：而外键数据的采样数量正是 100。???? 小技巧如果大家希望为不同的外键列，生成不同采样数量的数据，可以创

问题我有个大的 SQL 文件要回放，需要马上做，但又怕压死业务，怎么办？实验先来建一个测试库：塞一些数据进去：看看我们塞数据的成果：使用 mysqldump 导出一份数据：现在我们假设要把这个dump文件，回放到一个数据库中，并且现在数据库正在承担很重的业务，我们不希望业务受到太大影响。先来看看如果直接回放 dump 文件，会发生什么？我们看到 MySQL 的 cpu 会彪起来，我们换一个方式来回放 dump：看看 CPU 压力：可以看到 CPU 已经非常冷静，并且.

问题我写错了脚本，ibd 文件被删除了，该往哪个方向逃跑？实验先来建一个测试库：我们在这里开启了 innodb_file_per_table，但这个参数并非本实验所必须，只是为了演示方便。然后模拟一个业务压力：现在删掉相关的表文件：可以打开地图 app，选择一个方向开始跑路了…然而我们还可以挣扎一下，查看一下 MySQL 占用的句柄：找到被删除的表：可以看到，除了临时表，被我们手工删除的表也在其中，对应文件句柄号 54。现在我们把数据库的流量锁起来（如果使用了支持 of.

问题已知情况如下：MySQL 版本为 8.0.21（随 8.0 的小版本升级，MGR 参数和行为变更频繁，需要特别注意版本号）。MGR 架构，一个节点 C 网络不稳时，与其他节点的通讯断开。通讯断开后，一定时间内（5 秒 + group_replication_member_expel_timeout 秒）a. 其他节点开始质疑节点 C 可能掉线。在其他节点上，节点 C 的状态为 UNREACHABLE。b. 其他节点仍然能协商并提交新事务，其协商的信息会保存在消息缓存中。通讯恢复后，节点.

问题我的 MySQL CPU 高了，看了一下 processlist，实在有太多行了，我要不要准备辞职？实验MySQL CPU 飚高的原因有很多种，我们先分析一种最简单常见的。还是先建个数据库：还是按照之前实验 11 的技巧，快速造一些数据：反复执行最后一句 SQL：下面来执行一条比较坑的 SQL，让 CPU high 起来：现在我们忘掉之前做了什么，就来处理这个 CPU 高的问题。先用 top -H 找到 CPU 高的线程，这里可以看到 CPU 高的线程一直是 17967（.

问题我们执行 alter table 语句后，经常面临“跑又跑不完，杀又不敢杀”的窘境。如果能评估 alter table 的进度就幸福多了。实验MySQL官方已经给出了文档：https://dev.mysql.com/doc/refman/5.7/en/monitor-alter-table-performance-schema.html，我们来实践一下：先建个数据库：我们设置了一些跟 performance_schema 相关的参数，开启了查看进度必要的功能。还是按照之前实验 11的技.

本文关键字： 统计表，debug问题​我们知道在 MySQL 中创建一张表时，一些统计表会发生变化，比如：mysql/innodb_index_stats，会多出几行对新表的描述。那么会变更几张表？这些统计表是如何变化的？实验本期我们用 MySQL 提供的 DBUG 工具来研究 MySQL 的 SQL 处理流程。起手先造个实例这里得稍微改一下实例的启动文件 start，将 CUSTOM_MYSQLD 改为 mysqld-debug：重启一下实例，加上 debug 参数：我们来做..

本文关键字：大事务、binlog、Linux问题我们并不喜欢 MySQL 中出现大事务（更新很多数据的事务），大事务往往带来很多维护的问题。我们在维护 MySQL 时，需要关注于是否出现了较大事务，在 binlog 里找到其出现的证据。实验我们先创建个数据库：这里我们启用了 GTID，对于非 GTID 的 binlog，大家也可以用类似的方法处理。下面需要创建一些大小不同的事务，我们使用在 第11问 里使用过的手法，反复执行，下面我们开始研究 binlog，先解开一段看一下，..

本文关键字：MGR、监控、Wireshark问题在一个 MGR 集群里，一个节点异常退出后，MySQL 会如何进行调度？异常的节点什么时候会被踢出集群？实验实验开始前，给大家分享一个小经验：选择合适的观测工具，如果没有，就创造一个。我们先使用三台虚拟机，创建一个 MGR 的集群。MySQL 的版本是 5.7.20（之所以使用低版本的 MySQL，因为恐怕没有人能说清楚这个低版本的 MGR 的行为，不能扯淡只能观测）。这次我们忽略这一操作步骤，只看一下创建好的集群：检查一下谁是 Prim..

问题用 pt-table-checksum 时，会不会影响业务性能？实验实验开始前，给大家分享一个小经验：任何性能评估，不要相信别人的评测结果，要在自己的环境上测试，并**（大概）知晓原理**。我们先建一对主从：然后用 mysqlslap 跑一个持续的压力：开另外一个会话，将 master 上的 general log 打开：然后通过 pt-table-checksum 进行一次比较：查看 master 的 general log，由于 mysqlslap 的影响，general .

问题我们都知道 MySQL 的 Table Cache 是表定义的缓存，江湖上流传着各种对这个参数的调优方法。本期我们通过实验来验证 Table Cache 的作用。实验我们先创建一个测试数据库：建一张空表：建立一个连接，检查一下会话的初始状态：在另一个窗口，开启 strace 追踪 MySQL 服务器的文件操作：在 MySQL 中 select 新创建的表：检查状态：看到该操作没命中 table cache。查看 strace，确实发现 mysqld 进程打开了表结构文件.

问题有时候我们会不小心对一个大表进行了 update，比如说写错了 where 条件…此时，如果 kill 掉 update 线程，那回滚 undo log 需要不少时间。如果放置不管，也不知道 update 会持续多久。那我们能知道 update 的进度么？实验我们先创建一个测试数据库：快速创建一些数据：连续执行同样的 SQL 数次，就可以快速构造千万级别的数据：查看一下总的行数：我们来释放一个大的 update：然后另起一个 session，观察 performance_.