SQL 参数传递本身不涉及“传值”或“传引用”的传统编程概念，而是由数据库驱动和执行引擎共同决定的参数绑定行为。关键在于：参数值在预编译阶段被安全封装，不参与 SQL 文本拼接，从而杜绝注入风险，并由数据库按类型隐式或显式转换后参与执行计划。
参数化查询如何真正防止 SQL 注入
根本原因不是“参数被转义”，而是参数值完全脱离 SQL 语法解析流程。数据库收到的是已编译的语句模板（如 SELECT * FROM users WHERE id = ?）和独立的数据值，二者在执行时才结合，值不会被当作 SQL 代码解析。
- 即使传入 ' OR 1=1 --，它只会被当作字符串字面量匹配字段内容，不会改变查询逻辑
- 数据库驱动通常会对参数做类型校验（如 int 参数传入字符串会报错），进一步隔离语义
- 不同数据库对空值、NULL、二进制数据的支持方式不同，需依赖驱动正确序列化
各数据库常见的参数占位符与绑定规则
占位符形式由数据库协议和驱动约定，不统一，但语义一致：代表一个待绑定的、类型受限的位置。
- MySQL（Connector/J、mysql2）： 使用 ?，按位置顺序绑定；支持命名参数需开启 useServerPrepStmts=true
- PostgreSQL（pg、psycopg2）： 支持 $1, $2（位置）和 :name 或 %{name}（命名），后者需驱动层映射
- SQL Server（mssql、pyodbc）： 用 @param（命名）或 ?（位置），命名参数更易维护复杂语句
- Oracle（cx_Oracle）： 支持 :param 和 :1，注意绑定变量名不能含特殊字符或数字开头
实际开发中容易踩的坑
参数机制看似简单，但在动态条件、批量操作、NULL 处理等场景下容易误用。
- IN 列表不能直接参数化： WHERE id IN (?) 只能匹配单个值；需根据元素数量动态生成 IN (?, ?, ?) 占位符，再逐一绑定
- 列名/表名无法参数化： 参数只适用于数据值，结构信息（如 ORDER BY col、INSERT INTO table）必须通过白名单校验+字符串拼接实现
- NULL 值需显式传递： 传 None（Python）、null（Java）或 DBNull.Value（C#），不能传字符串 'NULL'
- 日期时间类型注意时区： JDBC 默认可能转为本地时区，建议使用 TIMESTAMP WITH TIME ZONE 类型或显式指定时区绑定
高性能批量操作的参数实践
批量插入/更新应避免循环单条参数化语句，而要利用数据库原生批量绑定能力。
- 使用 executeMany()（Python DB-API）、addBatch()（JDBC）等接口，一次提交多组参数
- PostgreSQL 支持 UNNEST(ARRAY[...], ARRAY[...]) 配合参数数组，减少网络往返
- SQL Server 的 SqlBulkCopy 或 PostgreSQL 的 COPY 命令绕过参数机制，适合百万级导入，但需额外权限和格式控制
