1. 问题现象与初步排查
那天下午，监控系统突然报警，显示某个核心接口响应时间突破1秒。顺着调用链追查，最终定位到一条看似简单的SQL语句：
sql复制SELECT * FROM orders WHERE user_id = 12345 AND status = 'pending' LIMIT 10;
在测试环境执行只要3ms的生产环境却耗时超过1000ms。作为有五年数据库调优经验的DBA，我立刻意识到这背后必有蹊跷。首先检查了基础指标：
- 服务器负载：CPU 20%，内存剩余40%
- 磁盘IO：await 2ms，util 15%
- 网络延迟：<1ms
- 数据库连接池：活跃连接数15/100
基础环境看起来完全正常，于是转向数据库内部排查：
sql复制EXPLAIN SELECT * FROM orders WHERE user_id = 12345 AND status = 'pending' LIMIT 10;
执行计划显示这条语句竟然进行了全表扫描（type=ALL），而orders表已有2000万行数据。
2. 索引失效深度分析
2.1 现有索引结构检查
检查表结构后发现，orders表上有以下索引：
- 主键索引：id
- 唯一索引：order_no
- 普通索引：idx_user_id (user_id)
- 联合索引：idx_user_status (user_id, status)
理论上，无论是单独使用idx_user_id还是联合索引idx_user_status，都应该能高效定位数据。但现实是优化器选择了全表扫描。
2.2 数据类型隐式转换陷阱
仔细比对字段类型后发现：
- user_id在表中定义为varchar(32)
- 而查询条件中使用的是整数12345
这导致MySQL进行了隐式类型转换，索引失效。验证方法：
sql复制-- 强制使用索引的写法
SELECT * FROM orders FORCE INDEX(idx_user_id)
WHERE user_id = '12345' AND status = 'pending' LIMIT 10;
这次执行时间降到了5ms，确认了类型转换问题。
2.3 联合索引最左前缀原则
即使修正了类型问题，另一个隐患是status字段的过滤性：
- user_id=12345的记录有5000条
- 其中status='pending'的只有3条
但联合索引idx_user_status的列顺序是(user_id, status)，当查询条件同时包含这两个字段时，索引可以充分发挥作用。单独使用status条件则无效。
3. 系统性的解决方案
3.1 短期应急措施
立即修改应用代码，确保查询条件类型匹配：
java复制// 修改前
String sql = "SELECT * FROM orders WHERE user_id = ? AND status = ?";
preparedStatement.setInt(1, userId); // 错误
// 修改后
preparedStatement.setString(1, String.valueOf(userId)); // 正确
3.2 索引优化方案
调整索引策略：
- 将user_id字段类型改为BIGINT（需要评估影响）
- 新增status单列索引（针对status单独查询场景）
- 调整联合索引顺序为(status, user_id)（根据业务场景决定）
sql复制ALTER TABLE orders
ADD INDEX idx_status (status),
MODIFY COLUMN user_id BIGINT;
3.3 查询重写建议
对于需要同时使用两个字段的查询，建议：
sql复制-- 更好的写法（利用索引下推）
SELECT * FROM orders
WHERE user_id = '12345'
AND status = 'pending'
ORDER BY create_time DESC
LIMIT 10;
4. 深度优化实践
4.1 执行计划解读技巧
使用EXPLAIN FORMAT=JSON获取更详细的信息：
sql复制EXPLAIN FORMAT=JSON
SELECT * FROM orders WHERE user_id = '12345'\G
重点关注：
- estimated_execution_time
- prefix_cost
- used_columns
- filtered
4.2 索引跳跃扫描优化
MySQL 8.0+支持Index Skip Scan：
sql复制-- 即使没有status前置的索引也能利用
SELECT /*+ INDEX_SS(orders idx_user_status) */ *
FROM orders WHERE status = 'pending';
4.3 直方图统计信息
收集更精确的统计信息：
sql复制ANALYZE TABLE orders UPDATE HISTOGRAM ON user_id, status;
5. 防患于未然的规范
5.1 开发规范建议
- 所有SQL必须通过EXPLAIN验证执行计划
- 字段类型定义必须与业务逻辑严格匹配
- WHERE条件中的字段顺序应与联合索引顺序一致
- 禁止在索引列上使用函数或运算
5.2 监控体系搭建
配置监控项：
- 慢查询日志（long_query_time=200ms）
- 未使用索引查询日志（log_queries_not_using_indexes=ON）
- 每分钟索引使用率统计
5.3 性能测试策略
在CI/CD流程中加入：
- 执行计划断言测试
- 100万数据量下的查询性能基准测试
- 并发压力测试（使用sysbench）
6. 高级技巧与案例分析
6.1 分区表优化
对于超大规模订单表，可以考虑按范围分区：
sql复制CREATE TABLE orders (
id BIGINT PRIMARY KEY,
user_id VARCHAR(32),
status VARCHAR(20),
create_time DATETIME
) PARTITION BY RANGE (TO_DAYS(create_time)) (
PARTITION p202301 VALUES LESS THAN (TO_DAYS('2023-02-01')),
PARTITION p202302 VALUES LESS THAN (TO_DAYS('2023-03-01'))
);
6.2 读写分离架构
配置MySQL Group Replication：
- 写节点处理所有INSERT/UPDATE/DELETE
- 读节点处理SELECT查询
- 使用ProxySQL实现自动路由
6.3 缓存策略优化
采用多级缓存方案：
- 热点数据使用Redis缓存
- 查询结果使用本地缓存（Caffeine）
- 字段级缓存（如用户名的反查）
关键提示：任何缓存策略都必须有完善的过期和淘汰机制，避免脏读
7. 真实生产案例复盘
去年双十一大促期间，我们遇到过一个更隐蔽的案例：
- 查询条件：WHERE create_time > '2022-11-11 00:00:00'
- 索引：idx_create_time (create_time)
- 问题原因：MySQL默认将字符串时间转换为当前时区
- 解决方案：明确指定时区或使用UNIX_TIMESTAMP
sql复制-- 正确写法
WHERE create_time > CONVERT_TZ('2022-11-11 00:00:00','+00:00','+08:00')
8. 工具链推荐
我的日常调优工具箱：
- 诊断工具：
- pt-query-digest（慢查询分析）
- mysqlsla（日志分析）
- 监控工具：
- Prometheus + Grafana
- Percona PMM
- 压测工具：
- sysbench
- tpcc-mysql
9. 未来优化方向
最近在测试MySQL 8.0的新特性：
- 不可见索引（INVISIBLE INDEX）
- 函数索引（FUNCTIONAL INDEX）
- 资源组（Resource Groups）
sql复制-- 函数索引示例
CREATE INDEX idx_name_lower ON users ((LOWER(name)));
10. 血泪教训总结
五年DBA生涯中最贵的几条经验：
- 永远不要相信"这个字段不会超过XX长度"的断言
- 所有JOIN查询必须验证执行计划
- 上线前一定要用生产级数据量测试
- ORM生成的SQL要特别警惕
- 监控系统比调优技巧更重要
最后分享一个检查清单，每次SQL优化前我都会过一遍：
- 字段类型是否匹配？
- 是否有合适的索引？
- 执行计划是否符合预期？
- 数据分布是否均匀？
- 事务隔离级别是否合适？
- 锁等待是否可能发生？