sql参数传递本质是客户端驱动安全嵌入变量的过程，关键在防注入、性能与可读性；须用参数化查询（如jdbc preparedstatement、python占位符、.net命名参数），禁用字符串拼接；大批量需拆分或临时表；存储过程应精确声明类型并慎用动态sql；orm中需区分安全参数化（#{}、fromsqlraw）与危险拼接（${}、$插值）。
SQL 参数传递本身不涉及“机制”层面的复杂设计，它本质是客户端驱动（如 JDBC、ODBC、ADO.NET）将变量安全地嵌入 SQL 语句的过程；真正关键的是如何避免拼接、防止注入、兼顾性能与可读性。
参数化查询：防注入的底线要求
直接字符串拼接 SQL（如 "WHERE name = '" + input + "'"）极易引发 SQL 注入。所有主流数据库驱动均支持命名参数或位置参数：
- JDBC 使用 PreparedStatement，用 ? 占位，调用 setString(1, value) 绑定
- Python 的 sqlite3 或 psycopg2 支持 ?（SQLite）、%s（PostgreSQL） 或 :name（命名）
- .NET 中 SqlCommand 配合 @param 命名参数，自动处理类型与转义
批量操作时的参数复用与分页策略
单条语句传入大量 ID 或条件时，不能无限制追加参数（如 IN (?) 里塞 5000 个值），不同数据库有硬性上限（如 Oracle 1000、SQL Server 约 2100）。实用解法：
- 拆分批量：每 500–1000 个参数为一组，循环执行
- 临时表/CTE：先将 ID 批量写入临时表，再 JOIN 查询（适合超大批量）
- 服务端分页：用 OFFSET-FETCH（SQL Server/PostgreSQL）或 LIMIT-OFFSET（MySQL）替代客户端内存分页
存储过程中参数的类型与默认值设计
存储过程不是“万能胶”，滥用会导致难以调试和缓存失效。优化要点：
- 输入参数尽量声明精确类型（如 VARCHAR(50) 而非 VARCHAR(MAX)），利于执行计划复用
- 可选条件用 NULL 默认值 + WHERE 字段 = ISNULL(@param, 字段)，但注意可能跳过索引；更稳妥写法是动态拼接（在过程内用 IF 判断后拼接 WHERE 片段）或使用 OPTION (RECOMPILE)
- 输出参数仅用于返回简单标量值；复杂结果统一用 SELECT，便于 ORM 映射
ORM 框架中的参数透明性与陷阱
Entity Framework、MyBatis、SQLAlchemy 等封装了参数传递，但开发者仍需警惕隐式行为：
- EF Core 的 FromSqlRaw 必须手动参数化（FromSqlRaw("WHERE id = {0}", id)），不可用 $ 插值
- MyBatis 的 #{} 走预编译，${} 是字符串替换——后者仅限表名/列名等无法参数化的场景，且必须白名单校验
- 启用 EF 的 LogTo 或开启数据库查询日志，确认最终生成的 SQL 是否含参数占位符，而非已展开的值
