开启EVENT_SCHEDULER后CREATE EVENT仍报错，是因为执行账号必须显式授予全局EVENT权限（GRANT EVENT ON .），该权限不随常规权限自动赋予，也不在ALL PRIVILEGES中；MySQL 8.0+中角色无法间接继承EVENT权限；最小权限实践要求专用账号仅授EVENT及对应表的DML权限，禁用SUPER等高危权限；事件以创建者身份执行，DEFINER仅在NO_DEFINER未启用时生效，已创建事件的权限边界在创建时即锁定。
MySQL 5.7+ 中 EVENT_SCHEDULER 开启后，为什么 CREATE EVENT 还报错？
因为开启调度器只是第一步，真正执行事件的账号必须有 event 权限——这个权限不随 select、insert 等常规权限自动授予，也不包含在 all privileges（除非显式指定）。
-
GRANT EVENT ON *.* TO 'scheduler_user'@'%';是必需的，且必须作用于全局（*.*），不能限定到某个库 - 如果只给
GRANT EVENT ON `mydb`.*，创建事件时会报错：ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation - MySQL 8.0+ 支持角色管理，但
EVENT权限仍需直接授予用户，角色无法间接继承该权限（除非用SET ROLE显式激活）
给定时任务账号分配最小权限的具体操作步骤
目标是让账号只能创建/修改/删除自己名下的事件，不能碰其他对象（如表、函数、其他用户事件）。
- 先创建专用账号：
CREATE USER 'evt_runner'@'localhost' IDENTIFIED BY 'strong-pass-2024'; - 只授必要权限：
GRANT SELECT, INSERT, UPDATE ON `app_logs`.* TO 'evt_runner'@'localhost';（按事件实际操作的表来定） - 加上调度必需权限：
GRANT EVENT ON *.* TO 'evt_runner'@'localhost'; - 禁止高危权限：不要给
SUPER、PROCESS、REPLICATION CLIENT，否则绕过最小权限原则 - 刷新权限：
FLUSH PRIVILEGES;
为什么不能用 root 或应用主账号跑事件？
事件在后台由 MySQL 自己调用，一旦用高权限账号定义，它就以该账号身份执行 SQL——相当于把数据库“后门”长期开着。
- 比如一个读写日志表的事件，若用
root创建，它就能顺手删掉mysql.user表（只要语句里写了） - MySQL 不校验事件体内的 SQL 是否超出账号原始权限范围；它只检查创建时是否有
EVENT权限 - 事件定义中若含存储过程调用，该过程的执行权限也取决于事件定义者（definer），不是调用者——所以 definer 账号权限越小越安全
Event 定义里的 DEFINER 和实际执行权限的关系
这是最容易混淆的一点：事件是否真按你写的 DEFINER 执行，取决于 sql_mode 和 MySQL 版本。
- 默认情况下，MySQL 会忽略你写的
DEFINER = 'lowpriv'@'%'，改用当前创建者身份执行（即“匿名 definer”行为） - 要让它严格按指定用户执行，必须确保：
sql_mode包含NO_DEFINER（MySQL 8.0.16+）或显式设为DEFINER模式（旧版本） - 检查方式：
SELECT @@sql_mode;，若输出含NO_DEFINER，则DEFINER子句会被静默丢弃 - 最稳妥做法：别依赖
DEFINER，直接用最小权限账号创建事件，让它的身份就是执行身份
权限边界在事件创建那一刻就锁死了，后续改账号权限不影响已存在事件的行为——这点常被忽略。
