干数据库优化的年头久了你迟早会遇到一种特别“邪门”的慢SQL数据量没涨多少执行计划却在一夜之间换了路线性能从几百毫秒直接掉到十几秒。查来查去问题不出在SQL本身索引也建得好好的最后你会一声长叹——是优化器自己“想多了”它在庞大的计划空间里选了一条烂路。这几年我接触金仓KingbaseES比较多尤其关注他们提出的“先判定后评估”优化框架。这套机制针对的正是传统代价优化器“什么都想算清楚最后却算不明白”的老毛病。这篇文章我会从问题根源说起拆解这个框架到底改写了哪些规则再结合SpringBoot集成金仓V8的真实项目场景把配置、实操、踩坑一次讲透。1. 优化器的传统困局好端端的SQL为什么越跑越慢1.1 一次夜间的慢SQL报警让我开始怀疑“成本模型”先讲一个真实经历。某个业务系统上线两年一直很稳。某天夜里突然收到一批慢SQL告警全是同一类统计查询涉及7张表关联还带一个NOT EXISTS子查询。我习惯性地先看执行计划第一反应是索引没建对仔细一看却发现一个诡异现象优化器把数据量最大的订单明细表放在了连接顺序的中间位置还选用了嵌套循环连接而驱动表却是经过过滤后数据量并不小的客户表。更要命的是这条SQL上周还走的是另一个计划执行只要1秒出头。这周统计信息一刷新计划变了执行时间变成了9秒多。数据量几乎没涨业务SQL也没改性能却差了近十倍。这种“同一条SQL今天快明天慢”的案例就是传统基于代价优化器CBO最典型的脆弱性它根据统计信息和代价模型给所有候选计划打分可统计信息有误差模型又有一堆假设分数一旦失真选出来的“最优计划”就是一场灾难。1.2 计划空间爆炸优化器也会“算不过来”很多人以为优化器选计划就像查字典按某种规则一翻就出来了。真相是它要在巨大的搜索空间里做组合优化。拿最简单的多表连接来说n张表做连接理论上的连接顺序就有n! / 2种5张表是60种7张表是2520种10张表直接奔着180万种去。而且这还只是连接顺序每种顺序还要叠加连接算法嵌套循环、哈希连接、排序合并、访问路径全表扫描、索引扫描、位图扫描、并行度等组合。所有因素乘在一起计划空间会膨胀到优化器根本枚举不完的程度。为了把优化时间控制在可接受范围内传统优化器只能做剪枝或者干脆提前终止搜索。麻烦就出在这里剪枝剪得不够狠优化器会在大量低质量计划里浪费时间剪枝剪得太狠又可能把真正的好计划提前淘汰。这有点像你用地图导航从A地到B地如果算法把每个路口的上百种走法都完整算一遍等你拿到结果天都黑了。可你要是只看路名不看红绿灯和拥堵推荐出来的路线可能又堵得死死的。1.3 代价模型的三个“软肋”让精算变成了精猜我做了这么多年数据库性能工作越来越觉得传统CBO的代价模型有三个绕不开的软肋。第一个是基数估算误差。优化器靠直方图、采样和统计信息来猜“这个条件能过滤出多少行”可一旦数据出现倾斜比如少数几个客户的订单量占了全表80%这种估算误差会被放大到指数级。第二个是成本模型滞后于硬件。顺序读和随机读的实际开销比例在机械硬盘、SSD、分布式存储上差别非常大优化器里写死的成本系数不可能适配所有环境。第三个是统计信息滞后。很多系统的统计信息是晚上定时更新的白天数据剧烈变化时优化器手里的“地图”早就过期了。这三个软肋单独出现还好说一旦叠加优化器选错计划几乎是必然事件。我整理过一个对照表基本能把问题看明白问题实际影响典型场景基数估算误差连接顺序选反小表驱动变慢数据倾斜、多列条件相关存储成本假设失真扫表方式选错随机读爆炸SSD、列存、分布式存储统计信息过期执行计划漂移性能忽好忽坏高频更新表、定时analyze不及时这也是为什么金仓提出“先判定后评估”时我会特别注意它。因为它在试图绕开这三个软肋不是靠一个更聪明的代价公式而是改变整个决策链条的结构。2. “先判定后评估”到底改写了什么规则2.1 一个朴素但实用的思想先别急着精算先判断值不值得算传统CBO的思路是“把所有候选计划都算到最细然后挑分数最高的”。“先判定后评估”完全换了顺序它把优化过程拆成两个阶段。第一阶段是判定用非常轻量的规则和粗粒度统计快速判断某一类计划到底值不值得投入资源去精算明显不可能优秀的路径直接淘汰。第二阶段才是评估只对通过判定的少量候选计划做完整的基数估算、成本计算和细节比较。我说的更直白一点传统方式相当于你招人时对每份简历都做一轮完整背景调查候选人有一万份你累死也看不完还容易看走眼。“先判定后评估”则先花几分钟筛简历把学历、经验明显不匹配的排除掉最后只对剩下的三五个人做深度面谈既省时间又提高了命中率。这个思想本身不复杂但要把“判定”这一步做得准、做得快非常考验数据库内核的功底。判得太多会把好计划误杀判得太少又起不到剪枝作用等于回到传统CBO的老路。2.2 金仓在判定阶段重点做的三件事从我实际观察到的行为来看金仓“先判定后评估”框架里的“判定阶段”并不是拍脑袋写几个规则而是至少做了三件很具体的事。第一是重写收益判定。SQL进来之后优化器不会先急着生成执行计划而是先判断这个SQL能不能改写成更优的形态。子查询能不能解关联谓词能不能下推外连接能不能消除分区裁剪能不能生效这些改写本身有成本如果改写后的计划明显更好才把改写结果保留下来进入后续评估。这一步解决了“SQL写法不好导致优化器没有发挥空间”的常见问题。第二是基数上下界判定。传统CBO对每种连接顺序都要精确估算中间结果的行数这是最耗时的环节。“先判定后评估”里优化器会用统计信息快速算一个上下界如果某个连接顺序在最理想的情况下中间结果都比另一条路径的最坏情况还大那这条路就直接枪毙连精算的资格都没有。这个思路非常像二分查找前先做范围判断能快速砍掉数量级差异巨大的计划。第三是访问路径可用性判定。索引、分区键、物化视图不是想用就能用的优化器会先判断它们是否真的适用于当前SQL的谓词和过滤条件。能用的才进入候选集不能用的直接忽略避免在无效访问路径上浪费评估时间。我还想强调一点这种“先粗筛再精算”的思路在工业界其实不孤独。PostgreSQL的GEQO应对复杂连接、Oracle的自适应计划、SQL Server的简易计划编译都在试图控制优化器的搜索代价。金仓的贡献在于把“判定”提升成了一个显式且独立的阶段让优化器的思考过程更透明也方便使用时针对不同负载做调整。2.3 和传统RBO、CBO放在一起看优势立刻清晰为了把“先判定后评估”的位置说清楚我喜欢拿它和传统两种优化方式做对比。基于规则的优化器RBO年纪最大它按预设规则选计划快但不管数据情况容易选出低效方案。基于代价的优化器CBO是过去二十多年的主流靠统计信息和代价模型挑计划但存在上一节说的三个软肋。“先判定后评估”则站在两者之间用规则做粗筛用代价做精算兼顾了效率和准确率。对比维度RBO基于规则CBO基于代价先判定后评估选择依据预设规则优先级统计信息代价模型规则粗筛代价精算优化开销低高中低计划稳定性高但容易低效容易漂移相对稳定典型适用场景简单固定SQL复杂查询复杂查询高并发混合负载这张表我在给团队做技术分享时用过很多次。核心结论是金仓这套框架不是要颠覆代价模型而是要给代价模型做“前置过滤”让优化器把宝贵的时间花在真正有希望的计划上。3. 实际落地在金仓KingbaseES里怎么把框架用起来3.1 版本选择与SpringBoot集成中的注意点想用上“先判定后评估”首先要选择和确认数据库版本。从我接触的情况看KingbaseES V8及后续版本才完整支持这套优化框架V7及更早版本并不具备所以建议新项目直接上V8系列老项目也要规划升级路径。升级前先在测试库把SQL全集回归一遍重点看复杂查询的执行计划变化因为优化器的行为变化可能让个别SQL从“次优”变成“更优”也可能短期内出现“不适应”需要重新分析统计信息。实际项目里SpringBoot集成金仓V8是非常常见的场景。数据源配置上我建议直接采用KingbaseES官方提供的JDBC驱动连接串写法如下spring.datasource.driver-class-namecom.kingbase8.Driver spring.datasource.urljdbc:kingbase8://192.168.1.100:54321/business_db spring.datasource.usernameapp_user spring.datasource.passwordyour_password这里有三个容易被坑的细节。第一端口不是MySQL的3306也没有用PostgreSQL的默认5432金仓V8的默认端口是54321连接串别写错。第二驱动类名是com.kingbase8.Driver不是org.postgresql.Driver虽然金仓兼容PostgreSQL协议但直接拿PG驱动连金仓可能碰到元数据兼容问题。第三建议在连接池比如HikariCP中把connection-init-sql设置为一条简单查询加快连接创建后的校验速度这在大并发下很管用。3.2 判断框架是否生效不要凭感觉看这些指标框架配好之后怎么确认它真的在干活我的习惯是先看优化耗时占比。执行EXPLAIN ANALYZE注意输出里的Planning Time和Execution Time如果优化耗时占总耗时的比例很高比如一条SQL执行只要2秒优化器却想了8秒说明计划搜索阶段的判定做得不够充分。开启并正确配置“先判定后评估”后正常情况下复杂SQL的Planning Time应该显著下降执行时间也可能因为计划选择更准而跟着下降。除了看执行计划还可以检查数据库日志里优化器相关的输出。金仓V8提供了一组优化器配置项不同小版本的参数名称可能有差异通用的做法是登录数据库执行SHOW ALL;然后过滤出包含optimizer、join、statistics关键字的部分。重点关注两类参数一类控制优化器搜索的深度和判定阈值另一类控制统计信息采样规模。我不建议直接抄网上的参数模板因为不同版本、不同CPU和内存配置下的最优值并不一样还是要结合自己业务SQL的复杂度来定。另外统计信息质量直接决定判定阶段的准确性。default_statistics_target这个参数值得单独看一眼默认值通常偏低对分布不均匀的大表可以适当调高但也不用调到离谱否则收集统计信息的时间会成倍增加。我一般先按照每列采样精度需求从100调到500观察两三天再决定是否继续加。3.3 不同负载类型的配置基线建议纯技术说参数容易让人晕我结合实践给三套基线建议适合大多数团队起步。第一类是OLTP在线交易场景特点是SQL短小、高频、要求低延迟。这时候“先判定后评估”的阈值可以调低快速出计划更重要不能让优化器为了几个百分点的理论收益把延迟拉高。第二类是OLAP分析型场景SQL复杂、单条耗时长、优化器思考时间占比显得没那么关键。阈值可以调高一些允许优化器在判定阶段保留更多候选计划多做一点精算换取更优的执行路径。第三类是混合负载我建议按SQL特征做区分比如简单点查和复杂分析分别走不同的处理通道或者通过限流和资源组把两类负载隔离开。这里有个行之有效的小技巧把容易“跑偏”的复杂SQL收集到一张清单每次发布新版本后统一看一遍执行计划有变化就重点核对避免优化器行为改变带来性能回退。4. 实操案例一条慢SQL在“先判定后评估”下的完整优化过程4.1 现场还原一条7表关联的统计查询理论说了不少拿个真实场景走一遍流程更直观。下面这段SQL是我从一个订单分析系统里整理出来的简化版本问题现象很经典每月初跑统计报表时这条查询特别慢而且每次跑出来的执行时间波动巨大。SELECT o.order_no, c.customer_name, p.product_name, od.quantity, od.amount, s.supplier_name FROM orders o JOIN customers c ON o.customer_id c.customer_id JOIN order_details od ON o.order_id od.order_id JOIN products p ON od.product_id p.product_id JOIN suppliers s ON p.supplier_id s.supplier_id JOIN regions r ON c.region_id r.region_id WHERE o.order_date DATE 2024-01-01 AND o.order_date DATE 2024-04-01 AND r.region_name IN (华东, 华南) AND NOT EXISTS ( SELECT 1 FROM returns re WHERE re.order_id o.order_id AND re.return_status 已退款 );刚接手时我的第一反应是先看索引。检查之后发现orders.order_date、order_details.order_id、returns.order_id都建了索引NOT EXISTS子查询也有索引可用。表面上没有明显短板执行计划却选了以regions表为起点、一路嵌套循环的做法整个计划做下来要扫海量随机IO。问题的深层原因有两个一是regions表经过条件过滤后的实际行数并不少但统计信息里把它的基数估得非常低二是优化器在评估海量连接顺序时没有做好剪枝导致一个理论上可以很早排除的差计划被保留了下来。4.2 排查顺序先排除统计信息问题再谈优化器问题遇到这类慢SQL我有个固定的排查顺序不会直接冲上去改SQL或者加索引。先收集统计信息确保优化器手里的“地图”是新的ANALYZE orders; ANALYZE customers; ANALYZE order_details; ANALYZE products; ANALYZE suppliers; ANALYZE regions; ANALYZE returns;更新完之后重新EXPLAIN ANALYZE计划还是老样子。这就排除了“统计信息过期”这一层问题确定在优化器自身的搜索策略上。紧接着我看Planning Time果然优化器耗时接近1.2秒而这条SQL执行耗时大约8.5秒。优化器花的时间看起来不长但它选择的执行路径直接放大了执行成本真正被杀死的不是优化速度而是执行效率。4.3 用“先判定后评估”的思路做针对性调整既然确认了问题出在计划搜索阶段就要从判定逻辑入手。按照“先判定后评估”的思路我做了三件事。第一检查regions表的日期和区域过滤条件能否更早下推让连接顺序从“小表驱动大表”变成“日期裁剪优先”。第二确认NOT EXISTS能不能改写成反连接Anti Join并用哈希方式执行避免嵌套循环对returns表造成大量重复访问。第三观察判定阈值参数是否需要调整这里不同版本名称不一样我建议先查配置再看实际效果。操作结束后重新生成执行计划优化器终于把orders表作为驱动表先通过日期条件裁剪出三个月的数据再依次哈希连接到明细、客户、商品、供应商同时把NOT EXISTS转成了哈希反连接。最终执行耗时降到了900毫秒左右优化耗时也降到了120毫秒以内整条SQL从“跑一次报表能喝杯茶”变成了“秒出结果”。优化前后的效果对比如下指标优化前优化后优化器耗时约1.2秒约120毫秒执行耗时约8.5秒约980毫秒计划稳定性随数据变化漂移稳定中间结果扫描方式大量随机IO顺序扫描哈希连接4.4 这次优化复盘下来的三点体会第一“先判定后评估”解决的是“选择范围过大”的问题它不能替你把统计信息质量变好。如果基数估算是错的判定阶段同样可能误判。所以定期ANALYZE还是基本功别指望框架能兜底一切。第二对于NOT EXISTS这种子查询有时候写成显式的LEFT JOIN ... WHERE re.order_id IS NULL反而更容易让优化器理解这算是对查询优化器的“友好沟通”。第三出现性能问题不要上来就调参数先看统计信息和执行计划变化趋势把问题分层逐层排查才能把“先判定后评估”用对地方。5. 常见问题与避坑清单5.1 判定阶段会不会误杀“好计划”会。判定规则毕竟依赖统计信息和启发式规则在统计信息严重过期、数据剧烈倾斜或者SQL里有复杂表达式时判定阶段可能把一条本来很好的计划给“误杀”掉。我的排查方法很直接拿同样的SQL通过提示Hint强制走一条手动指定的路径跟默认计划做对比。如果强制路径明显更快说明默认的判定有问题。这时候优先做的不是关掉整个框架而是先更新统计信息看问题是否消失。如果更新后还是误判再考虑调整判定阈值或者对个别SQL用Hint固定关键连接方式。金仓V8兼容多种Hint风格实际使用中/* ... */注释内写法在一些场景下是管用的但也别一场SQL里堆十几个Hint那会把优化器完全绑死后续维护成本很高。5.2 框架对每条SQL都会生效吗不会。简单SQL本身的计划空间很小判定阶段会快速放行你几乎感觉不到它的存在。所以如果你拿一条SELECT * FROM t WHERE id ?去对比优化耗时看不出什么差别是完全正常的。这套框架的价值主要体现在多表连接、复杂子查询、分区裁剪、大范围排序这些场景里。我给团队定的规则是只有当单条SQL的优化耗时超过总耗时10%以上或者执行计划频繁漂移时才需要重点去看判定阶段的日志和参数。5.3 和SpringBoot连接池共存要注意驱动版本集成框架是优化器侧的行为跟应用层的连接池没有直接冲突。但有一个容易忽略的隐患如果JDBC驱动版本和数据库服务端版本不匹配执行计划相关的元数据接口可能返回不完整导致优化器拿不到足够的统计信息。我在项目里出现过驱动版本偏老、查不到新增列直方图的情况解决办法很简单升级驱动到和数据库小版本对应的版本。连接池大小不用为了“先判定后评估”做特别调整但要注意长连接持有时间对数据库会话内存的影响。5.4 排查问题速查表最后整理一张速查表方便遇到类似问题时快速定位现象可能原因排查思路解决办法SQL突然变慢计划变更统计信息过期执行ANALYZE后对比计划更新统计信息建立定期任务优化耗时占比过高判定阈值偏严或偏松查看Planning Time占比调整优化器搜索深度相关参数强制Hint后变快默认计划慢判定阶段误杀好计划对比执行计划差异更新统计信息必要时固定Hint高并发下优化器CPU飙升复杂SQL过多判定压力大监控数据库CPU占用SQL改写降低复杂度调整阈值集成SpringBoot后偶发连接异常驱动版本不匹配查看驱动版本与库版本升级JDBC驱动到对应版本写到这里说点个人体会。刚开始接触“先判定后评估”时我也把它当成一个“开关型”功能以为打开就能解决所有慢SQL。后来翻了不少日志、对比了几十组执行计划才明白这套框架的本质是给优化器装上了一个“判断力前置”的阀门。真正能不能发挥作用取决于你对统计信息维护的重视程度也取决于你对业务SQL的理解深度。调参数只是在修表把数据喂准、把SQL写诚实再让框架去粗筛精算才是这条路上最省心的组合。我在实际项目中踩过几次坑之后现在面对任何数据库性能问题都会先问一句优化器到底是在认真思考还是在无效枚举想清楚这个问题很多故障都不会走到熬夜加班的境地。