PROCESS权限不写日志但使敏感SQL明文暴露在SHOW PROCESSLIST和performance_schema.threads中，易因应用错误处理导致泄露；REVOKE后用户仍可见自身线程属正常设计；推荐用受限视图替代直接授权。
PROCESS权限本身不写日志，但会让敏感SQL暴露在SHOW PROCESSLIST里
MySQL 的 PROCESS 权限不会直接导致错误日志或慢日志记录敏感 SQL，但它允许用户执行 SHOW PROCESSLIST 或查询 performance_schema.threads，而这两处会明文显示正在运行的 SQL 语句——包括含身份证、手机号、密码字段的 SELECT/UPDATE，甚至带参数值的 WHERE 条件。
一旦应用层错误处理不当（比如把 PROCESSLIST 输出拼进异常日志、监控告警或调试页面），这些 SQL 就会流到外部系统，形成间接泄露链。
哪些场景下PROCESS权限最危险
- 应用后台定时采集线程信息做“慢 SQL 排查”，结果把整条
SELECT * FROM users WHERE id = '12345' AND phone = '138****1234'写进自己的业务日志文件 - 运维脚本用
mysql -e "SHOW PROCESSLIST" | grep -i password检查风险语句，但输出未脱敏且被上传至共享目录 - 前端监控面板调用 API 查询
performance_schema.threads并直接渲染 SQL 文本，未过滤敏感字段名或值 - 低权限账号被钓鱼获取 shell 后，用已有
PROCESS权限连上数据库，手动执行SHOW PROCESSLIST扫描当前活跃查询
REVOKE PROCESS后仍能看到自己线程？这是正常行为
MySQL 默认允许用户查看自己的线程（即 SHOW PROCESSLIST 中只显示本用户发起的连接），无需 PROCESS 权限。所以即使执行了 REVOKE PROCESS ON *.* FROM 'app_user'@'%'，该用户仍能看到自己发的 SQL —— 这不是漏洞，是设计使然。
真正要防的是跨用户窥探。确认回收生效的方法是：
- 用
app_user登录，执行SHOW PROCESSLIST，检查输出是否只含自身连接（User列全为app_user） - 执行
SELECT COUNT(*) FROM performance_schema.threads WHERE PROCESSLIST_USER != 'app_user'，结果应为 0 - 运行
SHOW GRANTS FOR 'app_user'@'%'，确保输出里没有PROCESS
替代方案：用受限视图代替直接授权PROCESS
如果业务真需要“看线程”能力（如排查阻塞），又不想放开 PROCESS，可建一个受限视图，只暴露必要字段且过滤敏感内容：
CREATE VIEW app_processlist AS SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, LEFT(INFO, 200) AS INFO_TRIMMED -- 截断 SQL，避免长查询暴露完整条件 FROM performance_schema.threads WHERE USER = USER();
然后只授予 SELECT 权限给该视图：GRANT SELECT ON mydb.app_processlist TO 'app_user'@'%'。这样既满足可观测性，又切断了跨用户窥探路径。
注意：视图无法隐藏 INFO 字段中已存在的敏感值，所以关键还是得靠应用层避免在 SQL 中拼接明文数据——比如用参数化查询，而不是 CONCAT("WHERE phone = '", user_input, "'")。
