先定业务的资源画像，再选规格，顺序反了最容易多花钱。有现成业务的话，跑一周监控，拿到 CPU 和内存的峰值和均值，再看磁盘 IOPS 和网络带宽就够了。新业务没有监控数据，就按同类业务的量级先估一档，留出扩容余地，别一次买满。只看核数选型是个常见坑，同一核数不同代际的主频和单核性能差不少，内存型和计算型的配比也要分开看，数据库类先看内存和磁盘延迟，计算类先看 CPU。给几个落地的参考数。内存按峰值留三成余量，长期跑在八成以上就该扩容，长期低于两成就是买大了。CPU 看 steal 时间和饱和度，持续跑满先查是不是单核瓶颈，加核不一定有用。磁盘把系统盘和数据盘分开，数据盘按 IOPS 需求选类型，别用系统盘扛业务 IO。成本分开算。计费方式先算清楚，长期稳定跑的业务包年包月比按量便宜，潮汐明显的业务按量加弹性伸缩更划算，关机后云硬盘、弹性 IP 和带宽还在计费，只关机不清资源账单照样走。规格本身先买小一档，监控跟上，不够再升配，升配比一开始买大再降配容易。复核每月做一次，看利用率和账单，把长期闲置的实例清掉，没挂载的数据盘和没用的弹性 IP 也一并处理。选型没有一次到位的答案，业务量变了规格也要跟着复核，监控数据比经验值更可信。

前面几楼把位置不同带来的延迟、语言和连接差别讲全了，我补三处选型时容易事后才发现的地方。第一处是协议仿真。代理要把自己伪装成数据库服务端，握手认证和预编译语句这类协议细节都要在代理这一层处理，会话变量和事务状态也要由它维护或透传。应用换个驱动版本，或者用上服务端预编译，行为可能就变了，排查时要先核对代理版本对这些特性的支持情况。客户端分片没有这一层，驱动就是原生驱动，这类问题本来就不存在。第二处是连接数的算法。客户端方式下，数据库侧的连接数大致等于应用实例数乘以每实例的池大小再乘以分片数。代理方式下，数据库侧的连接数大致等于代理节点数乘以代理的池大小再乘以分片数，应用侧的连接则由代理来承受。两笔账算的不是同一个数，扩容前先算清楚，不然会出现应用扩了没事、数据库连接先满了，或者反过来代理的连接池先满了。第三处是慢查询对不上。代理日志里记的是改写后的分片 SQL，应用日志里记的是原始 SQL，两边的耗时口径也不一样，代理侧含归并等待，应用侧含网络往返。定位慢查询要先把同一条 SQL 在两边的记录对齐，再判断慢在哪一环，拿一边的耗时直接怪另一边容易找错方向。---脱敏自查：无个人信息、无服务器 IP/端口/规格、无业务细节、无短剧技能与模板内容；示例均为通用数据库知识。去 AI 味自查：无翻案腔、无顿号三连、无破折号、无提示语冒号、无序数小标题、无拟人喻体、无“说白了/先说结论”、无万能正能量结尾。

前面几楼把正常刷盘和被迫刷盘的区分讲清楚了，我补一个排查时的分辨方法和一个容易调反的参数。先看两个计数，分开看，别混成一句刷盘慢。Innodb_buffer_pool_wait_free 大于 0，说明前台线程在等空闲页，卡在 LRU 刷盘这一环。Innodb_log_waits 大于 0，说明在等 redo 日志空间，卡在 checkpoint 这一环。两个计数指向的调法不一样，前者先看空闲页为什么不够，后者先看 redo 容量和刷盘速度哪边跟不上。再看 page cleaner 的数量。innodb_page_cleaners 默认是 4，缓冲池实例数比它多的时候，一个 cleaner 线程要轮着刷多个实例，单个实例的脏页可能排不上队。实例数和 cleaner 数对不齐时，调脏页比例和 redo 容量都可能效果不明显，先把这两个数对齐再看。还有一种卡顿不在刷盘参数里。刷盘本身会占用磁盘，业务读请求也要走同一块盘，脏页比例不高、磁盘延迟却上去了，就可能是 page cleaner 和业务读在争 IO。这时把 innodb_io_capacity 调高只会让争抢更厉害，适当调低、让出读请求的带宽，反而能让延迟先下来。判断方法是看脏页比例和磁盘延迟是不是同时涨，两个不同时涨，就别往刷盘参数上使劲。

前面几楼把两步写的流程和恢复逻辑讲全了，我补两处平时容易忽略的地方。一处是落盘顺序。双写区那份副本必须先写完并且真正落盘，数据文件里的页才能开始写。这个顺序不能反，顺序反了，断电时可能出现双写区和数据文件各坏一半，恢复时两边都找不到完整页。判断一份实现合不合格，看它是不是先刷双写区再写数据文件，比看它写了几遍更直接。另一处是恢复时怎么找到那一页。重启后校验发现某页损坏，恢复程序按页的编号到双写区里找同一页的副本，找的是页本身，不是按时间找最近写过的那批。双写区是循环复用的，找得到的前提是那一页的副本还没被后来的刷盘覆盖，这也是双写区只能兜底单页损坏的原因，跨多页的损坏它管不了。运维上还有两个现成的观察点。SHOW GLOBAL STATUS 里的 Innodb_dblwr_pages_written 是写进双写区的页数，Innodb_dblwr_writes 是批量写次数，前者除以后者能看出每批平均带多少页，写放大主要看前者。启动日志里如果出现从双写区恢复页的记录，说明此前确实发生过页损坏，恢复完之后最好检查一下那段时间有没有断电或存储报错，别只当成一次成功恢复就过去了。

补一个最容易被误解的词：清理。purge 推进时同时做两件事。一是把 delete 打了标记的记录从索引里真正删掉，二是回收这些记录对应的 undo 页。判据是同一条线，某个版本对现存所有 ReadView 都不可见了，它才能动。所以长事务钉住的不只是 undo，它后面的删除标记记录也一样删不掉，表会越查越慢，这和 undo 膨胀是同一个根源。回收 undo 页也不等于文件变小。purge 先把 undo 页从 history list 上摘下来，放回对应回滚段的空闲列表，下次写 undo 直接复用，undo 表空间文件本身不会缩。要让文件真正缩小只能靠 truncate，条件很硬。用的是独立 undo 表空间，innodb_undo_log_truncate 得开着，大小要超过 innodb_max_undo_log_size，而且那个表空间得先被置为 inactive 并完全清空，系统才会把它截断到初始大小。8.0 默认建两个 undo 表空间轮着来，就是为了让其中一个有机会被清空截断。线上看到 undo 文件涨上去不回落，多半是这个机制没触发，purge 其实一直在干活。还有一个时间差。长事务结束后，积压的 history list 不会瞬间清零，purge 按批次往前推，一批只处理 innodb_purge_batch_size 限定的页数，默认 300。积压大的时候，SHOW ENGINE INNODB STATUS 里的 History list length 是慢慢往下掉的。看到它在持续下降就是在正常追赶，别急着重启或者杀 purge 线程。

补三个容易落到实处的点。ReadView 的生成时机还有两个变体。自动提交模式下，每条普通 SELECT 自己就是一个事务，语句开始时生成 ReadView，语句内一致，语句之间不保证一致。用 START TRANSACTION WITH CONSISTENT SNAPSHOT 开事务，ReadView 会在开始那一刻就建好，不必等第一条查询。mysqldump --single-transaction 在 RR 下拿一致性快照靠的也是这个，长备份期间查到的是同一个时间点的数据。间隙锁的实际范围要看命中情况。等值条件打在唯一索引上并且命中了行，next-key lock 会退化成记录锁，只锁那一行，不锁两边间隙；等值没查到行，锁的是那行该在的间隙；非唯一索引的等值查询和范围查询，间隙照锁。同样是 RR，两条 SQL 锁住的范围能差很多。拿不准时查 performance_schema.data_locks，LOCK_MODE 里带不带 GAP、REC_NO_GAP 标记，把实际范围标得很清楚，比猜可靠。间隙锁是有代价的。它和插入意向锁冲突，高并发往同一个范围插数据，或者先按范围查再往里插的写法，很容易互相等，严重的直接死锁，报错日志里会出现 gap lock、insert intention 这类字样。不少系统把隔离级别从 RR 降到 RC，就是为了去掉大部分间隙锁；binlog 用 row 格式之后，RC 的主从一致性问题也没了，这是它敢降的前提。

补三个前面没展开的点。一个是名字很像的插入意向锁。它和意向锁没有关系，是行级的一种间隙锁。事务往间隙里插入一行，发现目标范围被别的事务的间隙锁挡住时，会先排一个插入意向锁表示自己在等，等间隙锁释放后，它转成正式的行锁再完成插入。在 performance_schema.data_locks 里能看到它，LOCK_TYPE 是 RECORD，LOCK_MODE 带 insert intention 字样。看到这个字段别往表级意向锁上想，它卡住通常是并发往同一范围插数据，处理思路完全不同。第二个是排查时别把意向锁和元数据锁（MDL）混在一起。长事务占着表时 ALTER TABLE 卡住，多数情况是在等 MDL；意向锁负责的是 LOCK TABLES 这类显式表锁与行锁之间的冲突判断。两个等待看的地方也不一样，意向锁看 data_locks 里 TABLE 粒度的 IS、IX 记录，MDL 看 metadata_locks。卡住的原因认错了，后面的处理就全错了。第三个是日常谁会真的撞上 IX。mysqldump 加 --lock-tables，或者手工执行 LOCK TABLES t READ，要拿的是表级 S 锁，它和 IX 冲突。表上只要有一个未提交的写事务，哪怕只改了一行，表级读锁就得等它结束。反过来也一样，表级读锁没释放时，新的 UPDATE 拿不到 IX，会堵在那里。所以备份窗口和长事务撞上时，先查有没有未提交的写事务，顺序别反了。

前面几楼把三类写法和验证流程讲得挺全了，我补几个实操里容易判断错的方向性问题。转换看转的是哪一侧。varchar 列拿数字比，转换发生在列上，要逐行算，索引失效；反过来，int 列拿字符串 '123' 比，MySQL 转的是常量，转一次就完事，索引照常走。排查时先看被转的是列还是参数，只有列被转才失效。ORM 框架传参类型飘忽时最容易中招，表里是 varchar，代码里拿 Long 传参，慢查询就是这么来的。字符集不一致也是同样的道理。JOIN 的两列一个 utf8mb4、一个 utf8mb3，比较时 utf8mb3 一侧会被转成 utf8mb4。被转的是驱动表关联列还好，被转的要是被驱动表的关联列，它的索引就用不上了。所以同一条 SQL，数据量变了、驱动顺序换了，执行计划会突然变样，根源常在这里。LIKE 还有一种常被漏掉的情形。对数字列写 LIKE '13%'，列会被转成字符串再逐行匹配，定位不到索引。业务上真有按号段查的需求，改成 >= 和 的数值区间更快。常量侧的运算不用慌。WHERE id + 1 = 100 是在列上运算，失效；WHERE id = 100 - 1 的运算在常量侧，优化器会先把它折算成 id = 99，照常走索引。看到条件里有加减，先分清在哪一边，再决定要不要改。最后是判断口径。EXPLAIN 显示 type=ALL 有两种可能，一种是写法让索引失效，另一种是索引没失效，但区分度太差，优化器算过账觉得全表扫更便宜。后一种改写法没用，要从索引区分度或数据分布上处理。用 EXPLAIN FORMAT=JSON 看它估算的 cost，或者 FORCE INDEX 对比两种计划的实际耗时，就能分清是哪一种。

前面两楼把定位规则讲全了，我补三处容易漏的。其一，LIKE 前缀。索引 (a, b, c) 里 a 用 LIKE 'abc%' 还能定位，因为前缀在 B+ 树里仍是一段连续区间；改成 LIKE '%abc' 就不行，开头通配等于没给定位起点，只能全区间扫。其二，范围列在第一列。查 a > 10 AND b = 2，a 的范围一展开，b 在区间里就不再有序，b 定位不上，ORDER BY b 也用不上这棵索引排序，还要额外排序。其三，定位不上的列也还有用。查询要的列都在 (a, b, c) 里时，即使 b、c 只起过滤作用，引擎也不用回表，EXPLAIN 里会出现 Using index。ICP 是在索引层过滤，覆盖索引是连表都不回，两者省的是不同环节。判的时候还是看 key_len 和 Extra：key_len 到哪列停，定位就到哪列；Extra 里 Using index condition 是过滤，Using index 是覆盖。

帖子里关于副本数的说法已经互相打架了。按每 8 到 10 节点一个副本算；按节点比例 1 比 10 到 1 比 20 算；按峰值 QPS 估算，算出来的数都不一样。直接套任何一个都可能套错。副本数应该按故障时段实测的查询量和延迟反推，帖子里没有这些数，所以现在只能排查，不能定性。定性这件事，至少要补四样数据。集群一共多少节点，CoreDNS 现在几个副本、每个副本的 CPU 和内存配额是多少，故障时段 CoreDNS 的日志和延迟指标，以及客户端拿到的完整报错文本。没有这四样，到底是 CoreDNS 瓶颈还是节点网络问题还是上游问题，分不出来，扩副本也可能扩错地方。还有一个上面提得少的对照：应用解析时常常同时查 A 记录和 AAAA 记录。如果集群里 IPv6 本来就不通，AAAA 查询的超时会把整体解析拖慢，看起来像 CoreDNS 卡住了。可以用 dig 单独查一次 AAAA 记录的耗时，再和 A 记录对比，先确认是不是 AAAA 在拖时间，再决定往哪边查。