Firebird数据库添加dummy条件后SQL查询性能差异问题

性能差异根本原因 #

两个逻辑完全等价的SQL性能差2倍的核心原因是Firebird 2.1、3.0版本的优化器没有实现无意义谓词的提前消除逻辑：
0=0这类恒真条件虽然不影响业务逻辑，但会被优化器计入WHERE谓词的优先级权重，打乱后续真实过滤条件的选择性评估顺序。

• 带0=0的查询：优化器误判过滤条件优先级，没有识别到t3.field=6的高选择性，选择了T2作为驱动表走全表扫描，后续嵌套循环关联T1、T3时产生了近10万次TABLE1非索引读取、38万次TABLE3索引读取，执行成本大幅升高。
• 不带0=0的查询：优化器正确识别到t3.field=6的高选择性，选择过滤后结果集极小的T1作为驱动表，T2走外键索引关联，总查询成本直接降低一半。

Firebird优化器核心工作逻辑 #

Firebird使用基于成本的优化器（CBO），执行计划生成逻辑如下：

• 解析SQL的关联条件、过滤条件，读取表、索引的统计信息（行数、区分度、平均行长度等）
• 枚举所有可行的表连接顺序，计算每种顺序的IO、CPU成本
• 选择成本最低的执行计划返回

2.1、3.0版本的优化器存在两个已知缺陷：

• 不会提前消除0=0、1=1这类恒真/恒假的无意义谓词，谓词的书写顺序会直接影响成本估算权重
• 多表关联时，如果WHERE开头存在无意义谓词，会降低后续过滤条件的选择性评估优先级，容易选错驱动表

Firebird高效SQL编写规范 #

要规避这类问题，可以遵循以下规则：

• 禁止在WHERE子句开头添加0=0类恒真谓词：很多动态SQL拼接框架习惯加这类条件简化AND拼接，在Firebird中需要调整逻辑，根据是否存在动态过滤条件决定是否拼接AND前缀
• 高选择性过滤条件前置：把能过滤掉80%以上数据的条件放在WHERE子句最前面，引导优化器选择正确的驱动表
• 复杂查询可手动指定执行计划：如果优化器多次选错执行计划，可以通过PLAN语法强制指定连接顺序和索引，示例语法：

SELECT t1.*
FROM table1 t1
JOIN table2 t2 ON t2.fk_t1 = t1.id
JOIN table3 t3 ON t3.id = t1.fk_t3
WHERE t3.field = 6
AND EXISTS (SELECT 1 FROM table2 x WHERE x.fk2_t2 = t2.id)
PLAN JOIN (T1 NATURAL, T3 INDEX (T3_ID_IDX1), T2 INDEX (T2_FK_T1_IDX))

• 定期更新统计信息：执行SET STATISTICS TABLE 表名;和SET STATISTICS INDEX 索引名;，确保优化器拿到准确的统计数据，减少执行计划选错的概率
• 条件允许的话升级到Firebird 4.0及以上版本，新版本已经修复了恒真谓词干扰成本估算的缺陷，等价SQL的执行计划一致性大幅提升。

内容的提问来源于stack exchange，提问作者Dżyszla