应使用参数化动态sql：sql server用sp_executesql，mysql避免相关子查询误用，postgresql函数中return query execute须配合using传参，深层嵌套需警惕执行计划失效。
SQL Server 存储过程中 EXEC 动态查询无法识别外部变量
在存储过程里拼接 SQL 字符串再用 EXEC 执行时，@param 这类变量不会自动带入动态语句里——它根本不在作用域内。不是语法错了，是作用域断了。
常见错误现象：Must declare the scalar variable "@user_id"，哪怕你在 EXEC 前明明定义并赋值了。
- 别用
EXEC('SELECT * FROM orders WHERE user_id = ' + @user_id)—— 数字拼接有 SQL 注入风险，字符串拼接要手动加引号，还绕不过变量不可见问题 - 改用
sp_executesql，它支持参数化传参：EXEC sp_executesql N'SELECT * FROM orders WHERE user_id = @uid', N'@uid INT', @uid = @user_id - 注意：参数名（
@uid）在 SQL 字符串里、类型声明里、实际传值里必须完全一致，大小写敏感（取决于数据库排序规则）
MySQL 8.0+ 中嵌套查询引用外层变量失败
MySQL 不支持标准 SQL 的“相关子查询”中直接用外层变量给内层 WHERE 赋值，尤其在 WITH 或多层 SELECT 套娃时容易误以为能写 WHERE id = outer_table.id 就行。
使用场景：比如想查每个用户最新一条订单，但又不想用窗口函数或 JOIN 自关联。
- MySQL 8.0+ 推荐用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)配合 CTE，比嵌套更稳 - 如果坚持用嵌套，确保外层字段在子查询的
FROM或JOIN中显式暴露，例如：SELECT u.name, (SELECT order_no FROM orders o WHERE o.user_id = u.id ORDER BY o.id DESC LIMIT 1) AS last_order FROM users u - 避免在子查询里对同一张表做多次非关联扫描，性能会随数据量陡增；加好
(user_id, id)复合索引
PostgreSQL 函数内 RETURN QUERY 嵌套时参数丢失
用 RETURN QUERY EXECUTE 返回动态结果集时，如果 SQL 字符串里需要插变量，不通过 USING 传参，就会报错或返回空——因为字符串拼接后，变量值没进执行上下文。
典型错误：RETURN QUERY EXECUTE 'SELECT * FROM logs WHERE level = ''' || level_param || ''''，既危险又难调试。
- 必须用
USING：RETURN QUERY EXECUTE 'SELECT * FROM logs WHERE level = $1' USING level_param -
$1,$2是占位符，顺序和USING后的参数顺序严格对应，不能写成$2却只传一个参数 - 如果嵌套层级深（比如函数 A 调函数 B，B 再
RETURN QUERY EXECUTE），每层都要自己处理参数传递，不能指望“透传”
所有数据库通用：嵌套过深导致执行计划失效
超过 3 层嵌套（尤其是含聚合、窗口、CTE 和动态 SQL 混用）时，优化器容易放弃生成最优计划，转而用嵌套循环或全表扫描，哪怕有索引也视而不见。
这不是语法错误，是性能雪崩前兆——线上查 10 行可能耗时 5 秒。
- 用
EXPLAIN（或各库对应命令）看实际执行路径，重点盯rows估算值是否远超真实数据量 - 把中间结果物化成临时表（
CREATE TEMP TABLE），加索引，再从临时表查，往往比纯嵌套快几倍 - Oracle/PG 支持
MATERIALIZEDCTE，SQL Server 有OPTION (RECOMPILE)强制重编译计划，但别滥用——它们解决的是缓存计划失准，不是结构问题
变量传值本身不难，难的是传到哪一层、被谁解析、有没有被优化器“看见”。嵌套越深，控制力越弱，调试时得一层层剥开看执行计划，而不是只盯着语法对不对。
