分区表维护需显式授予ALTER ROUTINE和EVENT全局权限，因ALTER仅限表结构修改，无法支持存储过程与事件操作；最小授权应包含SELECT、ALTER、ALTER ROUTINE、EVENT，并严格限定IP范围与账号职责。
分区表维护人员不能只给ALTER权限，必须显式授予ALTER ROUTINE和EVENT权限，否则存储过程与自动事件无法创建或执行。
为什么GRANT ALTER ON db.table不够用
分区维护通常依赖存储过程（如动态添加分区）和定时事件（如每月自动建新分区），而ALTER权限仅允许修改表结构本身，不覆盖存储过程定义、事件调度、函数调用等元操作。常见报错包括：ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled 或 ERROR 1142 (42000): EVENT command denied to user。
-
ALTER ROUTINE：用于创建/修改存储过程和函数，否则CREATE PROCEDURE会失败 -
EVENT：用于创建/启用/删除事件，否则CREATE EVENT被拒绝 -
SELECT和INSERT在mysql系统库中不是必需的，但若需查询information_schema.PARTITIONS做校验，应额外授权SELECToninformation_schema.*
最小可行授权语句示例
假设维护账号为'partition_mgr'@'10.0.5.%'，只负责logs_db库下的分区表：
GRANT SELECT, ALTER ON logs_db.* TO 'partition_mgr'@'10.0.5.%'; GRANT ALTER ROUTINE, EVENT ON *.* TO 'partition_mgr'@'10.0.5.%'; FLUSH PRIVILEGES;
注意：ALTER ROUTINE和EVENT必须是全局级别（ON *.*），MySQL不支持库级或表级授予——这是容易忽略的关键限制。
- 不要用
GRANT ALL PRIVILEGES ON *.*，避免意外获得DROP或SHUTDOWN等高危权限 - 如果使用MySQL 8.0+，可先创建角色
'partition_admin'打包上述权限，再授给用户，便于后续统一调整 - 该账号不应有
FILE、SUPER、GRANT OPTION，这些与分区维护无关且显著扩大攻击面
验证权限是否真正生效
用维护账号登录后，运行以下命令确认关键能力可用：
-
SHOW GRANTS;—— 检查输出中是否含ALTER ROUTINE和EVENT -
SELECT COUNT(*) FROM information_schema.PARTITIONS WHERE TABLE_SCHEMA = 'logs_db';—— 验证能否读取分区元数据 -
CREATE PROCEDURE test_p() BEGIN SELECT 1; END;—— 测试存储过程创建是否成功 -
CREATE EVENT test_e ON SCHEDULE AT NOW() DO SELECT 1;—— 测试事件创建是否通过
任何一项失败，都说明对应权限缺失或未FLUSH PRIVILEGES。尤其注意：MySQL 8.0.23+默认启用require_row_format等安全模式，可能干扰事件内联SQL执行，此时需额外检查sql_mode设置。
生产环境必须禁用的配置习惯
分区维护账号最容易因图省事引入风险：
- 禁止绑定
'partition_mgr'@'%'，必须限定内网运维网段（如'10.0.5.%'） - 禁止复用应用账号或DBA账号，职责分离能防止误删分区或泄露业务数据
- 禁止在存储过程中使用
PREPARE/EXECUTE拼接非可信输入，否则分区名注入可导致DROP PARTITION被恶意触发 - 定期用
SELECT user, host, Alter_routine_priv, Event_priv FROM mysql.user WHERE user = 'partition_mgr';核对权限列是否仍为Y，避免被其他脚本误清
真正的难点不在加权限，而在持续确保权限边界不被运维流程无意突破——比如备份脚本里临时用root执行ALTER TABLE，之后忘记切回专用账号，就等于绕过了所有分级控制。
