SQL查询性能差异主要源于数据库优化器的设计差异，包括规则/代价优化、统计信息依赖、索引选择逻辑、执行计划搜索空间及人工干预策略。
SQL查询性能差异，往往不只来自写法本身，更关键的是背后优化器如何理解并执行这条语句。不同数据库的优化器设计目标、统计信息使用方式、代价模型和可选执行路径各不相同，导致同一条SQL在MySQL、PostgreSQL、Oracle甚至同一数据库不同版本中，可能生成完全不同的执行计划。
优化器核心差异：基于规则 vs 基于代价
早期优化器（如SQL Server 7.0前、部分嵌入式数据库）主要依赖固定规则，比如“有索引就走索引”“WHERE条件越靠前优先级越高”。这类策略简单但僵化，容易忽略数据分布实际影响。
现代主流优化器（PostgreSQL、Oracle、MySQL 8.0+、SQL Server 2016+）均采用基于代价的优化（CBO），通过估算不同执行路径的I/O、CPU、内存开销选择“理论上最优”的计划。但代价估算是否准确，高度依赖统计信息的及时性与粒度。
- PostgreSQL默认采样率低，大表统计信息易过时，常需手动ANALYZE或调高default_statistics_target
- Oracle自动收集统计信息较成熟，但分区表全局统计若未启用INCREMENTAL模式，可能导致跨分区JOIN误判
- MySQL 5.7对复杂JOIN顺序选择较保守，8.0引入哈希连接与更灵活的JOIN重排序，但依然不支持物化CTE等高级决策
索引利用逻辑：不是“能走索引”就一定走
优化器是否选择索引，取决于它预估的“走索引+回表”总成本是否低于全表扫描。当查询返回行数占比过高（例如>15%~20%）、索引列选择性差（如性别字段）、或WHERE条件含函数/表达式（WHERE YEAR(create_time) = 2023）时，即使存在索引也可能被跳过。
- MySQL中LIKE 'abc%'可用索引，LIKE '%abc'则不能——优化器明确知道前缀匹配可定位B+树范围
- PostgreSQL对OR条件处理更激进，有时会拆成UNION ALL再各自走索引；MySQL通常不拆，倾向全表扫描
- Oracle在绑定变量场景下可能因“绑定变量窥探”（Bind Peek）误判，导致一个执行计划复用到不同参数值上，引发性能抖动
执行计划生成自由度：优化器能“想多远”？
优化器搜索执行计划的空间大小，直接影响结果质量。受限于时间与资源，它不会穷举所有可能，而是采用启发式剪枝。
- SQL Server默认使用“贪心算法”生成JOIN顺序，对5张以上表JOIN容易陷入局部最优；可通过FORCE ORDER提示干预
- PostgreSQL 12+支持GEQO（遗传算法优化器），对多表JOIN尝试跳出传统动态规划限制，但默认仅在from_collapse_limit超过8时启用
- MySQL至今不支持对子查询单独物化（Materialization），复杂子查询常被反复执行，而Oracle和PostgreSQL已支持自动物化临时结果集
统计信息与Hint：何时该信优化器，何时该干预？
优化器不是黑箱，但也不是万能。当它因统计偏差、模型简化或功能限制给出次优计划时，人工干预是必要手段——前提是先确认问题根源。
- 别一上来就加USE INDEX或/*+ INDEX() */，先查EXPLAIN ANALYZE（PostgreSQL）、EXPLAIN FORMAT=JSON（MySQL 8.0）、DBMS_XPLAN.DISPLAY_CURSOR（Oracle）看真实执行耗时与预估偏差
- 对稳定慢查，优先更新统计信息：ANALYZE table_name（PG）、ANALYZE TABLE table_name UPDATE HISTOGRAM ON col1, col2（MySQL 8.0+）
- Hint是最后手段。PostgreSQL中更推荐用SET enable_hashjoin = off等会话级开关临时验证；Oracle中/*+ OPT_PARAM('_optimizer_use_feedback' 'false') */可关闭自适应执行计划干扰
基本上就这些。理解优化器不是为了背命令，而是建立一种判断习惯：看到慢查，先问“它为什么这么选”，而不是“怎么让它按我想的走”。不同数据库的差异，本质是工程取舍——有的重稳定性，有的重灵活性，有的倾向DBA可控，有的倾向全自动。找准边界，才能用得踏实。
