参数化查询能防SQL注入是因为将数据与SQL结构分离，数据库先编译语句骨架再填入参数，使恶意输入仅作字面量处理；但表名、列名、ORDER BY等不可参数化，须用白名单校验，且需配合最小权限原则。
MySQL参数化查询为什么能防SQL注入
因为参数化查询把「数据」和「SQL结构」彻底分开，数据库引擎先编译语句骨架，再把参数当纯值填入——哪怕你传入 ' OR 1=1 -- ，它也只会被当作字符串字面量处理，不会参与语法解析。
常见错误现象：用字符串拼接构造SQL，比如 PHP 里写 "SELECT * FROM users WHERE id = " . $_GET['id']，攻击者传 id=1 OR 1=1 就直接绕过条件；Node.js 用 mysql.format() 但没加类型校验，照样可能出问题。
- 所有主流驱动都支持参数化：PHP 的
mysqli::prepare()、Python 的cursor.execute()（带%s或?占位符）、Node.js 的mysql2库的query(sql, params) - 占位符不能用于表名、列名、排序方向（
ASC/DESC）——这些必须走白名单校验或硬编码 - MySQL 服务端预处理（
PREPARE+EXECUTE）在低版本有性能开销，但现代驱动基本都做客户端模拟，无需担心
哪些地方最容易漏掉参数化
权限提升往往发生在「看似安全」的动态查询里，比如后台接口根据角色拼接 WHERE 条件，或导出功能按用户传参决定字段别名。
典型场景：SELECT name, email FROM users WHERE status = ? AND role IN (?) —— 这里 role IN (?) 是错的，? 只能代入单个值，不能展开为多个值列表。
- IN 子句必须动态生成对应数量的
?，比如 Python 用','.join(['%s'] * len(roles))拼占位符串，再传roles列表 - ORDER BY 字段名不能参数化，得用白名单：比如只允许
['created_at', 'name', 'score']，收到sort=score才拼ORDER BY score - LIKE 模糊匹配要小心通配符位置：用
WHERE name LIKE CONCAT('%', ?, '%')，而不是把%拼进参数值里（否则用户传%' OR '1'='1又绕过了）
参数化 ≠ 绝对安全：权限控制仍需独立加固
即使 SQL 完全参数化，如果数据库账号本身有高权限（比如能读 mysql.user 表），攻击者通过正常查询也能拖库或提权。
错误认知：“用了 prepare 就不用管账号权限了”。实际上，SELECT 注入成功后，如果账号能查系统表，就能拿到哈希、甚至执行 SELECT LOAD_FILE('/etc/passwd')（取决于 secure_file_priv 配置）。
- 应用数据库账号应遵循最小权限原则：只给所需库的
SELECT/INSERT/UPDATE，禁用FILE、PROCESS、SUPER等管理权限 - 避免在应用配置里写 root 密码；生产环境用专用账号，比如
app_rw@'10.0.1.%'，限制来源 IP - MySQL 8.0+ 支持角色（
CREATE ROLE），可把权限打包分配，比直接授予权限更易审计
参数化查询是防注入的第一道铁闸，但它的有效性完全依赖你是否真正在每一处动态拼接的地方都用上了——尤其是那些带 IN、ORDER BY、LIMIT 偏移量的地方，最容易被当成“小问题”跳过。
