MySQL不支持按预处理语句内容做白名单限制，因服务端收到的已是绑定参数后的完整SQL，无法追溯来源；可行方案是用rewrite_rules插件在parser阶段按文本模式匹配，或采用最小权限账号、限定连接源、强制TLS、启用审计日志等组合策略。

MySQL 不支持按预处理语句内容做白名单限制

MySQL 原生没有机制能识别、校验或放行“某条 PDO::prepare() 绑定后的具体 SQL”——因为预处理语句在客户端完成拼接和参数绑定，发给服务端时已是完整、合法的语句（如 SELECT * FROM users WHERE id = ? 已被替换为 SELECT * FROM users WHERE id = 123）。服务端看到的只是最终执行的 SQL 字符串，无法追溯它是否来自预处理、来自哪个应用、用了哪个占位符。

真正可控的拦截点只有 parser 阶段的原始语句匹配

如果你的目标是“只允许某几类操作”，唯一可行路径是用 rewrite_rules 插件，在语句刚进入 parser 时做模式匹配。但它不区分预处理与否，只看文本特征：

• 规则必须写宽松 pattern，比如 'SELECT FROM orders%' 或 'INSERT INTO log_%'，不能依赖 ? 占位符（因为占位符早被替换了）
• 匹配是大小写不敏感的，但不支持正则；% 匹配任意字符，_ 匹配单字符
• 必须指定 pattern_database，且客户端连接时 USE myapp_db 或带库名前缀，否则不触发
• 生效需调用 query_rewrite.flush_rewrite_rules()，否则插入规则也不起作用

为什么 mysql_firewall 插件也不适合这个场景

mysql_firewall 插件虽能建白名单，但它记录的是“已解析并执行过的语句文本”，不是预处理模板。这意味着：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 同一段 PHP 代码执行 WHERE status = ?，传入 'active' 和 'pending'，会生成两条不同白名单项，维护成本爆炸
• 它对 PREPARE/EXECUTE 动态语句完全无效——这类语句绕过白名单学习逻辑
• MySQL 9.7 已将该插件标记为 deprecated，官方明确要求迁移到新机制（尚未公开细节）
• 它只存在于企业版，社区版用户直接排除

实际能落地的权限+行为控制组合

与其试图锁定“预处理语句内容”，不如收缩执行上下文本身：

• 用最小权限账号：只授目标表的 SELECT、INSERT 等具体 DML 权限，禁用 FILE、PROCESS、SUPER、SHOW DATABASES
• 限制连接来源：CREATE USER 'ext_app'@'10.30.5.%'，而非 '%' ，配合防火墙策略
• 强制 TLS 加密：REQUIRE X509 或 REQUIRE SSL，防止中间人篡改连接后发送非预期语句
• 启用审计日志：audit_log 插件，记录所有执行语句，用于事后回溯——虽然不防攻击，但能快速定位越权行为

最常被忽略的一点：所谓“限制预处理语句”，本质是信任应用层不拼接 SQL。一旦应用出 bug 或被攻破，任何数据库侧白名单都形同虚设。真正在意安全，就得让应用只走 PDO::prepare() + bindValue() 这一条路，并在代码层做静态扫描验证。