MySQL Enterprise Firewall对应用层SQL注入无效，因其工作在SQL解析后阶段，仅对已认证连接的语句做白名单过滤，无法干预应用拼接SQL的源头过程，真正的防护必须在应用层使用预处理语句或ORM参数化。
MySQL Enterprise Firewall 插件不能抵御应用层 SQL 注入——它只对已认证连接的 SQL 语句做白名单过滤，而注入行为本身发生在应用拼接 SQL 阶段，防火墙根本看不到原始输入。
为什么 mysql_firewall 插件对应用层注入无效
插件工作在 MySQL Server 内部、SQL 解析之后，它看到的是已经由应用传入并解析完成的语句（如 SELECT * FROM users WHERE id = 1 OR 1=1），而非用户原始输入（如 id=1 OR 1=1）。这意味着：
- 它无法区分这是合法模糊搜索还是恶意注入，只要语句语法合法且匹配白名单就放行
- 所有绕过应用参数化的直连行为（如 DBA 用命令行、运维脚本、测试工具连库执行）都会被它监控，但真实攻击者通常不走这条路
- 它完全不干预预处理语句的参数绑定过程，而真正的防护恰恰发生在这个环节
mysql_firewall 的实际适用场景和配置要点
它适合用于“已知应用行为稳定、需防止内部人员或第三方组件越权执行非预期 SQL”的场景，比如限制报表系统只能跑 SELECT、禁止运维账号执行 DROP TABLE。启用前必须确认：
- 你使用的是 MySQL 企业版，社区版无此插件
- 插件已安装：
INSTALL PLUGIN mysql_firewall SONAME 'mysql_firewall.so'，且SHOW PLUGINS中可见mysql_firewall - 目标用户已创建，并通过
CALL mysql.sp_set_firewall_mode('user@host', 'RECORDING')启动学习模式——此时所有该用户的语句会被记录进mysql.firewall_whitelist - 切换到
PROTECTION模式前，必须人工审核白名单，否则1=1类测试语句也会被当作合法流量固化
真正防应用层注入，必须在应用代码里做
所谓“防注入”，本质是阻止用户输入参与 SQL 语法构建。数据库侧的任何机制都只是补丁，不是根治手段。关键动作包括：
- PHP 中强制使用
PDO::prepare()或mysqli_prepare()，参数一律走bindValue()或bind_param()，绝不拼接字符串 - ORM 如 Laravel Eloquent 默认安全，但调用
whereRaw()、DB::select()等原生接口时，必须手动参数化 - 数字类字段别依赖
(int)$id，改用filter_var($id, FILTER_VALIDATE_INT)配合绑定，避免科学计数法绕过 - 动态字段名（如
ORDER BY ?）无法参数化，必须用白名单校验：in_array($input, ['created_at', 'status'], true)
最常被忽略的一点：mysql_firewall 插件已在 MySQL 9.7 中被标记为 deprecated，官方明确要求迁移到 firewall component；而无论插件还是组件，都不解决应用拼接 SQL 这个源头问题——它只管“谁说了什么”，不管“这句话是怎么造出来的”。
