性能的正式定义是响应时间，优化"CPU利用率"是个陷阱

“性能”这个词几乎人人都在用，但不同人心里想的可能是完全不同 的东西——每秒查询数、CPU利用率、可扩展性……这些理解各有道理， 但用来指导优化工作时会互相打架。真正该采用的定义很单纯：性能 就是完成某个任务所需要的时间，对数据库而言就是查询的响应 时间。这个定义之所以重要，是因为它排除了一类看起来合理、实则 会把人带偏的替代指标——把CPU利用率当作优化目标就是一个典型 陷阱：如果目标是”降低CPU利用率”，那减少资源使用就成了正确 方向，但资源本来就是拿来消耗、拿来干活的，有时候多消耗资源 反而能让查询跑得更快。书里给出一个具体反例：把老版本InnoDB 升级到新版本后，CPU利用率经常会明显上升，这并不代表性能变差 了，恰恰相反，往往说明新版本把资源利用得更充分了——真正该看 的是查询的响应时间有没有变好，而不是CPU利用率这个”现象”（虽然 版本升级偶尔也会引入bug，比如索引失效导致CPU利用率异常飙升， 但这也只能靠响应时间是否变差来判断，不能靠CPU利用率本身下 结论）。同样，把”每秒查询量”（吞吐量）当作优化目标也是同一类 误区的变体——吞吐量提升其实是响应时间优化的副产品（吞吐量正好 是响应时间的倒数），直接以吞吐量为目标容易只顾表面数字、忽略 真正决定用户体验的单次查询耗时。判断一个优化方向是不是走对了， 永远要回到”完成这个任务花了多长时间”这个最朴素的问题上。