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() 这一条路，并在代码层做静态扫描验证。
