首先必须得提的就是EXPLAIN命令，这玩意儿可以说是分析SQL性能的入门必备。不过很多人可能就只看个type和key就完事了，其实里面的细节多了去了。比如extra字段里如果出现"Using filesort"或者"Using temporary"，那就要警惕了，这很可能就是性能瓶颈所在。我习惯用EXPLAIN FORMAT=JSON来获取更详细的信息，特别是当查询涉及子查询或者UNION操作时，JSON格式的输出能更清晰地展示执行计划树。
除了基本的EXPLAIN，还有个高级玩法是EXPLAIN ANALYZE，这是MySQL 8.0才开始支持的功能。它会实际执行查询并统计各阶段的耗时，比传统的EXPLAIN更直观。比如可以看到在某个索引扫描阶段实际花了多少时间，在排序阶段又花了多少时间。我上次就是用这个功能发现了一个看似简单的查询居然在临时表创建上花了80%的时间，后来通过调整索引就解决了问题。
慢查询日志是另一个不可或缺的工具。建议把long_query_time设置为0.5秒或者更低，这样才能捕捉到那些不太明显但频繁执行的慢查询。分析慢查询日志的时候，最好配合pt-query-digest这个工具，它能自动对慢查询进行归类统计，快速找出最耗时的查询类型。记得有次我们系统突然变慢，就是用这个工具快速定位到了一个新上线的功能里循环执行了大量相似查询。
performance_schema是MySQL自带的神器，但很多人可能因为配置复杂而望而却步。其实只要重点开启几个监控项就很有用了。比如监控等待事件（wait events），可以清楚地看到SQL在执行过程中在哪些环节等待最久；监控锁等待（lock waits），能发现那些隐形的阻塞问题。我通常会重点关注data_lock_waits和metadata_locks这两个表，特别是在高并发场景下。
对于存储过程或者复杂事务的调试，建议使用MySQL的查询分析器（Query Profiler）。通过set profiling=1开启后，执行一系列SQL，然后show profiles就能看到每条语句的详细耗时。这个比慢查询日志更实时，适合在开发阶段进行针对性优化。不过要注意的是，这个功能在MySQL 8.0中已经被标记为过时，后续可能会被移除。
在命令行环境下，mysqladmin的processlist命令可以实时查看当前连接和执行的查询状态，特别适合排查突发性的性能问题。如果看到某个查询长时间处于"Sending data"状态，那很可能就是在进行全表扫描了。另外，show engine innodb status这个命令也很实用，里面包含了InnoDB引擎的详细运行状态，包括死锁信息、缓冲池使用情况等。
工具方面，除了MySQL自带的这些，第三方工具也很给力。比如Percona Toolkit里的pt-query-digest和pt-index-usage，前者刚才提到过，后者可以分析索引使用情况，建议哪些索引可以删除。HeidiSQL和MySQL Workbench这些图形化工具也内置了不少性能分析功能，特别是可视化的执行计划展示，对新手很友好。
最后想说，调试MySQL性能问题没有银弹，关键是要形成系统化的排查思路。我一般的做法是：先通过慢查询日志或processlist定位问题SQL，然后用EXPLAIN分析执行计划，结合performance_schema深入分析等待事件，必要时使用profiler进行细粒度分析。记住，索引不是越多越好，有时候适当的查询重构比加索引更有效。
调试MySQL确实是个经验活，很多技巧都是在实际踩坑中积累的。建议大家多动手实践，把理论知识和实际场景结合起来，慢慢就能形成自己的调试方法论了。