sp_executesql比exec更快因其可复用执行计划，而exec每次拼接字符串都会强制重新编译；postgresql中execute需显式类型转换防绑定失败；mysql的prepare语句名会话级唯一，不可循环重复deallocate；oracle的execute immediate单次绑定上限为1000个参数。
SQL Server 存储过程中 sp_executesql 为什么比 EXEC 更快
因为 sp_executesql 能复用执行计划，而 EXEC（尤其拼接字符串的 EXEC(@sql)）每次都会触发重新编译。SQL Server 对参数化查询识别度高，只要参数类型、数量、顺序一致，就倾向重用缓存计划。
- 用
sp_executesql时，SQL 引擎把查询文本和参数定义分开看待：N'SELECT * FROM users WHERE id = @id'是“模板”，@id INT是契约，匹配即复用 -
EXEC(@sql)把整个字符串当黑盒处理，哪怕只差一个空格或引号位置，都算新语句，强制编译 - 动态条件多时（比如可选的
@status、@start_date），别硬拼WHERE片段，改用IS NULL或CASE配合参数化，否则照样破坏计划复用
PostgreSQL 中写存储过程如何避免 EXECUTE ... USING 的类型陷阱
PostgreSQL 的 EXECUTE 动态执行必须显式声明参数类型，漏写或错写会导致运行时报错 ERROR: there is no parameter $1 或类型不匹配。
- 在
EXECUTE 'SELECT * FROM logs WHERE level = $1' USING v_level;中，v_level必须是明确的TEXT或ENUM类型变量；若它是varchar(10)且值为NULL，可能被推断为unknown，导致绑定失败 - 安全做法：对所有
USING参数加类型转换，比如USING v_level::text，尤其当变量来自IN参数或函数返回值时 - 不要依赖隐式转换——例如把
integer变量传给期望bigint的字段，即使值在范围内，也可能因类型不一致跳过索引
MySQL 存储过程里用 PREPARE + EXECUTE 时，为什么不能在循环里反复 DEALLOCATE PREPARE
因为 PREPARE 语句名是会话级全局标识符，不是局部变量。同一会话中重复 PREPARE stmt_name 会报错 ERROR 1243 (HY000): Unknown prepared statement handler，但更常见的是没及时释放导致内存泄漏或后续执行错乱。
- 正确模式是：一次
PREPARE stmt_name，多次EXECUTE stmt_name USING ...，最后统一DEALLOCATE PREPARE stmt_name - 如果必须在循环中构建不同 SQL（比如批量插入不同表），用唯一命名，如
CONCAT('stmt_', @i)，再配合IF EXISTS检查是否已存在（MySQL 8.0+ 支持DROP PREPARE IF EXISTS） - 注意
PREPARE不支持变量名作为表名/列名——那些必须拼进 SQL 字符串，但拼接部分要严格过滤，否则就是 SQL 注入入口
Oracle PL/SQL 中 EXECUTE IMMEDIATE 绑定参数数量超过 1000 怎么办
Oracle 单次 EXECUTE IMMEDIATE 的 USING 列表上限是 1000 个位置占位符（:b1, :b2, ..., :b1000），超了直接报 ORA-01795: maximum number of expressions in a list is 1000，这不是语法错误，而是硬限制。
- 拆分逻辑：把大数组按每 999 个一组循环执行，别试图一次性塞进去
- 改用临时表：先把参数数据 INSERT 到全局临时表（
ON COMMIT DELETE ROWS），再用IN (SELECT ... FROM temp_table)替代长列表 - 慎用
BULK COLLECT+FORALL：它不走动态 SQL，性能更好，但前提是操作对象固定（比如固定表、固定字段），不能用于表名/列名也动态的场景
参数化不是万能胶，真正卡住性能的往往是没意识到计划缓存失效、类型推断偏差、或把动态当成了唯一解法。留心那几个关键字——sp_executesql、USING、PREPARE、EXECUTE IMMEDIATE——它们各自有脾气，哄好了才肯干活。
