数据库代理中间件能提供比应用层更强的sql过滤能力，因其在mysql协议解析完成后介入，基于语义级ast节点或digest进行精准拦截，支持上下文感知、白名单校验及高危模板匹配，是绕过应用层参数化的最后一道结构化防线。
分布式数据库中间件（如 ProxySQL、ShardingSphere、MyCat）本身不执行业务逻辑，但它是 SQL 请求的必经之路——这恰恰让它成为拦截高危 SQL 的合理位置，前提是拦截逻辑基于语义解析，而非字符串清洗。
中间件拦截不是替代参数化查询，而是补位防御
应用层用了 prepareStatement 或 query + 参数绑定，不代表 SQL 就绝对安全。现实里总存在绕过：ORM 的 raw() 调用、动态拼接的报表 SQL、遗留系统直连、CLI 导入脚本、异步任务里的手写 SQL。这些请求跳过了应用层的参数化校验，但依然会流经中间件。
- 中间件拦截是“最后一道结构化防线”，针对的是已解析、未执行的 SQL 抽象语法树（AST）或 digest
- 它不处理原始 HTTP 参数，也不碰
QueryString，只对已由 MySQL 协议 parser 解析出的 token 类型做判断（比如确认ORDER BY后面确实是列名，且在白名单内） - 一旦发现
UNION SELECT+ 敏感表名组合，或digest匹配已知攻击模板，可直接拒绝或重写
为什么不能在中间件里对 URL 参数做“过滤”？
这是最常被混淆的点：QueryString 里的 id=1%27%20OR%201%3D1 是合法编码，中间件 decode 后得到 id=' OR 1=1，但这串字符本身不是 SQL，只有拼进查询时才危险。你在中间件里删掉单引号，可能把用户搜索词 O'Reilly 变成 OReilly；你拦 UNION，攻击者改用 unIoN 或 Base64 编码就绕过。
- URL 参数用途千差万别：可能是数字 ID、JSON 字符串、Base64 图片、带引号的搜索词——没有统一清洗规则
- 中间件看不到参数最终怎么用：同一个
sort参数，在用户列表接口是排序字段，在日志接口可能是模糊匹配关键词 - 真正该拦的，是最终生成的那条 SQL 中非法的结构，比如
WHERE子句里出现子查询嵌套超过 3 层，或SELECT列中包含@@version
ProxySQL 的 query rule 怎么做到精准拦截？
ProxySQL 在 mysql_query_processor 阶段介入，此时 SQL 已完成词法分析和语法校验，token 类型明确。它不靠正则匹配原始字符串，而是基于 digest 或已识别的语法单元做决策：
-
match_digest匹配标准化后的 SQL 摘要（忽略空格、大小写、参数值），例如所有SELECT * FROM users WHERE id = ?归为同一 digest -
match_pattern只用于已知上下文，比如限定在ORDER BY后的 token 必须是name、created_at、status - 支持重写
IN (?, ?, ?)为固定长度占位符，避免应用层传入超长数组导致性能抖动
这种能力在应用层很难统一实现——每个服务语言、ORM、驱动对预编译的支持粒度不同，而 ProxySQL 对所有客户端一视同仁。
容易被忽略的关键点
中间件拦截有效性的前提是：它必须运行在 SQL 解析之后、执行之前；且规则配置需随业务演进持续更新。一个静态的黑名单规则集，哪怕放在 ProxySQL 里，也会迅速失效。真正起作用的，是结合业务语义的白名单策略（如只允许 SELECT 查特定视图、禁止跨库 JOIN）、以及对异常 pattern 的主动识别（如单次查询返回行数 > 10000）。这需要 DBA 和后端工程师共同维护，而不是部署完就不管。
