动态拼接含子查询的语句本质是将整个SQL（含子查询）作为字符串整体拼接，必须用PREPARE+EXECUTE执行；MySQL不支持变量直接替代表名、列名或子查询结构，子查询须完整拼入字符串并带显式别名，参数用?占位符绑定。
动态拼接含子查询的语句，本质不是“让子查询变动态”，而是把整个含子查询的 SQL 字符串当做一个整体来拼——子查询只是字符串里的一段文本。直接在静态 SQL 里用变量替换子查询内容，SQL 引擎根本不认。
MySQL 中必须用 PREPARE + EXECUTE 拼完整字符串
MySQL 不允许在 FROM、WHERE 或 SELECT 子句中直接使用变量代替表名、列名或子查询结构。你写 SELECT * FROM (SELECT id FROM @tbl) t 会报错 ERROR 1146 (42S02): Table 'db.@tbl' doesn't exist。
- 子查询部分（包括括号、别名、ORDER BY、LIMIT）必须完整拼进
@sql字符串里，例如：SET @sql = CONCAT('SELECT * FROM (SELECT id, name FROM ', @table_name, ' WHERE status = ? ORDER BY created_at DESC LIMIT 5) AS t'); -
@table_name必须先用REGEXP '^[a-zA-Z_][a-zA-Z0-9_]*$'校验，否则可能被注入成log_202405` UNION SELECT password FROM users -- - 子查询必须带显式别名（如
AS t），否则FROM (subquery)语法不合法 - 如果子查询里要传参，只能用
?占位符，且后续必须用EXECUTE stmt USING @val绑定，不能直接拼值
SQL Server 中优先用 sp_executesql 而非 EXEC()
虽然两者都能执行动态 SQL，但 sp_executesql 支持参数化，能复用部分执行计划；而 EXEC(@sql) 每次都是硬解析，尤其当子查询里有 WHERE p.order_id = o.order_id 这类关联字段时，优化器更难推导数据分布。
- 拼接时用
QUOTENAME(@table_name)包裹表名，比手动加方括号更安全（自动处理中划线、空格、保留字） - 子查询中的字符串值要用双单引号转义：
WHERE level = ''ERROR''，不能写成WHERE level = '''ERROR'''—— 后者在sp_executesql中会被当成三个单引号字面量 - 避免在子查询里拼
IN (SELECT ...)，改用EXISTS：前者遇到 NULL 会整体失效，后者只看是否存在匹配行 - 如果子查询本身也依赖参数（比如外层传入
@start_time），必须在sp_executesql的参数定义部分统一声明，不能只在外层拼
嵌套子查询 + 动态表名最容易忽略执行计划缓存失效
哪怕只是多一个空格、换一行、字段顺序调换，SQL Server 就认为是全新语句；MySQL 的 PREPARE 语句每次 EXECUTE 都是独立编译。这意味着：你每换一张日志表（log_202405 → log_202406），就失去所有缓存收益。
- 不要指望“拼得差不多就能复用计划”——只要
@sql字符串的 hash 值不同，就是新语句 - 若业务允许，把高频变动的表名映射为固定别名（如
CASE @month WHEN '202405' THEN 'log_may' END），减少字符串差异 - 子查询里避免
SELECT *，明确列出字段，防止因底层表结构变更（新增列）导致拼出的字符串长度突变，间接影响缓存命中 - SQL Server 中可对关键动态查询加
OPTION(RECOMPILE)，强制每次重编译，反而比错误复用旧计划更稳
真正麻烦的不是怎么拼，而是拼完之后那条语句再也没法被数据库当“普通查询”对待——它失去了索引选择稳定性、参数嗅探一致性、甚至事务可见性边界。动手前先问一句：这个动态性，是不是非得塞进存储过程里？
