从开慢日志、读执行计划到加索引，给出可复现的定位与优化流程。下面按“先判断、再动手、最后验证”的顺序展开，每一步都给出可核对的检查点。
涉及 MySQL慢查询、索引优化、慢查询日志 的关键动作都写成了具体命令或配置项，可以照着走，也可以当检查表用。
开启慢日志
slow_query_log=ON，long_query_time 先设 1 秒，用 mysqldumpslow 或 pt-query-digest 汇总 Top 10。
看执行计划
EXPLAIN 关注 type（避免 ALL）、rows、Extra（出现 Using filesort 与 Using temporary 要警惕）。
索引原则
联合索引按等值在前、范围在后；区分度低的列不要单独建索引，反而拖慢写入。
常见坑
函数计算导致索引失效、隐式类型转换（字符串列传数字）、%前缀模糊查询，这三类改写法比加索引有效。
验证效果
优化后对比扫描行数与耗时，同时看写入是否有影响；索引不是越多越好。
速查表
| 环节 | 关键动作 |
|---|---|
| 开启慢日志 | slow_query_log=ON，long_query_time 先设 1 秒，用 mysqldumpslow 或 pt-query-digest 汇总 Top 10 |
| 看执行计划 | EXPLAIN 关注 type（避免 ALL）、rows、Extra（出现 Using filesort 与 Using temporary 要警惕） |
| 索引原则 | 联合索引按等值在前、范围在后；区分度低的列不要单独建索引，反而拖慢写入 |
| 常见坑 | 函数计算导致索引失效、隐式类型转换（字符串列传数字）、%前缀模糊查询，这三类改写法比加索引有效 |
常见问题
Q：按文中写法改完，怎么确认真的生效？
不要只看配置文件，用对应的验证命令或从外部视角复测一次；改完先小流量观察一段，再全量推进，出问题能马上回退。
Q：按文中的步骤做完，还需要注意什么？
把处理过程和最终生效的参数记下来。同类问题再出现时直接对照记录，比重查一遍快得多。
Q：业务规模小，也要按这套标准来吗？
不需要一次到位。先把影响最大的两项做到位，剩余的随着业务增长逐步补齐，比一开始就追求完美更容易落地。
小结
回到这篇的 5 个环节：开启慢日志、看执行计划、索引原则、常见坑、验证效果。把这几个动作写进检查表，下次遇到同类问题按顺序过一遍，比凭经验跳步骤稳。
相关阅读：Nginx的502与504排查路径、防火墙配置：firewalld与iptables怎么选、systemd服务管理：从单元文件到日志。
延伸阅读：Nginx的502与504排查路径、内存占用高排查：从free到smem、磁盘扩容：LVM与文件系统在线扩展。