如何分配权限允许用户优化和修复表_维护操作权限的专项授权-phpMyAdmin-PHP中文网

optimize table需alter+index权限，repair table需单独授予且仅适用于myisam；权限须在库级（如myapp_db.*）授予，并执行flush privileges生效。

grant optimize table 和 repair table 权限到底要给谁？

只有 alter 权限不够，mysql 8.0+ 默认关闭 repair table，且这两个操作需要显式授予，不是 dba 或 root 就别硬试。

真实场景里，运维脚本或监控告警触发的自动修复常卡在这儿：用户报错 ERROR 1142 (42000): REPAIR command denied to user，但查了权限表发现 ALTER 已开——漏了专项授权。

OPTIMIZE TABLE 需要 ALTER + INDEX 权限（注意：不是只靠 ALTER）
REPAIR TABLE 在 MySQL 8.0+ 必须单独授 REPAIR TABLE 权限，且仅对 MyISAM 表有效（InnoDB 不支持）
权限必须在具体库表级授予，GRANT ... ON *.* 是全局，GRANT ... ON db_name.* 才能覆盖目标库

怎么用 GRANT 命令精准授权？

别直接 GRANT ALL PRIVILEGES，最小权限原则在这里特别实在：开了 FILE 或 SHUTDOWN 可能引发越权风险。

正确写法是分步、限定范围：

优化表：GRANT ALTER, INDEX ON `myapp_db`.* TO 'maint_user'@'10.20.%';
修复表（仅 MyISAM）：GRANT REPAIR TABLE ON `myapp_db`.* TO 'maint_user'@'10.20.%';
执行后必须 FLUSH PRIVILEGES;，否则权限不生效（尤其在非动态加载配置的旧版本上）

为什么 OPTIMIZE TABLE 有时还是被拒绝？

常见于使用 Percona Server 或 MariaDB 的环境：它们可能启用 skip_optimize_table 或强制要求 PROCESS 权限配合，但 MySQL 官方版不需要。

排查要点：

检查是否启用了 --skip-optimize-table 启动参数（SELECT @@skip_optimize_table; 返回 ON 就是关了）
确认表引擎：SHOW CREATE TABLE mytable; —— 如果是 InnoDB，OPTIMIZE TABLE 实际触发的是 ALTER TABLE ... FORCE，仍依赖 ALTER + INDEX
用户 host 匹配是否精确？'maint_user'@'10.20.%' 和 'maint_user'@'%' 是不同账号，权限不互通

REPAIR TABLE 在现代 MySQL 中还有必要开吗？

基本没必要，除非你还在用 MyISAM 且无法迁移。MySQL 5.7 起默认禁用 REPAIR TABLE，8.0+ 更是彻底移除了对它的支持（除兼容模式外），错误信息会变成 ERROR 1290 (HY000): The MySQL server is running with the --skip-replica-start option so it cannot execute this statement 这类误导性提示。

替代方案更可靠：

MyISAM 表损坏 → 用 myisamchk 命令行工具离线修复（需停服务或锁表）
InnoDB 表异常 → 优先检查 innodb_force_recovery 和 redo log 状态，而不是幻想 REPAIR TABLE 能起作用
自动化维护脚本里，建议直接抛出明确错误：“REPAIR TABLE not supported on InnoDB”，避免静默失败

真正容易被忽略的是权限作用域和引擎适配——给错库、选错引擎、忘了 FLUSH PRIVILEGES，三者占了线上授权失败的八成以上。