章节摘要:慢的原因千奇百怪,快的路径大同小异。本章先建立一套通用的分析框架——看懂执行流程、读懂执行计划、善用 Profile 数据,然后逐个检视优化器提供的免费加速手段,最后落到参数与资源层的调优手法。压轴的 5.4 是一次完整的降耗演练:一条十二秒的报表 SQL 如何被系统地压到亚秒。
完成本章后,你应当能够:
调优的第一原则是"分层归因":延迟要么花在等待计划(FE 侧),要么花在搬运数据(网络 Shuffle),要么花在计算本身(BE 算子)。三层各有一套抓手:
金句:没有 Profile 的调优是玄学,有归因的改动才配叫优化。
三层抓手的动手术次序也值得预先立好规矩:永远从扫描层开始,因为扫描是 IO 密集的第一性成本,裁剪一个分区胜过调十个参数;网络层次之,Join 分发方式的修正动一次就是量级变化;FE 层最后碰,它的手段收益稳定但天花板低。颠倒次序的典型症状是"参数调了一轮、语句纹丝没动"——多数时候不是参数无效,而是瓶颈根本不在参数所在的那一层。5.4 的实录会把这套次序演示成完整的手术记录。
先修认知(5.1 执行流程是一切分析的坐标系),再学武器(5.2 的改写与策略是免费的午餐),后练手艺(5.3 的参数与观测是精确制导),最后合成一战(5.4)。缺了第一步,后面全部沦为抄参数清单:
坐标系 → 武器库 → 制导术 → 实战演练 5.1 5.2 5.3 5.4
需要第 2 章架构词汇(Fragment、Runtime Filter)和第 3 章表设计常识。学完本章顺手读 7.2 监控指标能把单点技巧升格为容量视角;持续为 Join 头疼的团队还应回看 3.3 的 Colocation 规划。
五节的深浅并不平均:5.1 与 5.2 是理解型的,读慢一点,把六段流程与五种 Join 策略内化成直觉;5.3 是操作型的,按需查阅即可;5.4 建议在真机前对照着读——把那条十二秒的语句在自己的测试集上复现一遍,收益比读三遍都大。判据始终只有一个:下次接到慢查询时,你的第一反应是不是"先看 Profile 再说话"。
另有一条团队层面的建议:把 5.2 的免费午餐清单与 5.3 的七步 SOP 合并打印成一页调优速查卡,评审新 SQL 时过清单、接工单时走 SOP。个人技艺转化为团队制度的那一步,往往就是慢查询总量开始下降的那一季。
本章也刻意保留了几处"反直觉"的记录:并行度不是越高越好、资源隔离解决不了容量不足、参数调优排在语句改写之后。这些反直觉条目是从真实工单里筛出来的高频误区,读到你深以为然的观点被反驳时,慢一点翻页——那正是本章最想跟你讨论的地方。
带着预设来读的人最容易在这章走弯路:把过去在其他数据库上的调优经验原样搬来,常常适得其反——MPP 的代价结构与单机引擎不同,同一招在不同架构下收益方向都可能翻转。把旧经验当假设、把本章的推演当验证,是进入演练场前最后一次装备检查。