MySQL无“慢查询执行权限”概念，slow_query_log由服务端自动判定记录，与用户权限无关；控制重点应是MAX_QUERIES_PER_HOUR等资源限制及max_rows、元数据访问权限等实际约束手段。
MySQL 本身没有“慢查询执行权限”这个概念——slow_query_log 是服务端全局或会话级的记录开关，不是用户可操作的权限项。用户无法主动“执行慢查询”，只能发出查询语句；是否被记录为慢查询，取决于语句实际执行时间是否超过 long_query_time，以及日志开关状态。真正能对用户施加约束的，是资源限制类参数，比如查询频次、连接数、单次查询最大行数等。
为什么不能靠 GRANT/REVOKE 控制慢查询行为
慢查询日志由 MySQL Server 自动判断并写入，不依赖用户权限。只要用户有 SELECT 权限，就能执行任意复杂度的查询（哪怕耗时 60 秒），只要没超 long_query_time 就不会记日志；反之，一个简单查询若因锁等待或 IO 延迟超时，也会被记录。所以：
-
GRANT和REVOKE对slow_query_log开关、long_query_time值完全无效 - 用户无法通过 SQL 启用/禁用自己的慢查记录（
SET SESSION slow_query_log = 1会被拒绝，该变量只读） - 试图用权限控制“谁可以触发慢查”属于方向错误——应该控制“谁可以发起高成本查询”
用 MAX_QUERIES_PER_HOUR 限制高频低效查询
这是最贴近需求的实操手段：防止用户通过反复执行中等耗时查询（如 8 秒的 JOIN）制造大量慢日志，或试探性扫描。它不看单次耗时，而看单位时间内的查询总数。
- 对已有用户设置：
ALTER USER 'report_user'@'%' WITH MAX_QUERIES_PER_HOUR 300; - 新建用户时直接指定：
CREATE USER 'report_user'@'%' IDENTIFIED BY 'pwd' WITH MAX_QUERIES_PER_HOUR 300; - 该限制作用于所有语句（包括
SELECT、SHOW等），但不包含空闲连接、网络心跳包 - 注意：它不阻止单条慢查询，只防“积少成多”；若用户只发 1 条 20 秒查询，仍会被记入慢日志
- 需配合
FLUSH PRIVILEGES（仅当直接改系统表时才需要；ALTER USER通常自动生效）
用 max_rows + application-level timeout 双重兜底
虽然 max_rows 不是权限，但它是会话级硬限制，能有效阻断全表扫描类慢查询的执行完成。
- 在应用连接池初始化时执行：
SET SESSION max_rows = 5000; - 该设置会让超出行数的
SELECT直接报错ERROR 1105 (HY000): Query execution was interrupted, maximum number of rows reached - 必须搭配应用层 query timeout（如 JDBC 的
socketTimeout），否则长事务或锁等待仍可能卡住连接 - 注意：
max_rows不影响INSERT/UPDATE/DELETE，也不限制子查询内部扫描行数 - 验证方式：用目标用户登录后执行
SELECT * FROM big_table;，确认是否截断
真正要盯住的其实是 INFORMATION_SCHEMA 和 performance_schema 访问
很多“伪慢查询”源于用户主动查元数据表来探测结构、索引、锁状态，这类操作本身快，但暴露意图且常被忽略。
- 撤销元库访问：
REVOKE SELECT ON `INFORMATION_SCHEMA`.* FROM 'report_user'@'%';（MySQL 8.0.12+ 支持） - 检查是否残留
PROCESS权限：SHOW GRANTS FOR 'report_user'@'%';—— 若含PROCESS，用户能执行SHOW PROCESSLIST看到别人正在跑什么 SQL - 禁止跨库可见性：
REVOKE SHOW DATABASES ON *.* FROM 'report_user'@'%';，否则即使没权限，也能看到库名列表 - 这些操作比纠结“慢查询权限”更关键：它们堵住了用户主动制造慢查的路径和动机
资源限制参数（如 MAX_QUERIES_PER_HOUR）生效的前提是用户连接重连——旧连接不受新限制影响。别只改配置就以为万事大吉，得让应用重建连接或等连接池自然轮换。
