普通用户无法创建 mysql event 的根本原因是 mysql 8.0+ 对 event 权限实施严格绑定：必须指定具体数据库（如 grant event on app_log.*）、definer 用户真实存在且认证兼容、event_scheduler 由 dba 在 my.cnf 中启用并重启，且事件需显式声明 enable。
普通用户无法创建 MySQL EVENT，不是因为“没给权限”，而是因为 MySQL 8.0+ 对 EVENT 权限的生效逻辑做了严格限制：它必须与具体数据库绑定、依赖 DEFINER 身份真实存在且具备最小执行权限，且调度器本身必须由 DBA 预设开启。
CREATE EVENT 报错 Access denied 或静默失败
常见现象是执行 CREATE EVENT 时直接报 Access denied，或语句看似成功但 SHOW EVENTS 查不到、information_schema.EVENTS 中状态为 SLAVESIDE_DISABLED 或 DISABLED。根本原因不是语法错，而是权限未在正确粒度上授予：
-
GRANT EVENT ON *.*在 MySQL 8.0+ 基本无效——系统不激活该权限，除非账号还拥有APPLICATION_PASSWORD_ADMIN等特殊角色（普通业务账号不该有） - 必须指定目标库：先
CREATE DATABASE IF NOT EXISTS app_log，再GRANT EVENT ON app_log.* TO 'app_user'@'localhost' - 如果事件体里要写数据（比如
INSERT或DELETE），还得单独补 DML 权限：GRANT INSERT, SELECT ON app_log.* TO 'app_user'@'localhost' - 授完权必须
FLUSH PRIVILEGES，否则不会立即生效
事件创建后始终不触发，但 SHOW VARIABLES 显示 event_scheduler=ON
即使你确认 @@event_scheduler = ON，事件仍不执行，大概率卡在以下三个环节之一：
-
event_scheduler全局开关只能由 DBA 在my.cnf的[mysqld]段中写event_scheduler = ON并重启服务；普通用户执行SET GLOBAL event_scheduler = ON会报Access denied（需要SYSTEM_VARIABLES_ADMIN权限） -
CREATE EVENT默认生成DISABLED状态，必须显式加ENABLE关键字，例如：CREATE EVENT my_event ON SCHEDULE EVERY 1 DAY ENABLE DO ... -
DEFINER用户必须真实存在于mysql.user表中，且认证插件兼容（如旧库用mysql_native_password，新库默认caching_sha2_password，会导致 definer 验证失败）
迁移后事件存在但不执行，检查 mysql.event 表里的 definer 字段
用 mysqldump 导出时漏掉 --events 或没导 mysql 库，会导致事件定义被导入，但 definer 用户没同步过去。此时查 mysql.event 可能显示 definer='appuser'@'192.168.1.%'，但 SELECT User,Host,plugin FROM mysql.user WHERE User='appuser' 查不到对应行：
- 导入后必须手动创建该用户：
CREATE USER 'appuser'@'192.168.1.%' IDENTIFIED WITH caching_sha2_password BY 'xxx'; - 再授
EVENT权限：GRANT EVENT ON app_log.* TO 'appuser'@'192.168.1.%'; - 最后
FLUSH PRIVILEGES;，并用ALTER EVENT app_log.my_event ENABLE;显式启用 - 验证是否真跑起来：
SELECT EVENT_NAME, LAST_EXECUTED, NEXT_EXECUTED FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'app_log';——LAST_EXECUTED有值才算成功
最容易被忽略的是：事件不是“你登录谁就用谁的权限跑”，而是完全以 DEFINER 身份运行；这个身份不仅要存在、要有 EVENT 权限，还要能通过认证插件校验——三者缺一不可。
