撤销PROCESS权限可防敏感信息进错误日志，因无该权限时SHOW PROCESSLIST仅返回当前会话线程，不暴露他人明文SQL；但需注意账号粒度、验证回收及禁用SUPER权限。
为什么撤销PROCESS权限能防敏感信息进错误日志
MySQL 错误日志本身不记录 SQL 语句或用户数据，但应用层常把 SHOW PROCESSLIST 的输出当调试上下文拼进日志——一旦该命令返回了其他连接的明文 SQL（比如 SELECT password FROM users WHERE id = 123），整个敏感查询就进了 error log。PROCESS 权限是触发这个链条的前提，没它，SHOW PROCESSLIST 只返回当前会话自己的线程，不带他人 SQL。
如何安全回收 PROCESS 权限
直接执行 REVOKE PROCESS ON *.* FROM 'app_user'@'%' 即可；但要注意三点：
- 必须对每个具体账号操作，
'app_user'@'localhost'和'app_user'@'%'是两个独立账户，需分别处理 - 回收后立即用
SHOW GRANTS FOR 'app_user'@'%'验证，确认输出里不再出现PROCESS - 若账号有
SUPER权限，它可绕过限制重新启用 PROCESS，所以必须同步检查并禁用SUPER
哪些场景下 PROCESS 权限仍可能被间接利用
即使显式收回了 PROCESS，以下情况仍可能导致敏感信息暴露：
- 监控脚本以 DBA 账号运行
SHOW PROCESSLIST，再把结果写入应用日志文件（而非 MySQL error log），而该日志被统一收集到 ELK 或 S3 —— 这属于日志配置越界，和 MySQL 权限无关 - 应用使用
performance_schema.threads表查线程信息，该表默认所有用户可读（除非显式REVOKE SELECT ON performance_schema.threads FROM ...） - MySQL 8.0+ 开启了
log_error_verbosity = 4，此时部分内部错误会附带线程堆栈，含 SQL 片段 —— 这和 PROCESS 无关，但效果类似，需设为 ≤ 3
PROCESS 权限与监控、运维的真实取舍
运维账号确实需要 PROCESS，但不能和应用账号混用。建议：
- 建专用监控账号，如
'monitor'@'192.168.1.%'，只授PROCESS和SELECTonperformance_schema，不给任何业务库权限 - 禁止在应用代码里调用
SHOW PROCESSLIST；改用information_schema.PROCESSLIST（仅返回当前会话）或直接查performance_schema.threads并加WHERE PROCESSLIST_ID = CONNECTION_ID() - 如果用 Prometheus + mysqld_exporter，确保 exporter 使用的是监控账号，且其抓取间隔足够长（如 30s），避免高频查询放大风险
真正难控的不是权限开关本身，而是应用层对“线程信息”的误用习惯——哪怕权限收得再紧，只要代码里还留着 log.info("Current processlist: " + resultSet.toString())，泄露风险就还在。
