ProxySQL 通过 mysql_query_rules + apply_mysql_query_rules 配合 hits 计数器实现 SELECT 查询粗粒度限流，需确保 active=1、apply=1、destination_hostgroup=-1 拒绝，并执行 LOAD/SAVE 命令生效；hits 全局累计，缓存命中不触发，不适用于精确 QPS 控制。
ProxySQL 里怎么配 SELECT 查询限流
ProxySQL 本身不直接支持“每秒最多 N 次 SELECT”，得靠 mysql_query_rules + apply_mysql_query_rules 配合 hits 计数器和 sticky_conn 或自定义变量间接实现，本质是用规则命中频次做粗粒度拦截。
常见错误是以为加个 match_digest 就能限流——其实没配 apply_mysql_query_rules=1 或漏设 active=1，规则压根不生效；还有人把 destination_hostgroup 写错，导致流量绕过规则直接转发。
- 只对明确的
SELECT开头语句生效，SELECT /*+ MAX_EXECUTION_TIME(1000) */这类 hint 不影响规则匹配 -
hits是全局累计值，不是每连接/每用户独立计数，适合防扫描类突发，不适合精确 QPS 控制 - 若同时启用
mysql-query-cache，缓存命中的查询不触发规则，限流会失效
为什么不能只靠 MySQL 自身的 max_connections 或 wait_timeout
这两个参数拦不住 DDoS 式高频小查询：连接数没超，单条查询又很快，wait_timeout 只管空闲连接，max_connections 被耗尽后新连接被拒，但攻击者早把后端打满或拖慢了。
真实场景里，攻击者常用短连接反复执行 SELECT 1 或查某个轻量视图，MySQL 层面看到的是大量合法连接+合法语句，传统连接池或超时设置完全无感。
-
max_connections设太低会影响正常业务伸缩，设太高又失去防护意义 -
wait_timeout缩短会导致健康检查失败、应用连接池频繁重建 - MySQL 8.0+ 的
connection_control插件只针对登录失败限速，对已建立连接内的查询无效
ProxySQL 规则中 match_digest 和 apply 的关键写法
必须用 match_digest 精确匹配 SQL 模式，不能用模糊的 match_pattern（性能差且易误伤），且要确保规则在 mysql_query_rules 表中 active=1 且 apply=1。
示例：限制所有不含 WHERE 的单表 SELECT
INSERT INTO mysql_query_rules (active, match_digest, destination_hostgroup, apply, hits) VALUES (1, '^SELECT [^ ]+ FROM [^ ]+$', -1, 1, 100);
注意：destination_hostgroup = -1 表示拒绝，不是发往某个 hostgroup；hits=100 是该规则被命中 100 次后自动停用（需配合定时任务重置）。
-
match_digest匹配的是归一化后的 SQL，空格/换行/注释全被抹掉，SELECT * FROM t和SELECT\n*\nFROM\nt都匹配成功 - 规则顺序很重要：
rule_id小的先匹配，一旦apply=1就终止后续规则检查 - 别在
match_digest里写正则捕获组，ProxySQL 不支持，写了也不报错但永远不匹配
实际部署时最容易被忽略的三个点
ProxySQL 限流不是开箱即用的功能，配置完不 reload、不监控、不联动，等于没配。
- 改完
mysql_query_rules必须执行LOAD MYSQL QUERY RULES TO RUNTIME，再SAVE MYSQL QUERY RULES TO DISK，否则重启就丢 - 没有持续看
stats.stats_mysql_query_rules表里的hits和cache_hits，就不知道规则是否真在挡流量 - 没把 ProxySQL 的管理端口（默认 6032）加到防火墙白名单，或者没关掉
admin-admin_credentials默认弱密码，反而引入新攻击面
真正的难点不在写几行 SQL，而在判断哪些查询该限、限多狠、怎么和业务方对齐阈值——比如报表系统凌晨跑的 SELECT COUNT(*) 和攻击流量长得一模一样。
