5.3 性能调优实践
5.3 性能调优实践
本节摘要：前两节给了方法论，这一节给操作面：Profile 的常态化采集怎么做、会话参数的默认值该怎么校准、资源隔离如何把大任务关进笼子。所有建议都附带"什么时候不要动"的反向说明——调参的成熟标志不是记住了多少默认值，而是知道每一个旋钮的副作用。
学习目标
阅读完本节，你应当能够：
- 为报表集群搭建 Profile 采样与归档的最小流程；
- 解释单查询内存限额、超时、并行度三组参数的联动关系；
- 用资源组把夜间批任务与白天看板隔离开；
- 按顺序执行一套标准的慢查询处置流程（SOP）。
一、让 Profile 成为常备体检而不是临场急救
按需开启的 Profile 只能在"已经吵起来了"之后取证。更好的节奏是常态低比例采样：
-- 全局开启百分之一的采样 报表高峰期单独调高一档 SET GLOBAL enable_profile = true; SET GLOBAL profile_collect_threshold = 毫秒阈值; -- 只收慢样本 减少噪音
配合两条纪律形成闭环：每份 Profile 落盘归档时记录语句指纹、耗时与五个关键算子行数；每周出一份"TopN 慢语句榜"，逐条标注已优化/待办。坚持两个月的团队普遍会发现，慢查询总数的三分之一来自同五条语句的变体——治理目标是集中而明确的。
二、三组核心参数的联动账本
内存类：单实例执行内存上限决定了单个 Fragment Instance 能摊到多少空间。哈希表构建阶段（大型 Join 或高基数聚合）是首个撞线者；报错文案通常明示 pool 与限额数值。调整次序应当是先降并行实例数（让单实例分到的天然变多）、再考虑上调限额，因为后者直接改变整机 OOM 余量。
时限类：查询超时要覆盖最长的合法业务场景而不迁取病态长尾；展示型看板设十秒量级就够，等不到就是设计问题。导入相关的独立时限另算，二者别共用直觉。
并发类：单 FE 可承受的并发与排队深度、BE 单机同时跑的 Fragment 实例数共同决定集群承载力。大促前的压测应该回答一个问题：多少并发时 P99 开始拐头？那个数字乘零点六就是你们的容量红线。
-- 会话级临时收缩（排查用 完成即恢复） SET parallel_fragment_exec_instance_num = 2; SET exec_mem_limit = 4294967296; SET query_timeout = 15;
⚠️ 常见坑：全局把内存上限调到机器物理内存的九成去"用满硬件"。必须给 BE 进程内的导入池、压缩池、缓存池留出共享余量，否则一个晚间批任务就能引爆整台机器。
三、资源隔离：把乱源关进笼子
混合负载集群的第一杀手是大扫表任务挤占交互流量。资源组机制给出操作系统级的答案：
CREATE RESOURCE GROUP rg_batch PROPERTIES ( "cpu_core_percent" = "30", -- 夜批最多拿三成核 "memory_limit" = "25%", "max_concurrency" = "8" ); -- 把定时作业绑定到该组 归属可按用户名或数据库规则自动匹配 SET PROPERTY FOR 'etl_user' 'default_resource_group' = 'rg_batch';
落地后观察两项对照指标：日间看板 P99 是否回稳、夜批总时长是否在预算内浮动。若两者冲突加剧，说明的是容量不足被隔离掩盖了，该加机器加机器，别继续压榨隔离粒度。
四、一张标准处置 SOP
接到慢查询投诉时按序走完七步，多数团队在此流程下能把定位时间从半天压到半小时：
- 取指纹：用户贴出语句与大致发生时刻；
- 查档案：TopN 榜里有没有它，有则直接看历史结论；
- 开 Profile：复跑一次带采样的执行（低峰期或临时开全量）；
- 分层归因：计划占比高走简化路线，扫描占比高走进裁剪路线，交换占比高走 Join 策略路线；
- 对照第 5.2 免费午餐清单逐项过一遍；
- 尝试一次最小干预并留存前后 Profile 对比数据；
- 回写案例库：语句形态、根因分类、修法一句话。
这套 SOP 的隐藏收益是归因词条的复利：季度复盘时按根因分类统计，你会看到"谓词未下推""统计过期""分桶倾斜"三类常年霸榜——它们对应的恰恰是第 3 章建模期可以预防的部分。前端治病的尽头在后端养身。
五、观测之外的软技能
最后说点数字之外的。调优沟通的最大损耗在于口径不一致："慢"到底是几秒？哪天几点？偶发还是必现？要求投诉方提供三件套（语句文本、发生时间点、期望时长）再动手，能过滤掉一半的伪工单。另一条经验：当着需求方的面跑一次 EXPLAIN 并讲解裁剪命中情况，比任何文档都更能建立"这里不是黑盒"的信任——性能问题的治理一半靠技术，一半靠预期管理。
六、两层缓存的水位表
参数之外，还有两块"隐性内存"值得单独记账。一块是数据页缓存：BE 把最近读过的数据块留在内存里，重复扫描同一批热数据时直接命中。它的推荐水位是节点内存的三到五成，但要看业务形态——看板类负载的扫描高度重复，缓存命中率高，值得给足；即席查询占比高的集群扫描离散，大缓存只是占着内存看风景。观测方法是对照缓存命中率与内存占用曲线，命中率长期低于两成就该缩容，把内存让给执行池。
另一块是查询结果类缓存（按版本与形态差异包括分区级结果缓存等）。它适合"结果集小、命中频繁、底表更新不频繁"的看板语句。开它之前先回答两个问题：同一条语句每天被多少人执行？底表数据的更新节奏是分钟级还是小时级？前者低于十次、后者分钟级刷新的场景，缓存收益常常盖不过失效开销，不如不开。
两层缓存共同的纪律是变更后主动清账：批量导入完成、表结构变更、版本升级之后，缓存内容与新数据之间会出现短暂的不一致窗口。把"导入完成后清缓存"写进调度编排的固定步骤，而不是依赖过期机制慢慢自愈——报表数字对不上账的投诉，一半源自这里。
常见疑问
问：参数调优和 SQL 改写的优先级到底怎么排？ 永远 SQL 在前。本册反复出现的证据链是：语句形态错误的收益损失以秒计，参数错配的损失以毫秒到百毫秒计。先用 5.2 的免费午餐清单把语句改干净，再用 5.3 的参数把资源用稳——顺序颠倒的团队常在错误的语句上精心调参，收效自然可疑。
问：压测该测到什么程度才算数？ 三条验收线：目标并发下 P99 不越过业务承诺；持续时长覆盖至少一个完整业务周期（含导入高峰的叠加段）；故障注入一项（单节点重启）后恢复时间有实测值。只测"跑得多快"不测"坏了多久"的压测报告，在生产事故面前一文不值。
本节要点回顾
- Profile 常态化采样加周榜：让慢查询治理从救火变成巡逻。
- 三组参数先动并发再动限额：每一格内存都要有人负责。
- 资源组解决的是公平：若容量本身不够，隔离只会延长痛苦。
- 七步 SOP 写成制度：定位时间可以压缩到分钟级。
- 预期管理占半壁江山：口径一致的投诉才值得立刻出门。
武器备齐了。下一节进入实战回合：一条十二秒的真实报表 SQL 的完整手术记录。