Alexander Ioffe：为什么我的“鲸鱼查询”在生产环境中慢了1000倍？数据库都讨厌数据倾斜，但各有各的恨法
内容提要
ExoBench实测显示，外键数据倾斜（10个大客户占80%订单）导致同一三表连接查询比均匀数据慢约千倍：Postgres从1毫秒升至1572毫秒，SQL Server升至2340毫秒。两引擎均因单列直方图无法识别跨连接相关性而低估约3000倍。修复方式不同：Postgres关闭嵌套循环即可降至约310毫秒；SQL Server需覆盖索引、批处理模式与哈希连接三者叠加才达约330毫秒。
延伸解读
数据分布：基准测试的隐藏变量
文章通过均匀数据与倾斜数据的对比，揭示了测试数据分布对查询性能的颠覆性影响。均匀数据下查询仅需1毫秒，而倾斜数据下飙升至1572毫秒（Postgres）和2340毫秒（SQL Server）。这提醒我们，使用Faker等工具生成的均匀测试数据会掩盖生产环境中的性能问题，导致上线后才发现灾难。因此，基准测试必须模拟真实的数据分布，尤其是外键的倾斜情况。
基数估计盲区：跨连接相关性
两个数据库的优化器都严重低估了连接后的行数，误差高达3000倍。根本原因在于单列直方图无法捕捉跨连接的相关性：orders.customer_id的直方图将所有客户平均化，无法识别少数大客户贡献了绝大多数订单。这种结构性缺陷并非统计信息过期，而是模型本身的局限。Postgres的扩展统计和SQL Server的过滤统计都无法解决，因为相关性跨越了连接边界。
修复策略的不对称性：引擎间的关键差异
Postgres和SQL Server虽然因相同原因变慢，但修复方式截然不同。Postgres只需关闭嵌套循环（SET enable_nestloop = off），查询时间从1572ms降至约310ms，无需更改架构。而SQL Server的瓶颈在于访问路径中的72万行键查找，任何连接提示都无法突破2000ms底线，必须组合覆盖索引、批处理模式和哈希连接才能达到约330ms。这表明优化建议不能跨引擎直接套用。
结构修复的代价与收益：并非总是最优
将倾斜表拆分以提供诚实统计信息是教科书式的修复，但在两个引擎上收益不同。SQL Server上拆分表后查询仅193ms，优于覆盖索引方案；而Postgres上拆分表后为391ms，反而比免费的会话设置（321ms）更慢，且需要架构重构。因此，当错误估计只是导致可恢复的算法选择时，廉价的症状修复可能优于昂贵的根因修复。
Q&A
为什么同一个三表连接查询在生产环境比测试环境慢1000倍？
因为生产数据存在外键数据倾斜：10个企业客户拥有80%的订单，而测试数据是均匀分布的。这导致优化器严重低估连接结果行数（约3000倍），选择了嵌套循环计划，从而执行时间从约1毫秒飙升至1572毫秒（Postgres）或2340毫秒（SQL Server）。
Postgres和SQL Server分别如何修复这种数据倾斜导致的慢查询？
Postgres只需一个会话设置：SET enable_nestloop = off，强制使用哈希连接，执行时间从1572ms降至约310ms。SQL Server则需要组合三个措施：创建覆盖索引（包含quantity和unit_price）、启用批处理模式、使用哈希连接，才能从2340ms降至约330ms。
为什么Postgres和SQL Server的优化器都会低估连接结果行数？
因为两个优化器都依赖单列直方图，而直方图无法捕捉跨连接的相关性。orders.customer_id的直方图将所有客户平均化，无法识别10个企业客户的订单量远高于平均值（约40000 vs 10），导致估计值严重偏低。
在SQL Server中，为什么强制哈希连接反而使查询更慢？
强制哈希连接导致两个问题：一是哈希连接溢出到tempdb，因为内存授予基于错误的低估计（约4.3MB），而实际构建侧有约40万行；二是计划中仍然包含72万行的键查找，因为提示只强制了连接算法，没有改变访问路径。结果比原始嵌套循环慢2.25倍。
什么是解决数据倾斜的“教科书式”方法？它在两个引擎上的效果如何？
教科书式方法是拆分表：将高频行（企业订单）拆到单独的表，使统计信息准确。在SQL Server上效果最好，执行时间193ms；在Postgres上为391ms，比免费的SET enable_nestloop = off（321ms）慢，且需要架构变更。
为什么均匀测试数据会掩盖数据倾斜问题？
均匀数据下，优化器估计准确（误差约2倍），嵌套循环计划是真正最优的，查询仅需约1毫秒。这会让开发者误以为查询和架构没有问题，从而在生产环境遭遇性能灾难。
