一、为什么这几类问题总是反复出现

在MySQL日常运维中，真正让DBA深夜被叫醒的，往往不是新特性，而是三类老问题：主从复制异常、慢查询突增、死锁报错。它们的共同点是：现象直观、根因分散，既可能来自数据库参数与架构，也可能来自业务SQL写法或突发流量。本文按“现象—定位—验证—修复”的顺序，梳理一套可直接落地的排查清单。

二、主从复制类故障

1. 主从延迟持续增大

• 先看状态位：执行 SHOW REPLICA STATUS（旧版本为 SHOW SLAVE STATUS），关注 IO 线程、SQL 线程是否为 Yes，以及错误信息。
• 理性看待延迟秒数：Seconds_Behind_Master 由从库本地时间与事件时间戳计算得出，长事务、时钟不同步、IO 线程断开时都可能失真，需结合位点差值判断。
• 查大事务与批量写：单事务更新大量数据、大批量导入、大表DDL，都会让从库应用线程长时间阻塞。
• 查从库自身负载：从库承担备份、统计报表、离线查询时，磁盘IO与CPU竞争会显著拖慢回放。
• 查复制并行度：并行复制是否开启、能否按库或按事务组并发回放，决定了回放能力上限。
• 查无主键或无唯一键表：这类表在行复制下需要全表扫描定位行，是延迟的典型放大器。

2. 主从复制中断

• 数据冲突类：主键冲突（错误码1062）、找不到待更新记录（1032），通常源于从库被直接写入或发生过主从切换。
• 日志缺失类：主库 binlog 被清理、relay log 损坏或位点丢失（1236），GTID 模式下则表现为事务缺失。
• 权限与配置类：复制账号权限变更、server_id 冲突、网络闪断导致的连接失败。

处理原则是：先判断能否跳过或补数，再判断是否需要重建复制。任何跳过操作前，都应先确认数据差异范围，避免误差持续扩散。

3. 主从数据不一致

• 定期做行数、校验和比对，可借助 checksum 类工具抽样核对。
• 从库设置只读，避免业务或运维误写入。
• 切换前做一致性校验，不要默认“延迟为零”等于“数据一致”。

三、慢查询排查

排查步骤

1. 界定范围：是整体变慢还是个别接口变慢，结合监控看连接数、QPS、磁盘IO与锁等待是否同步异常。
2. 抓取样本：开启慢查询日志，合理设置 long_query_time，并决定是否记录未走索引的语句。
3. 聚合排序：用 mysqldumpslow 或 pt-query-digest 按总耗时、执行次数、平均耗时排序，优先处理“高频+高耗时”的SQL。
4. 看执行计划：使用 EXPLAIN 或 EXPLAIN ANALYZE，重点看访问类型、命中索引、预估行数与 Extra 中的 Using filesort、Using temporary。
5. 验证索引：检查是否存在隐式类型转换、索引列上使用函数、前导模糊匹配、OR 条件导致索引失效等情况。
6. 检查统计信息与表状态：统计信息过期、表碎片过多，都可能让优化器选错执行计划。
7. 回归验证：修改后在接近生产的数据量下复测，并纳入SQL上线审核流程。

常见成因清单

• 缺少合适索引，或联合索引顺序与查询条件不匹配。
• 一次性返回大量结果，未做分页或字段裁剪。
• 深分页（大偏移量）导致扫描成本线性上升。
• 复杂关联查询、子查询被反复执行。
• 业务高峰期并发突增，单条SQL虽快但总量压垮实例。

四、死锁排查

第一步：拿到现场

• 执行 SHOW ENGINE INNODB STATUS，查看 LATEST DETECTED DEADLOCK 段落，其中包含两个事务的SQL、持有锁与等待锁信息。
• MySQL 8.0 可查询 performance_schema 中的锁等待相关表，观察当前阻塞链路。
• 开启 innodb_print_all_deadlocks，把死锁信息完整写入错误日志，便于事后统计。

第二步：还原加锁顺序

死锁的本质是两个及以上事务以相反顺序获取锁。排查时要还原：每个事务先锁了哪些行、锁类型是什么（记录锁、间隙锁、临键锁）、为何会产生间隙锁。

常见成因

• 多表或多行更新时，业务代码未统一访问顺序。
• 唯一索引冲突场景下，插入与删除并发执行。
• 在可重复读隔离级别下，范围条件更新产生间隙锁。
• 更新条件未走索引，导致扫描并锁定大量行。
• 长事务持有锁时间过长，放大了冲突概率。

降低发生概率

• 统一数据访问顺序，按主键排序后批量更新。
• 缩短事务，把非数据库操作移出事务范围。
• 为更新条件建立合适索引，避免大范围锁定。
• 在应用层对死锁报错做有限次数的重试，并记录日志。
• 评估是否可降低隔离级别，但必须先确认业务对一致性的要求。

五、高频故障速查清单

• 主从：线程状态、错误码、位点差异、大事务、无主键表、并行复制配置。
• 慢查询：慢日志聚合、执行计划、索引有效性、统计信息、并发量。
• 死锁：死锁日志、锁等待视图、加锁顺序、事务粒度、索引覆盖情况。
• 通用：连接数、CPU、内存、磁盘IO与空间、网络抖动、备份任务影响。

六、通用排查方法论

1. 先止损：必要时限流、终止异常会话、临时切流，避免故障面扩大。
2. 再定位：从监控时间线找到拐点，与变更记录、发布记录对照。
3. 后验证：修复动作要有可量化的验证指标，而非“看起来恢复了”。
4. 做复盘：把本次问题沉淀为告警规则、巡检项或SQL规范。

七、结语

主从、慢查询与死锁，考验的其实不是某个命令的熟练度，而是监控是否完整、变更是否可控、SQL是否规范。对于承载核心业务的数据库，建议从实例规格、存储类型、备份策略与高可用架构上提前留出余量，把可观测性做在故障之前，才能让排查从“救火”变成“例行检查”。