直接限制高成本查询需资源配额、查询重写和运行时拦截三类手段：mysql原生max_queries_per_hour按次数限频，proxysql可拦截无where全表扫描，mysql 8.0+ resource group能限制cpu与并发，而slow_log仅事后审计，无法实时防护。
直接限制高成本查询，靠的是资源配额 + 查询重写 + 运行时拦截三类手段，单靠权限控制或SQL审计根本拦不住——用户有SELECT权限，就能跑SELECT SLEEP(10)、SELECT COUNT(*) FROM huge_table或笛卡尔积。
用MAX_QUERIES_PER_HOUR和MAX_UPDATES_PER_HOUR硬限频次
这是MySQL原生最轻量的防刷手段，不依赖外部组件，但只按“次数”而非“耗时”或“扫描行数”限制，适合防简单轮询或脚本暴力扫表。
-
MAX_QUERIES_PER_HOUR对所有语句（包括SELECT、SHOW）计数，每小时超限后新查询直接报错ERROR 1226 (42000): User 'xxx' has exceeded the 'max_questions' resource -
MAX_UPDATES_PER_HOUR仅统计修改类语句（INSERT/UPDATE/DELETE），对高成本SELECT无效，别误用 - 创建用户时一次性设好：
CREATE USER 'app'@'10.20.%' IDENTIFIED BY 'pwd' WITH MAX_QUERIES_PER_HOUR 300 MAX_CONNECTIONS_PER_HOUR 20; - 已有用户用
ALTER USER调整，改完必须FLUSH PRIVILEGES才生效
用ProxySQL拦截无WHERE的全表扫描和慢查询模式
MySQL自身无法识别“是否带WHERE”，也无法在语句执行前判断它会不会慢；ProxySQL能在SQL到达MySQL前做规则匹配，是目前最实用的运行时过滤方案。
- 规则必须设
active=1且apply=1，否则不生效；destination_hostgroup = -1表示拒绝，不是转发到某个组 - 匹配无条件单表
SELECT：INSERT INTO mysql_query_rules (active, match_digest, destination_hostgroup, apply) VALUES (1, '^SELECT [^ ]+ FROM [^ ]+$', -1, 1); - 匹配明显低效模式，如
SELECT * FROM table ORDER BY RAND()或SELECT ... LIKE '%keyword%'，需单独写规则 - 注意：
match_digest基于归一化SQL（空格/换行/注释全抹掉），不能用LIKE模糊匹配；缓存命中的查询不触发规则
用MySQL 8.0+的resource_group限制CPU和并发
这是真正能卡住高成本查询执行资源的方式，但要求MySQL 8.0.19+且必须启用RESOURCE_GROUP_ADMIN权限，普通账号默认没这权限。
- 先建资源组：
CREATE RESOURCE GROUP rg_low TYPE=USER VCPU=(0-1) THREAD_PRIORITY=19;（限制最多用1个逻辑核，优先级拉最低） - 把用户绑定到组：
ALTER USER 'app'@'%' RESOURCE GROUP rg_low; - 效果：该用户发起的查询即使扫描千万行，也会被系统强制降频调度，不会拖垮整个实例
- 陷阱：若用户有
SUPER或RESOURCE_GROUP_ADMIN权限，可自行切换资源组绕过限制；务必确保其权限中不含这两项
为什么不要依赖long_query_time或slow_log事后审计
慢日志只记录已执行完的慢查询，属于“马后炮”；攻击者用大量SELECT SLEEP(0.5)或小结果集但高IO的GROUP BY，可能永远不进慢日志，却能把磁盘IOPS打满。
-
long_query_time = 1只捕获执行超1秒的查询，而SELECT COUNT(*) FROM t WHERE id > 0在索引覆盖下可能0.2秒跑完，但每秒跑10次照样压垮连接池 - 开启
log_queries_not_using_indexes会误伤正常业务（比如分页查最后一页），且不解决“有索引但写法差”的问题（如函数索引未命中） - 真正要防的是“单位时间内的资源消耗总量”，不是单条语句快慢——这只能靠ProxySQL规则或resource group实现
最容易被忽略的是：resource group绑定对已存在的连接不生效，只对新连接起作用；如果应用用长连接池，得滚动重启或等连接自然断开才能落地。别测完就以为万事大吉。
