根本原因是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 类调用点。