1. 课程导论：慢查询诊断的重要性、Message Queue 场景下的挑战、连接池配置的核心作用
1.1 为什么慢查询诊断是 DBA 的必修课
在 MySQL 生产环境中，慢查询（Slow Query）是性能劣化的首要信号。一条未命中索引的 SQL 可能将 CPU 打满、锁等待堆积、连接池耗尽，最终导致服务雪崩。慢查询诊断的核心价值在于：
- 快速定位瓶颈：从海量 SQL 中识别出消耗资源最多的查询。
- 量化优化效果：通过执行时间、扫描行数、返回行数等指标对比优化前后差异。
- 预防故障：在慢查询演变为生产事故前提前介入。
关键指标速查表：慢查询日志中重点关注
Query_time（执行时间）、Rows_examined（扫描行数）、Rows_sent（返回行数）。当 Rows_examined 远大于 Rows_sent 时，通常意味着索引缺失或查询设计不合理。
1.2 Message Queue 场景下的特殊挑战
消息队列（Message Queue, MQ）场景是慢查询的“重灾区”。无论是 RocketMQ、Kafka 还是 RabbitMQ，其业务逻辑通常涉及大量状态变更、消息轨迹查询、死信重试等操作，对数据库的访问模式与普通 OLTP 系统有显著差异：
| 挑战维度 | 具体表现 | 对慢查询的影响 |
|---|---|---|
| 高并发写入 | 消息生产端批量写入消息表、消费进度表 | 写锁竞争、binlog 堆积、磁盘 IO 打满 |
| 范围查询频繁 | 按时间范围拉取未消费消息、死信消息 | 全表扫描或索引选择错误，导致 CPU 飙升 |
| 数据倾斜 | 部分 Queue/Partition 消息量远大于其他 | 热点页竞争，单行锁等待加剧 |
| 消费状态回查 | 分布式事务场景下频繁查询消息状态表 | 非聚簇索引回表开销大，响应时间不稳定 |
典型陷阱：很多团队在 MQ 场景下直接使用默认的 B+Tree 索引，忽略了“时间戳 + 消息状态”的联合索引设计。当消息积压时，一条
SELECT * FROM msg WHERE status=0 AND create_time BETWEEN ? AND ? 可能扫描数百万行，直接拖垮数据库。
1.3 连接池配置的核心作用
连接池是应用程序与 MySQL 之间的交通枢纽。错误的连接池参数配置，即使 SQL 本身已经优化到极致，依然会导致严重的性能问题。连接池配置不当的典型表现包括：
- 连接泄漏：未正确归还连接，导致连接池耗尽，新请求排队等待。
- 连接震荡：频繁创建和销毁连接，增加 TCP 握手和 MySQL 认证开销。
- 队列堆积：最大连接数设置过小，请求在连接池队列中长时间等待，RT 飙升。
经验法则：连接池的
maximum-pool-size 并非越大越好。过大的连接数会导致 MySQL 内部线程争抢 CPU 和锁资源，反而降低吞吐。推荐公式：maximum-pool-size = (CPU核心数 × 2) + 有效磁盘数，在此基础上根据实际压测结果微调。
1.4 连接池参数与慢查询的关联
连接池参数直接影响慢查询的可见性和恢复速度：
| 连接池参数 | 错误配置后果 | 与慢查询的关联 |
|---|---|---|
maximum-pool-size |
设置过小 → 请求排队；设置过大 → MySQL 过载 | 排队时间被计入应用 RT，掩盖真实 SQL 执行时间 |
connection-timeout |
超时时间过长 → 请求阻塞堆积 | 慢查询未超时前，连接池无法释放，影响其他正常查询 |
idle-timeout |
空闲连接回收不及时 → 连接池膨胀 | 大量空闲连接占用 MySQL 线程，加剧慢查询时的资源争抢 |
max-lifetime |
连接存活时间过长 → 连接老化 | 老化连接可能被 MySQL 端主动断开，导致慢查询中断重试 |
1.5 本课程的核心学习路径
本课程将围绕以下三条主线展开，帮助学员建立从问题发现 → 根因分析 → 参数调优的完整闭环：
- 慢查询诊断方法论：慢查询日志分析、
EXPLAIN执行计划解读、performance_schema与sys系统表实战。 - Message Queue 场景索引设计：联合索引、覆盖索引、索引下推、分区表在消息表、消费进度表、死信表中的最佳实践。
- 连接池参数配置与调优：HikariCP、Druid、Tomcat JDBC 等主流连接池的核心参数详解，以及针对 MQ 场景的压测调优案例。
课程目标：学完本课程后，你能够独立诊断 MQ 场景下的 MySQL 慢查询问题，并给出索引优化和连接池参数配置的完整解决方案，将数据库响应时间降低 50% 以上。