要拿到这个"犯罪记录"简单得很，直接在SELECT语句前面加上这个关键字就行，或者更直观地用来份详细报告。执行后，返回的不是查询结果，而是一张表，里面全是破案的关键线索。咱们得一个个字段地琢磨。
第一，看type列，这是判断查询效率的重中之重。 它告诉你MySQL决定怎么去找数据。从好到坏大概有这么几种常见情况： > > > > > > 。和是性能最好的，通常根据主键或唯一索引查询时出现，速度快到飞起。在联表查询时用得比较多，比如用主键或唯一索引进行关联。就稍微普通点，用的是普通索引。如果看到，说明用了索引范围扫描，比如BETWEEN、IN、> 这些操作，也还算可以。最要警惕的就是，这代表全表扫描，数据量一大性能肯定崩。一旦发现是，十有八九是你的索引没建对或者没用上。
第二，key和possible_keys列也得重点关照。表示查询会用到的索引，是MySQL觉得可选的几个。而是它选择的那个索引。有时候你会看到列了一堆，但却是，这说明MySQL最终决定不用任何索引，全表扫了！这通常发生在数据量不大，或者它估算用索引反而更慢的情况下（比如统计信息不准）。另一种情况是，用的索引根本不在里，这可能是覆盖索引（Covering Index）发挥了作用，索引本身就把要查的数据包圆了，都不用回表。
第三，留意rows和filtered字段。是个预估值，MySQL觉得为了找到结果，需要扫描多少行数据。这个数越小越好。表示存储引擎返回的数据，在Server层再用其他查询条件过滤后，剩余数据所占的百分比。理想情况下是100%，表示索引已经完美过滤了。如果这个值很低，比如只有10%，说明大部分数据在索引层面没拦住，被送到Server层再做筛选，效率自然高不了。在联表查询时，这两个字段结合起来，能帮你预估出整个查询的大致数据量。
第四，警惕几个"性能杀手"标志。 一个是，这说明MySQL正在费劲地自己排序，没用到索引的有序性。看到这个，想想能不能给的字段加个合适的索引。另一个是，这表示创建了临时表，常见于GROUP BY、DISTINCT或者复杂的UNION操作。临时表一般在内存里搞，如果太大就会写到磁盘上，那速度就慢得惊人了。还有，这不一定全是坏事，它只表示在存储引擎返回数据后，Server层还做了过滤。但如果配合是，那就惨了，意味着全表扫描出来的每条数据都要再做一次条件判断。
光看懂这些字段还不够，关键得会用。我举个实战里的常见坑。假设你有个用户表，在和上分别建了单列索引。然后你写了个查询：。一执行，发现有和，但可能用了，是，然后里出现了。为啥不用呢？因为MySQL的优化器认为，根据这个条件筛选出的数据量更少，成本更低。但实际效果可能并不好。这时候，你就该考虑为创建一个联合索引，这样查询就能直接定位到数据，效率飙升。
总之，不是摆设，是每个后端开发者和DBA必须掌握的硬核技能。调优SQL就像老中医看病，得望闻问切。就是那个帮你号脉的工具，让你能精准地找到病灶（缺失的索引、低效的连接顺序、不必要的临时表等），然后对症下药。下次再遇到慢查询，别犹豫，先一下，让它原形毕露！