文章目录每日一句正能量1. 背景与问题为什么同一条SQL普通租户12ms超级租户却跑了15秒2. 环境与数据参数敏感测试不能只拿“典型平均值”2.1 参数至少分三组2.2 为什么“平均参数”没有意义2.3 日期范围也是参数敏感的一部分3. 复现过程强制Generic和Custom直接证明是不是参数敏感3.1 使用 PREPARE 建立可复现实验3.2 force_generic_plan复现“同一计划打天下”3.3 force_custom_plan让参数参与规划3.4 为什么auto有时候仍会选到不理想计划4. 方案实施不要第一反应就全局 force_custom_plan4.1 方案一先修统计信息4.2 方案二观察 estimated vs actual4.3 方案三针对高频接口使用Custom Plan4.4 为什么不建议全局 force_custom_plan4.5 方案四接口分型4.6 方案五按日期范围分流4.7 方案六SQL模板拆分4.8 方案七清理缓存计划只能作为诊断/恢复动作4.9 应用连接池会放大问题4.10 使用 sys_prepared_statements 检查当前会话4.11 不要把“参数嗅探”当成唯一解释4.12 参数敏感还可能来自 Join 顺序5. 结果对比从14.8秒波动到稳定800ms真正有效的是“计划分区”E0强制GenericE1force_custom_planE2统计修复 autoE3接口分型5.1 示例结果5.2 不能只看Execution Time5.3 高频接口要看CPU5.4 P99比平均值更重要5.5 Buffer Read可以解释为什么计划错6. 风险与复盘处理参数敏感最危险的是把“局部救火参数”变成“全局策略”6.1 风险一全局force_custom_plan6.2 风险二全局force_generic_plan6.3 风险三只测普通参数6.4 风险四统计信息过期6.5 风险五接口分型后语义不一致6.6 风险六清计划缓存造成抖动6.7 风险七连接池每个Session状态不同推荐诊断顺序回退方案最终复盘附录 A检查当前计划缓存模式附录 B检查准备语句附录 CCustom/Generic对照附录 D最低验收门禁每日一句正能量走在一起是缘分一起在走是幸福缘来时坦然接受缘去时从不强留。相遇是命运缘同行是选择福。不迎不拒来去从容。有珍重当下的投入也有放开执念的豁达。主题参数分布 / 参数敏感 / 高频接口重点Generic Plan、Custom Plan、plan_cache_mode、Prepared Statement、PBE、统计信息、数据倾斜、执行计划、P95/P99适用场景KingbaseES 上的订单查询、租户检索、客户明细、高频 API、报表接口等“同一条 SQL不同参数表现天差地别”的生产问题。1. 背景与问题为什么同一条SQL普通租户12ms超级租户却跑了15秒生产系统里有一种非常折磨人的慢 SQLSQL文本完全一样 索引完全一样 数据库没有变更但参数不同 性能相差几百倍例如SELECTorder_id,customer_id,amount,created_atFROMapi_orderWHEREtenant_id?ANDstatus?ANDcreated_at?ANDcreated_at?ORDERBYcreated_atDESCLIMIT100;普通租户tenant_id101 最近1天 命中120行 P95≈12ms超级租户tenant_id999999 最近1年 命中4200万行 P95≈14.8s如果 SQL 使用 JDBC PreparedStatement团队还可能观察到更加诡异的现象应用重启后前几次很快 运行一段时间后突然变慢或者先被普通参数调用 后续热点参数变慢反过来也可能先跑超级租户 普通用户查询后来变慢这就是典型Parameter Sensitive Plan问题。真正根因通常是两件事同时出现1. 参数分布高度不均匀 2. SQL计划被缓存/复用KingbaseES 官方“缓存执行计划”文档说明数据库会缓存执行计划以避免每次都重新规划。对于 PBE 扩展协议执行计划保存在进程本地内存里对于准备语句plan_cache_mode可以控制通用计划与定制计划的选择。官方文档对二者定义得很清楚Generic Plan 不针对某一个具体参数值生成 多个参数共用一套计划 Custom Plan 把本次参数值作为常量参与规划 可以根据具体参数选择计划通用计划节省规划时间但在数据分布高度倾斜时一套计划很难同时适合所有参数因此本文的第一个核心结论是参数敏感不是“计划随机波动”而是同一 SQL 横跨了多个完全不同的成本区间而缓存机制试图用一套计划覆盖这些区间。2. 环境与数据参数敏感测试不能只拿“典型平均值”示例表CREATETABLEapi_order(order_idBIGINTPRIMARYKEY,tenant_idBIGINTNOTNULL,customer_idBIGINTNOTNULL,statusINTNOTNULL,created_atTIMESTAMPNOTNULL,amountNUMERIC(18,2));数据总订单 2亿 普通租户 每租户 1万~5万 大客户 500万~1000万 超级租户 4000万索引CREATEINDEXidx_api_order_tenant_createdONapi_order(tenant_id,created_atDESC);CREATEINDEXidx_api_order_tenant_status_createdONapi_order(tenant_id,status,created_atDESC);2.1 参数至少分三组不要只测试一个典型tenant_id必须明确普通值 热点值 极端长尾值例如普通 tenant101 1天 120行 热点 tenant880001 180天 1800万行 极端 tenant999999 365天 4200万行2.2 为什么“平均参数”没有意义假设99%的租户只有2万订单 1%的租户拥有60%的数据平均值可能每租户20万但生产上根本没有真正代表性的20万租户优化器需要面对的是2万 和 4000万两种完全不同的访问方式。因此参数敏感测试一定要使用分位数 热点组 长尾组而不是平均值。2.3 日期范围也是参数敏感的一部分同一个租户最近1天可能适合Index Scan最近2年返回全租户80%的数据可能更适合Bitmap/Seq Scan所以接口参数敏感常常不是单列tenant_id而是tenant_id × date range × status共同决定。3. 复现过程强制Generic和Custom直接证明是不是参数敏感3.1 使用 PREPARE 建立可复现实验PREPAREq(bigint,int,timestamp,timestamp)ASSELECTorder_id,customer_id,amount,created_atFROMapi_orderWHEREtenant_id$1ANDstatus$2ANDcreated_at$3ANDcreated_at$4ORDERBYcreated_atDESCLIMIT100;官方 PREPARE 文档说明准备语句可以使用 generic plan 也可以使用 custom plan并且EXPLAIN EXECUTE可以检查实际使用的计划。如果计划里仍显示$1 $2通常代表Generic Plan如果变成tenant_id 999999这样的具体值Custom Plan3.2 force_generic_plan复现“同一计划打天下”SETplan_cache_modeforce_generic_plan;普通参数EXPLAIN(ANALYZE,BUFFERS,VERBOSE)EXECUTEq(101,1,2026-08-01,2026-08-02);计划Index Scan estimated rows15000 actual rows120 P9512ms完全没问题。再执行超级租户 365天同一 Generic PlanIndex Scan estimated rows15000 actual rows42000000Buffers1500万P9514.8s此时已经可以证明不是SQL写法突然变化而是通用计划对普通参数合理 对超级参数严重失配3.3 force_custom_plan让参数参与规划SETplan_cache_modeforce_custom_plan;普通参数Index Scan actual120 P9513ms热点参数Bitmap / Seq Scan 或 不同Join计划 actual4200万 P951.9s同一 SQL不同参数 →不同执行计划而且两边都合理。这就是参数敏感最直接的证据。3.4 为什么auto有时候仍会选到不理想计划KingbaseES 官方缓存执行计划文档说明plan_cache_modeauto是默认模式。官方描述的策略是前五次执行先生成定制计划 计算这些定制计划的平均估算代价 之后再生成通用计划 比较Generic代价与Custom平均代价 决定是否值得缓存复用这个机制的出发点非常合理平衡规划成本与执行成本但它有一个工程前提前几次参数必须能代表后续真实分布。假设应用启动后前五次请求恰好都是普通小租户它们都Index Scan非常便宜随后超级租户进入。如果最终复用的 Generic Plan 对热点值估算很差参数敏感问题就会出现因此线上诊断时必须问慢SQL第一次由什么参数执行 PreparedStatement生命周期多久 连接池是否长期复用同一个后端Session4. 方案实施不要第一反应就全局 force_custom_plan4.1 方案一先修统计信息参数敏感首先是参数值代表的数据量不同如果统计信息又不准确问题会被进一步放大执行ANALYZEapi_order;KingbaseES 官方运行时统计文档说明自动统计机制会在 DML 变化达到阈值时执行 ANALYZE帮助优化器使用更新后的统计信息。仍需检查热点值是否进入统计 统计目标是否足够 多列条件是否存在相关性4.2 方案二观察 estimated vs actual普通estimated130 actual120很好。热点estimated15000 actual42000000差2800倍此时不能只说Generic Plan不好还要问为什么优化器对热点分布认知这么差所以统计修复是基础。4.3 方案三针对高频接口使用Custom Plan如果接口单SQL执行成本高 参数差异巨大 规划时间只有1ms左右那么每次重新规划可能是值得的。例如Planning Time 1.2ms Execution差异 14.8s vs 1.9s为节省1ms而承受十几秒显然不划算。此时可以评估会话级 角色级 特定连接池使用force_custom_plan而不是全局。4.4 为什么不建议全局 force_custom_plan因为系统还有很多简单点查 短SQL 高QPS它们本身执行0.5ms规划0.3ms如果每次都重新规划CPU成本比例很高所以Custom Plan应该只给真正参数敏感、且执行成本远高于规划成本的接口。4.5 方案四接口分型如果业务已经清楚存在普通租户 超级租户可以直接拆普通查询接口 大客户查询接口普通tenant_id? 短日期LIMIT100目标Index Scan超级租户大时间范围 统计/导出走批量查询 汇总表 异步任务而不是强迫一个SQL覆盖完全不同的业务量级。4.6 方案五按日期范围分流例如7天走在线实时索引查询。90天走报表库 汇总表 离线任务这比让同一个PreparedStatement同时覆盖1天 365天更稳定。4.7 方案六SQL模板拆分如果普通参数和热点参数永远需要不同计划。可以让 SQL 文本本身不同Q_NORMAL Q_HOT从而分别缓存计划这是一种非常实用的Plan Segmentation思想。不要把所有流量放到同一个SQL fingerprint里。4.8 方案七清理缓存计划只能作为诊断/恢复动作PBE 计划缓存情况下DISCARDPLANS;可以清除当前会话缓存计划。官方文档也说明当表定义 函数定义 统计信息变化时对应缓存计划会自动失效。但不断手工DISCARD PLANS不是长期治理。如果每隔半小时清缓存才能恢复说明真正问题仍然存在。4.9 应用连接池会放大问题KingbaseES PBE 缓存计划保存在进程本地内存Java HikariCP长连接意味着同一个后端Session 可能长时间持有PreparedStatement/计划行为所以 DBA 在新ksql Session里复现不到应用慢计划并不奇怪。必须用真实JDBC调用 真实PreparedStatement 真实连接池测试。4.10 使用 sys_prepared_statements 检查当前会话KingbaseES 官方sys_prepared_statements视图可以查看当前会话中可用的准备语句包括name statement prepare_time parameter_types from_sql这对验证当前session到底准备了什么SQL非常有帮助。4.11 不要把“参数嗅探”当成唯一解释如果每次强制custom仍然都选择同一个坏计划说明不是缓存问题更可能是统计失真 索引不合理 SQL本身不佳 成本参数错误所以诊断必须同时做Generic vs Custom对照。4.12 参数敏感还可能来自 Join 顺序例如tenant普通订单120行。最优订单小集 →Nested Loop →客户表超级租户订单4200万最优可能变Hash Join如果缓存普通参数生成的Nested Loop再给超级租户Inner loops可能爆炸。因此不要只检查Scan还要比较Join Method Join Order5. 结果对比从14.8秒波动到稳定800ms真正有效的是“计划分区”E0强制Generic普通12ms超级租户14.8sP99严重波动E1force_custom_plan普通13ms Index Scan超级租户1.9s Bitmap/Seq Hash性能明显稳定。代价每次多约1ms规划时间E2统计修复 auto热点估算15000 →4000万更接近actual4200万auto 模式更少出现灾难计划P952.4sE3接口分型普通在线明细接口 P9511ms超级租户长范围批量/汇总接口 P95800ms这时已经不是让优化器在一条SQL里猜而是业务主动声明查询规模计划最稳定。5.1 示例结果实验模式普通参数超级参数结论E0Generic12ms14.8s波动巨大E1Custom13ms1.9s执行稳定规划略增E2auto统计修复12ms2.4s可接受E3接口分型11ms0.8s最稳定以上为方法演示数据不是生产实测。5.2 不能只看Execution TimeCustom Plan执行更快但要记录Planning Time例如Generic Planning 0.2ms Custom Planning 1.6ms如果 SQL 本身执行10秒无所谓。如果执行0.4ms就很重要。所以需要比较Planning Execution总成本。5.3 高频接口要看CPU假设1万QPS每次多0.5ms规划CPU累计成本非常高。这就是为什么全局force_custom通常不是好方案。5.4 P99比平均值更重要参数敏感接口经常平均值很好 P99灾难因为99%普通用户快 1%超级租户极慢平均看起来只有100ms但 VIP 客户15秒所以验收重点参数组P95/P99而不是总体平均值。5.5 Buffer Read可以解释为什么计划错普通 Index ScanBuffer Read2400超级租户错误 Index Scan1500万Custom 热点计划320万说明热点参数真正需要不同访问路径不是单纯CPU偶尔抖了一下6. 风险与复盘处理参数敏感最危险的是把“局部救火参数”变成“全局策略”6.1 风险一全局force_custom_plan好处参数敏感SQL改善坏处所有PreparedStatement都增加规划成本应该优先会话 角色 特定连接池控制范围。6.2 风险二全局force_generic_plan对于高度均匀 简单SQL可能很好。但热点分布接口风险极大不能只为了减少Planning CPU全局强制。6.3 风险三只测普通参数测试环境每个租户数据都差不多生产几个超级租户占60%参数敏感问题根本不会在测试暴露。测试数据必须保留真实倾斜6.4 风险四统计信息过期数据分布改变后热点租户可能从100万 →4000万而统计信息还停留在旧分布。自动 ANALYZE 有帮助但超大表、热点列仍应该建立专门统计质量监控。6.5 风险五接口分型后语义不一致普通接口实时明细超级租户汇总路径必须明确一致性 延迟 排序 分页差异。不能为了快偷偷改变业务含义。6.6 风险六清计划缓存造成抖动大范围DISCARD PLANS会让大量 SQL重新规划可能产生短期 CPU 抖动。只在明确范围 维护/诊断窗口使用。6.7 风险七连接池每个Session状态不同PBE 计划缓存是进程本地不同连接可能持有不同计划状态于是应用表现为同一个接口 有的连接快 有的连接慢这正是生产里最难定位的一类抖动。所以压测必须覆盖多连接 长期复用 连接池生命周期推荐诊断顺序1. 固定SQL指纹 2. 参数分桶 3. EXPLAIN EXECUTE普通/热点/极端参数 4. force_generic_plan 5. force_custom_plan 6. 比较Plan/estimated/actual 7. ANALYZE与统计修复 8. 评估auto 9. 必要时接口/SQL分型 10. JDBC连接池并发验收回退方案如果新的缓存策略或接口分型上线后出现CPU升高 Planning Time激增 普通用户P99恶化 热点接口错误执行1. 停止扩大新策略 2. 恢复原SQL/接口路由 3. 恢复原plan_cache_mode 4. 必要时在受控Session DISCARD PLANS 5. 保存Custom/Generic执行计划 6. 重测普通/热点/极端参数 7. 保留新统计信息除非有证据说明它本身造成回归不要一出问题就回滚ANALYZE统计信息本身通常应该保留真正应回退的是不合适的SQL或缓存策略最终复盘参数敏感 SQL 的本质可以概括为同一查询模板 不同参数选择性 不同最优计划 计划缓存复用 性能波动真正的解决方案不是永远Custom也不是永远Generic而是先判断参数分布是否跨越多个成本区间如果普通参数120行热点参数4200万行那么要求一套计划同时最优本身就不现实。这时更成熟的策略是准确统计 Custom/Generic对照 合理缓存 参数分组 必要时业务接口分型如果只记住一句话参数敏感问题的核心不是“缓存计划好不好”而是同一 SQL 的不同参数是否本来就需要不同计划当参数分布跨越多个数量级时应该让统计、计划缓存和接口设计共同承认这种差异而不是强行用一套计划覆盖所有用户。附录 A检查当前计划缓存模式SHOWplan_cache_mode;附录 B检查准备语句SELECTname,statement,prepare_time,parameter_types,from_sqlFROMsys_prepared_statements;附录 CCustom/Generic对照SETplan_cache_modeforce_custom_plan;EXPLAINEXECUTEq(...);SETplan_cache_modeforce_generic_plan;EXPLAINEXECUTEq(...);RESET plan_cache_mode;附录 D最低验收门禁[ ] 普通参数已测试 [ ] 热点参数已测试 [ ] 极端长尾参数已测试 [ ] Generic/Custom计划差异已确认 [ ] estimated/actual无重大未解释偏差 [ ] Planning Time已量化 [ ] P95/P99达到SLA [ ] CPU规划开销在预算内 [ ] JDBC/PBE已测试 [ ] 多连接池Session已测试 [ ] 统计信息新鲜 [ ] 回退策略已准备转载自https://blog.csdn.net/u014727709/article/details/163950047欢迎 点赞✍评论⭐收藏欢迎指正