看起来在"执行"的时间里，可能藏着真正的"等待"

完成一项任务所花的时间可以分成两种性质完全不同的部分：执行 时间和等待时间。这个区分之所以重要，是因为诊断这两类耗时需要 完全不同的思路——优化执行时间的方法是拆解出各个子任务、去掉 不必要的子任务或提升它们的效率；优化等待时间要复杂得多，因为 等待往往是被其他系统间接拖累的（比如多个任务在争用磁盘或CPU 资源），不是这个任务本身”做得慢”。麻烦的是，这两类耗时经常被 混在一起、表面上分不清：一个基于执行时间做的性能剖析，可能 显示某个查询”执行”花了很长时间，但如果深入研究会发现，这段 “执行时间”里绝大部分其实是在等磁盘I/O完成，任务本身在CPU上 真正干活的时间很短。也就是说，性能剖析报告上写的”执行时间” 只是一个粗粒度的外部观测结果，并不能保证这段时间里任务真的 在”执行”，如果不进一步深挖，很容易把”等待”误判成”执行慢”， 从而在错误的方向上去做优化（比如去优化查询逻辑本身，而真正 该解决的其实是I/O瓶颈）。这也解释了为什么诊断时通常需要基于 执行时间和基于等待两种分析方式都试一遍：如果任务主要在消耗 资源、几乎不等待，基于等待的分析没什么用；如果任务大部分时间 在原地等待、几乎不消耗资源，去分析”执行时间”也不会有什么 发现——只有先弄清楚耗时的性质究竟是哪一种，才能选对诊断工具， 不会在错误的假设上白费功夫。