Dynamic SQL为何提升性能

“Dynamic SQL 提升性能”这个说法并不绝对，准确地说：动态 SQL 在特定场景下可以提升性能，也可能降低性能。它提升性能的核心原因，主要是减少不必要的开销、提高执行计划复用率、避免全表扫描等。

下面从原理和常见场景说明。

一、Dynamic SQL 为什么“可能”提升性能

1️⃣ 避免无效的固定条件（减少数据扫描）

静态 SQL 常写成：

SELECT * FROM orders
WHERE (status = @status OR @status IS NULL)
  AND (city = @city OR @city IS NULL);

问题：

• 优化器很难用好索引
• 容易全表扫描

动态 SQL：

DECLARE @sql NVARCHAR(MAX) = 'SELECT * FROM orders WHERE 1=1';
IF @status IS NOT NULL
  SET @sql += ' AND status = @status';
IF @city IS NOT NULL
  SET @sql += ' AND city = @city';

✅ 只生成真正需要的 WHERE 条件
✅ 更容易走索引
✅ 减少 IO 和 CPU

2️⃣ 生成更优的执行计划

• 静态 SQL：一个语句要兼容所有参数组合
• 动态 SQL：不同参数 → 不同 SQL → 不同执行计划

例如：

• 查“管理员” → 走索引
• 查“全部用户” → 直接扫表更快

动态 SQL 可以为不同场景选择不同最优路径

3️⃣ 避免参数嗅探（Parameter Sniffing）问题

静态 SQL：

CREATE PROC p @type INT
AS
SELECT * FROM t WHERE type = @type;

• 第一次执行用参数 A 生成计划
• 后续参数 B 可能极慢

动态 SQL + OPTION(RECOMPILE) 或不同 SQL 文本：

SET @sql = 'SELECT * FROM t WHERE type = @type OPTION(RECOMPILE)';

✅ 每次按真实参数生成计划

4️⃣ 减少不必要的列和表

静态 SQL 常 SELECT * 动态 SQL 可：

• 只查需要的列
• 只 JOIN 需要的表

➡ 减少网络、内存、临时表压力

5️⃣ 分库分表 / 动态表名

SET @sql = 'SELECT * FROM log_' + @month;

• 静态 SQL 做不到
• 避免超大表扫描

二、为什么 Dynamic SQL 也可能“降低性能”

⚠️ 注意事项：

• 每次拼 SQL → 重新编译（CPU 开销）
• 执行计划无法缓存（或缓存命中率低）
• SQL 注入风险
• 可读性差、维护难

三、什么时候“该用”动态 SQL 提升性能

✅ 多条件搜索（管理后台）
✅ 参数差异极大（数据分布不均）
✅ 动态表名 / 分表
✅ 静态 SQL 执行计划明显不合理

❌ 简单 CRUD
❌ 高频小查询
❌ 参数固定

四、一句话总结

Dynamic SQL 提升性能的本质：
让 SQL 在“正确的时间，用正确的结构，走正确的索引”

如果你愿意，我可以：

• 给你一个 静态 vs 动态 SQL 性能对比示例
• 或针对 MySQL / SQL Server / Oracle 分别说明