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 操作
