开启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，直接用最小权限账号创建事件，让它的身份就是执行身份

权限边界在事件创建那一刻就锁死了，后续改账号权限不影响已存在事件的行为——这点常被忽略。