数据库变慢，八成是几条慢 SQL 拖累的。治理慢查询是投入产出比最高的数据库优化。
「MySQL 慢查询治理：从 explain 到索引重构」是数据团队绕不开的现实课题。MySQL 与 RDS 性能治理不是一次性项目，而是伴随业务增长持续演进的过程，需要把性能、安全与成本放在同一个框架里长期权衡。
开启慢查询日志
设置 long_query_time，用慢查询日志或 performance_schema 找出耗时 Top N 的 SQL，先解决最痛的几条。
用 explain 看执行计划
重点关注：type（避免 ALL 全表扫描）、key（实际用到的索引）、rows（预估扫描行数）、Extra（出现 Using filesort / Using temporary 是危险信号）。
索引设计原则
- 遵循最左前缀建立联合索引。
- 用覆盖索引避免回表。
- 区分度高的列放在联合索引前面。
避开索引失效
在索引列上做函数或运算、隐式类型转换、前导模糊 like '%x'、用 OR 连接非索引列等，都会让索引失效。
EXPLAIN SELECT id, status FROM orders
WHERE user_id = 1001 AND status = 'PAID'
ORDER BY created_at DESC LIMIT 20;
-- 目标：type=ref/range，key 命中 (user_id,status,created_at)，无 filesort改写与分页
深分页用游标或延迟关联；大事务拆小；数据量大到瓶颈时再考虑读写分离或分库分表。
小结：先定位、再看执行计划、后建索引，避免拍脑袋乱加索引反而拖累写入。
把慢查询治理变成常态机制
专项排查能解决当下最痛的几条 SQL，但业务在长、数据在涨，新的慢查询会不断出现。真正的收益来自把它做成常态机制，让问题在造成故障之前就被发现和消化。
- 上线前审核：把执行计划检查纳入发布流程，新增或修改的 SQL 要说明预期命中的索引与扫描量级，避免全表扫描直接上生产。
- 周期报表：按周输出慢查询排行与趋势，标出相比上周的新增项，让治理有明确的责任人和完成时限，而不是停在一份没人跟进的清单里。
- 结构变更评估：大表的索引增删与在线 DDL 要评估锁范围与耗时，选择业务低峰执行，并提前准备回退方案与验证脚本。
- 索引卫生：定期清理重复索引与长期未被使用的索引，它们会拖慢写入、占用存储，却很少带来查询收益。
数据量本身也是变量：单表行数持续增长时，同样的 SQL 会从毫秒级退化到秒级，而代码一行都没改。为关键表设定行数与容量水位的预警线，把归档与拆分纳入长期规划，比等到用户投诉再优化要从容得多。
需要外部支持时，可以找安徽卓牛
针对MySQL 与 RDS 性能治理，安徽卓牛可以结合阿里云数据库与存储产品体系，协助客户完成选型评估、迁移方案设计与上线后的持续优化，全程由具备阿里云认证资质的技术团队跟进。
无论是一次专项排查，还是长期的运维托管，都可以通过官网在线客服与安徽卓牛取得联系，说明现状与诉求即可。
从排查到预防：把经验沉淀为机制
- 慢的问题先定位再动手：用执行计划与监控数据说话，避免凭感觉改索引、改参数。
- 变更留痕：每一次调整记录原因与预期，便于复盘与回退。
- 容量预警前置：为存储、连接数、内存等关键水位设置提前量告警。
- 演练常态化：把恢复演练、切换演练纳入日常，而不是出事才第一次做。
机制化的沉淀，能让MySQL 与 RDS 性能治理从「个人经验」变成「团队能力」。