不能直接用GRANT授“看慢日志”权限，因慢查询日志非数据库对象；即使启用log_output=TABLE并建mysql.slow_log表，GRANT SELECT也仅半解：表需严格按官方DDL创建，且MyISAM锁表、数据未脱敏、精度不一致；推荐OS层授权：开放日志文件路径，配用户组与logrotate。
不能直接用 GRANT 给开发人员授“看慢日志”的权限——因为慢查询日志不是数据库对象，MySQL 的权限系统管不了它。
为什么 GRANT SELECT ON mysql.slow_log 不可靠
即使你启用了 log_output = TABLE 并手动建了 mysql.slow_log 表，GRANT SELECT ON mysql.slow_log TO 'dev'@'%' 也只解决一半问题：
- 该表默认不存在，必须按 MySQL 5.7 官方 DDL 严格创建（字段名、类型、引擎都得对），少一个
COMMENT或错一个TIMESTAMP类型，INSERT就会失败，日志不写入 -
mysql.slow_log是MyISAM表，高并发写入时锁表严重，可能拖慢主库响应 - 开发人员查到的是一堆原始 SQL 文本，包含未脱敏的参数值（如
WHERE user_id = 12345）、密码字段更新、敏感业务逻辑，审计风险极高 - 该表内容和
FILE模式不完全一致：比如Lock_time在表中是整数秒，文件里是微秒精度
推荐做法：把日志文件路径开放给开发组（OS 层控制）
这是生产环境最可控、最轻量、最易审计的方式。核心是让开发人员以普通 Linux 用户身份读文件，而非通过 MySQL 协议查表：
- 确保
slow_query_log_file = /var/log/mysql/mysql-slow.log是绝对路径，且已在my.cnf中配置并重启生效 - 执行：
sudo chown :devgrp /var/log/mysql/ && sudo chmod 750 /var/log/mysql/（假设开发组名为devgrp） - 把开发账号加进该组：
sudo usermod -aG devgrp devuser - 开发人员即可执行：
tail -f /var/log/mysql/mysql-slow.log或用pt-query-digest /var/log/mysql/mysql-slow.log分析 - 后续配合
logrotate配置自动归档与权限继承，避免日志无限增长或权限丢失
必须避开的三个坑
这些操作看似省事，实则埋雷：
- 别设
long_query_time = 0—— 开发临时调试可以，但忘记改回去会导致日志每秒数百行，磁盘 IO 扛不住，还可能触发open_files_limit耗尽 - 别把日志放在
/tmp或 NFS 挂载点 —— 前者可能被系统清理，后者在锁等待时会让慢查询本身变卡，甚至引发连接超时 - 别依赖
SET GLOBAL slow_query_log = ON代替配置文件重启 —— 这个设置对已存在的连接无效，且服务重启后丢失，开发会误以为“开了却没日志”
真正安全的授权，是把权限边界划在操作系统层，而不是绕过它去拼凑数据库权限。文件路径 + 用户组 + logrotate，三者配齐，比任何 GRANT 都干净利落。
