根本原因是PHP驱动层主动开启多语句执行能力，MySQL服务端默认拒绝分号分隔的多语句，而mysqli_multi_query()或未关闭PDO::MYSQL_ATTR_MULTI_STATEMENTS会直接赋予攻击者删库权限。
堆叠查询注入在 MySQL + PHP 环境中危害最大，根本原因不是数据库本身支持分号，而是 PHP 驱动层主动开启了多语句执行能力——只要用了 mysqli_multi_query() 或没关 PDO::MYSQL_ATTR_MULTI_STATEMENTS，攻击者就能从“只读”直接跃迁到“删库跑路”。
MySQL 默认不允许多语句，但 PHP 驱动常默认打开后门
MySQL 服务端默认配置是拒绝分号分隔的多语句（sql_mode 不含 PIPES_AS_CONCAT 之类也不影响这点），真正让堆叠生效的是客户端行为：
-
mysqli_query()遇到分号直接报错：MySQLi SQL syntax error，天然免疫 -
mysqli_multi_query()是唯一默认允许堆叠的函数，且不校验第二条语句是否合法——1; DROP TABLE users;会先查 ID=1 的记录，再无条件执行删表 - PDO 默认禁用多语句，但很多旧项目初始化时显式设了
PDO::MYSQL_ATTR_MULTI_STATEMENTS => true，等于亲手交出钥匙
为什么 PostgreSQL 和 SQL Server 堆叠风险相对低
PostgreSQL 服务端默认就禁止分号分隔多语句，除非显式启用 pg_query() 的多语句模式（PHP 扩展极少这么用）；SQL Server 虽支持 GO 分隔，但 PHP 的 sqlsrv_query() 和 pdo_sqlsrv 都不支持一次传入多条语句——攻击者即使输入 1; DROP TABLE users，驱动只会执行第一条，后续被截断或报错。
换句话说：MySQL 的危险性来自“驱动层宽松 + 应用层误用”的组合，而其他数据库要么服务端硬拦，要么驱动层压根不提供入口。
WAF 过滤分号根本不可靠，绕过方式太多
分号看似简单，但实际防御中几乎拦不住：
- URL 编码：
%3B替代; - 注释混淆：
;/**/DROP/**/TABLE绕过正则匹配 - 非 HTTP 场景直连 DB：CLI 脚本、定时任务、管理后台 API，WAF 完全不覆盖
- 某些 ORM 封装了
mysqli_multi_query()却未暴露开关，开发者根本意识不到自己开了堆叠权限
禁用堆叠后最常被忽略的兼容性断裂点
一旦关闭 mysqli_multi_query() 或设 PDO::MYSQL_ATTR_MULTI_STATEMENTS => false，以下逻辑会直接失败，且错误信息极不友好：
- 安装脚本里用堆叠建表+插入初始数据：
CREATE TABLE ...; INSERT INTO ...;→ 报错但日志只记DB init failed - CMS 初始化流程依赖一次发多条 DDL（如添加索引+修改字段+清空缓存表）→ 中断，但调用栈可能深埋在 vendor 包里
- 某些老版本 Laravel 的
DB::unprepared()在 MySQL 下底层调用了mysqli_multi_query()，升级 PDO 配置后静默失效
这些不是边缘 case，而是真实生产环境中排查数小时才发现是堆叠禁用导致的“连接正常但建库失败”。关键不在怎么关，而在关之前必须扫描所有 executescript、multi_query、unprepared 类调用点。
