H2数据库优化器在特定场景下索引排序执行计划选择问题分析

问题背景

在H2数据库的实际使用中，开发人员发现了一个关于查询优化器的有趣现象：当查询涉及自连接并带有ORDER BY子句时，优化器在某些情况下无法正确选择最优执行计划，特别是当索引排序优化(Index-Sorted Optimization)可行时表现尤为明显。

问题复现

通过以下测试用例可以稳定复现该问题：

1. 创建测试表并插入数据：

CREATE TABLE Addr(
    ID INT PRIMARY KEY, 
    First VARCHAR(50), 
    Name VARCHAR(50), 
    ZIP INT, 
    Create_At datetime not null
);

2. 创建包含正序和倒序的复合索引：

CREATE INDEX addr_index_name ON Addr(Name asc, Name desc);
CREATE INDEX addr_index_create_at ON Addr(Create_At asc, Create_At desc);

3. 执行以下查询时会出现性能差异：

-- 快速执行（使用索引排序优化）
SELECT * FROM addr a JOIN addr b ON a.name = b.name 
ORDER BY a.name DESC LIMIT 10;

-- 慢速执行（未使用索引排序优化）
SELECT * FROM addr a JOIN addr b ON a.name = b.name 
ORDER BY a.name ASC LIMIT 10;

技术分析

根本原因

经过深入分析，问题根源在于H2优化器的成本估算逻辑存在缺陷：

1. 索引定义问题：测试中创建的(Name asc, Name desc)这样的索引定义实际上没有意义，反而会增加索引大小和降低性能。合理的做法应该是只定义单列索引。

2. 成本估算偏差：优化器在计算不同执行计划的成本时，对于正序和倒序扫描的成本估算不一致，导致在某些情况下选择了次优的执行计划。

3. 主键与唯一索引差异：当使用主键约束时，优化器能正确识别索引排序优化机会；但当使用唯一索引时，优化器在某些情况下会错误地选择表扫描而非索引扫描。

优化器决策过程

通过分析优化器的内部决策日志，可以观察到：

1. 对于ASC排序查询，优化器错误地认为表扫描成本(10,200)低于索引扫描成本(11,010)，因此选择了表扫描方案。

2. 对于DESC排序查询，优化器正确地识别了索引扫描的优势，选择了更高效的执行计划。

3. 当使用主键约束替代唯一索引时，优化器能够对ASC和DESC排序都正确应用索引排序优化。

解决方案建议

1. 避免冗余索引定义：不应在同一索引中重复定义相同列的正序和倒序，这会增加存储开销并可能干扰优化器决策。

2. 优化器改进：需要修正成本估算模型，确保对正序和倒序扫描的成本估算一致，特别是在涉及自连接和LIMIT子句的场景下。

3. 查询重写：在优化器修复前，可以尝试通过查询提示或重写查询来引导优化器选择正确的执行计划。

性能影响

该问题对以下场景影响显著：

1. 大数据量表上的自连接查询
2. 带有ORDER BY和LIMIT子句的查询
3. 使用非主键索引进行排序的情况

在测试案例中，性能差异可达两个数量级（8ms vs 117,576ms），对用户体验和系统性能影响重大。

结论

H2数据库优化器在特定场景下的执行计划选择存在改进空间，特别是在涉及自连接和排序操作的查询中。开发人员应注意索引设计的合理性，并关注数据库版本更新以获取优化器改进。同时，这也提醒我们数据库优化器的复杂性，即使是成熟的数据库系统也需要持续优化和调整。

对于H2数据库用户，建议在性能关键的查询上仔细检查执行计划，必要时通过查询重写或使用最新版本来规避已知问题。