禁用多语句执行能从根本上阻断堆叠注入，因其依赖mysqli_multi_query或PDO::MYSQL_ATTR_MULTI_STATEMENTS等驱动层支持，而WAF过滤分号可被编码绕过，唯有在连接初始化时禁用才彻底消除执行基础。
堆叠查询能执行 DROP/INSERT/UPDATE 等写操作
普通 SQL 注入（如 UNION 或盲注）通常只能读取数据，而堆叠查询允许在一次请求中执行多条语句，比如 '; DROP TABLE users; -- 或 '; INSERT INTO admins VALUES ('hacker', 'pwd'); --。只要后端用了 mysqli_multi_query()、PDO::MYSQL_ATTR_MULTI_STATEMENTS = true 这类支持多语句的驱动配置，数据库就会顺序执行——先查，再删，再插，完全不受应用层逻辑约束。
MySQL 默认不启用多语句，但 PHP 驱动常被误配
MySQL 服务本身默认只接受单条语句，真正打开堆叠大门的是客户端驱动的行为：
-
mysqli_query()遇到分号直接报错：MySQLi SQL syntax error -
mysqli_multi_query()是唯一默认允许堆叠的函数，且不校验第二条语句合法性 - PDO 默认禁用多语句，但若显式设置
PDO::MYSQL_ATTR_MULTI_STATEMENTS => true，风险立刻回归
很多旧项目初始化 PDO 时没关这个 flag，或直接用 mysqli_multi_query() 做批量操作，结果把注入入口从“只读”升级成“可写可删”。
WAF 和输入过滤根本拦不住堆叠查询
分号（;）看似容易拦截，但攻击者有太多绕过方式：
- URL 编码：
%3B替代; - 空格混淆：
;/**/DROP/**/TABLE - 非 HTTP 接口直连 DB：CLI 脚本、定时任务、管理后台 API，WAF 完全不覆盖
真正有效的防线是连接建立那一刻就掐断能力——不是过滤输入，而是让驱动根本不具备执行多语句的权限。
修复后容易忽略的兼容性问题
禁用 mysqli_multi_query() 或关闭 PDO::MYSQL_ATTR_MULTI_STATEMENTS 后，部分旧逻辑会直接崩溃，而不是静默降级：
- 安装脚本里用堆叠建表+插入初始数据 → 报错：
Cannot execute queries while other unbuffered queries are active - CMS 初始化流程依赖一次发多条 DDL → 失败，但日志里可能只记“DB init failed”，不提示具体原因
这类调用往往不在主业务链路，排查时容易被当成环境问题跳过，实际却是堆叠禁用后的必然表现。
