普通用户执行SHOW PROCESSLIST只能看到自己连接，是因为MySQL权限模型强制限制：未授予PROCESS ON .全局权限时，系统自动过滤其他用户会话；该权限不可指定数据库，授完需FLUSH PRIVILEGES并重新登录。
普通用户执行SHOW PROCESSLIST只能看到自己连接的原因
MySQL默认限制非特权用户仅能查看自身会话，这是权限模型的硬性设计。哪怕你有SELECT权限、甚至能查information_schema.processlist表，只要没PROCESS权限，返回结果就自动过滤掉其他用户的行。这不是bug，是安全机制。
GRANT PROCESS ON *.* 是唯一正确写法
常见错误是把PROCESS当成数据库级权限，写成GRANT PROCESS ON mydb.* TO 'user'@'localhost'，这会直接报错ERROR 1221 (HY000): Incorrect usage of DB GRANT and GLOBAL PRIVILEGES。
-
PROCESS是全局权限（Global Privilege），只接受ON *.*语法 - host部分可以是
'localhost'或'192.168.1.%'，但权限范围仍是实例级 - 授完必须执行
FLUSH PRIVILEGES，否则不生效 - 目标用户需退出重连，旧连接不会自动获得新权限
验证PROCESS权限是否生效的实操方式
用被授权用户登录后，运行以下命令观察输出差异：
- 执行
SHOW PROCESSLIST：若能看到User列为root、admin等非当前用户名的行，说明成功 - 执行
SHOW FULL PROCESSLIST：避免Info字段被截断（默认只显示前100字符） - 执行
SELECT * FROM information_schema.PROCESSLIST：结果应与SHOW PROCESSLIST一致 - 执行
SHOW GRANTS FOR 'user'@'localhost'：确认输出中明确包含PROCESS ON *.*
为什么不用performance_schema.threads替代
虽然performance_schema.threads也能查线程信息，且性能开销更小，但它默认对普通用户不可见：
- 访问
performance_schema需要SELECT权限，且该库本身默认不开放给非super用户 - 即使显式授权，
threads表里PROCESSLIST_INFO列仍为空，除非用户有PROCESS权限 - 真正能绕过
PROCESS限制的只有root或拥有SUPER/CONNECTION_ADMIN（MySQL 8.0+）的账号
所以，想让监控脚本或DBA工具稳定获取全量连接信息，PROCESS ON *.*仍是绕不开的最小必要权限——但务必控制host范围、禁用%通配，且绝不和应用账号混用。
