普通用户无法执行 set global event_scheduler = on，需 system_variables_admin 或 super 权限；event 权限须显式授予具体数据库，如 grant event on app_log.*；创建事件必须加 enable 关键字，否则默认 disable；事件失败静默，需通过心跳日志或错误日志排查。
普通用户不能 SET GLOBAL event_scheduler
MySQL 8.0 中，SET GLOBAL event_scheduler = ON 是系统级操作，需要 SYSTEM_VARIABLES_ADMIN 或旧版的 SUPER 权限——这两者都属于高危权限，**绝不应授予普通用户**。即使你用 GRANT ALL PRIVILEGES，也不会自动包含该权限。
这意味着：普通用户无法自行开启或关闭事件调度器，也不能通过 SQL 动态切换全局状态。这是设计上的硬性隔离，不是配置遗漏。
- 检查权限是否生效？执行
SELECT CURRENT_USER(), @@session.role确认登录身份与角色上下文 - 若看到
Access denied for SET错误，直接放弃尝试该语句，换路径 - DBA 必须在配置文件中预设
event_scheduler = ON并重启服务，普通用户才可能后续创建事件
EVENT 权限必须显式授予数据库粒度
GRANT EVENT ON *.* 看似覆盖全库，但 MySQL 8.0 默认启用 sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'，且对通配符权限有更严格校验——**多数情况下，它不会被真正激活**。
正确做法是绑定到具体数据库：
- 先确保目标库存在：
CREATE DATABASE IF NOT EXISTS app_log - 再授予权限：
GRANT EVENT ON app_log.* TO 'app_user'@'localhost' - 如果事件体中要写入数据，还需补充 DML 权限：
GRANT INSERT, SELECT ON app_log.* TO 'app_user'@'localhost' - 最后刷新：
FLUSH PRIVILEGES
注意：ON *.* 在 MySQL 8.0+ 中仅对具备 APPLICATION_PASSWORD_ADMIN 等特殊角色的账号才有效，普通用户请老实用库名限定。
创建事件时必须带 ENABLE，否则默认 DISABLE
即使调度器已开、权限已给，CREATE EVENT 默认生成的是 DISABLE 状态事件——它不会触发，SHOW EVENTS 中显示为 DISABLED，且 Last_executed 始终为 NULL。
必须显式声明启用：
CREATE EVENT clean_old_logs
ON SCHEDULE EVERY 1 DAY STARTS '2026-05-11 02:00:00'
DO
DELETE FROM app_log.logs WHERE created_at <p>上面这段会失败（状态为 DISABLE）。正确写法是：</p><pre class="brush:php;toolbar:false;">CREATE EVENT clean_old_logs
ON SCHEDULE EVERY 1 DAY STARTS '2026-05-11 02:00:00'
ENABLE -- ← 关键！必须写这行
DO
DELETE FROM app_log.logs WHERE created_at
- 也可事后启用：
ALTER EVENT clean_old_logs ENABLE - 但首次创建不加
ENABLE，等于白建——这点极易忽略，且无报错提示
事件执行失败时几乎不报错，排查靠日志和表验证
MySQL 事件调度器静默失败是常态：语法错、权限不足、表不存在、磁盘满……都可能导致事件跳过执行，但 SHOW EVENTS 仍显示 ENABLED，Last_executed 却一直为空或停滞。
可靠验证方式只有两个：
- 在事件体中插入一条“心跳记录”到已知可写的表，例如：
INSERT INTO app_log.event_log (event_name, exec_time) VALUES ('clean_old_logs', NOW()) - 查错误日志：
SELECT @@log_error得到路径，然后tail -f /var/log/mysql/error.log观察调度器线程是否报错
别依赖 SHOW PROCESSLIST 查看 Waiting on empty queue——这只是空闲状态，不是故障信号；真正的失败往往没有进程痕迹。
