先从查询路径开始
先找出时间真正花在哪里。看重负载查询路径、索引、连接模式、报表压力，以及应用代码为了弥补数据访问糟糕而做补偿的地方。
- 识别最慢且成本最高的重复查询路径
- 把应用低效和真正的数据库瓶颈区分开
- 审查索引、基数假设和明显的结构错配
洞见
重写之前先做数据库调优：该先修什么
当数据库成了显眼瓶颈时，团队往往会直接跳到迁移或重写。有时这确实合理，但很多时候最先需要的是数据库调优和结构审视。第一个问题应该是：性能究竟在哪丢失，什么能被安全改进。
最适合
- 慢查询已经影响真实用户行为的应用
- 在不破坏交付稳定性的前提下仍需提升性能的团队
- 数据模型每个版本都变得更混乱的系统
找出调优掩盖不了的结构问题
有些性能问题其实是模式问题。负载过重的表、不一致的键、历史性权宜做法以及不清晰的数据所有权，会制造出仅靠调查询无法解决的阻力。
- 找出承担了过多职责的表或关系
- 识别让报表或集成路径变复杂的模式选择
- 把战术性调优与结构性重设计需求区分开
为什么先调优往往是更安全的一步
有节制地先做一轮调优，可以改善当前性能、看清哪些模式债务真正重要，也能为以后迁移或重设计打下更干净的基础。
- 先拿到立刻可见的收益，而不是假装整个系统都必须被替换
- 为后续任何重设计或迁移决策提供更好的证据
- 在澄清核心问题的同时减少对交付的干扰