MySQL 中不存在 table_mysql 系统表，实际应严格限制普通用户访问 mysql 库（如 user、db 表），仅授权最小化业务权限，推荐使用角色管理并禁用其对系统库的继承权限。
MySQL 中没有 table_mysql 这个系统表，你可能是指对 MySQL 系统库（如 mysql 库）中的表（例如 user、db、tables_priv 等）进行权限控制，或者误将表名写成了 table_mysql。实际场景中，**直接授予普通用户操作 mysql 系统库表的权限是高危行为，应严格限制**。
明确禁止普通用户访问 mysql 系统库
MySQL 的 mysql 库存储用户、权限、插件等核心元数据，任何误操作都可能导致服务不可用或权限失控。
- 默认情况下，只有
root@localhost或具备SYSTEM_USER+SYSTEM_VARIABLES_ADMIN等高级权限的账号才能安全修改 - 不要用
GRANT ALL ON mysql.* TO 'user'@'%'—— 这等于开放数据库后门 - 若需临时排查，应使用专用运维账号，操作后立即回收权限
按需授予最小化业务权限（非系统表）
对业务数据库中的普通表，应遵循“最小权限原则”，而非开放整个库或系统表。
- 只授权必要操作：例如
GRANT SELECT, INSERT ON mydb.orders TO 'app_user'@'10.20.30.%'; - 避免使用通配符
*在表名位置（如mydb.*），除非确认该库下所有表都可被该用户访问 - 敏感表（如含密码、身份证的表）可单独撤销权限：
REVOKE UPDATE, DELETE ON mydb.users FROM 'app_user'@'%';
用角色（Role）统一管理权限（MySQL 8.0+）
通过角色解耦权限定义与用户绑定，便于审计和批量调整。
- 创建只读角色：
CREATE ROLE 'app_reader'; GRANT SELECT ON mydb.* TO 'app_reader'; - 赋予用户角色：
GRANT 'app_reader' TO 'report_user'@'%'; - 禁用某角色对系统库的继承：
REVOKE ALL ON mysql.* FROM 'app_reader';（确保角色本身不带系统库权限）
验证与加固建议
权限设置后必须验证效果，并启用日志跟踪异常行为。
- 用目标用户登录后执行
SHOW GRANTS;确认实际获得的权限 - 检查是否意外继承了全局权限：
SELECT * FROM mysql.role_edges WHERE TO_HOST = '%'; - 开启审计日志（如 MySQL Enterprise Audit 或 community 版的 general_log / error_log 配合过滤），重点关注对
mysql.user、mysql.db的 DML 操作
