mysql 8.0中event_scheduler默认为on，但重启后变off主因是旧配置文件残留（如my.cnf含event_scheduler=off）或被其他配置段覆盖；若值为disabled则必须改配置并重启，不可动态开启；新事件默认disable需显式enable；时区以system_time_zone为准。
MySQL 8.0中event_scheduler默认是ON，但重启后变OFF？查配置文件是否被覆盖
MySQL 8.0起event_scheduler默认值确实是ON，但很多升级场景下它仍表现为OFF——根本原因不是版本问题，而是旧配置文件残留或启动时被其他配置覆盖。尤其从5.7升级上来的实例，my.cnf或my.ini里可能还留着event_scheduler = OFF，或者有多个配置段（比如[mysqld_safe]）意外禁用了调度器。
实操建议：
- 运行
mysqld --verbose --help | grep "Default options"确认MySQL实际加载了哪些配置文件（Linux/macOS）；Windows下检查服务启动参数里的--defaults-file - 用
SELECT @@global.event_scheduler;查当前值，再执行SELECT @@global.config_file;（8.0.22+支持）看配置路径 - 重点搜索所有配置文件中是否出现
event_scheduler字样，包括注释行（如#event_scheduler = OFF有时也会生效） - 若发现冲突配置，统一删掉或改为
event_scheduler = ON，然后必须重启MySQL服务（sudo systemctl restart mysql或Windows服务管理器）
SHOW PROCESSLIST里看不到event_scheduler线程？说明它被DISABLED而非OFF
event_scheduler变量有三个合法值：ON、OFF、DISABLED。前两者可动态切换，而DISABLED是只读状态，只能通过修改配置文件并重启解决。如果你执行SET GLOBAL event_scheduler = ON没报错，但SHOW PROCESSLIST里始终没有User: event_scheduler的daemon线程，且SELECT @@global.event_scheduler;返回DISABLED，就是这个情况。
常见触发点：
- 升级过程中MySQL自动将不兼容的旧事件标记为失效，并顺带把调度器设为
DISABLED - 某些云厂商RDS或容器镜像在初始化脚本里硬编码了
DISABLED（尤其在安全加固模板中） -
my.cnf中写成了event_scheduler = DISABLED（注意大小写，MySQL会接受但不提示）
验证命令：SHOW VARIABLES LIKE 'event_scheduler'; —— 若结果Value列是DISABLED，别试SET GLOBAL，直接改配置文件、删掉那行或改成ON，再重启。
事件创建后状态是DISABLE，不是调度器问题，而是CREATE时漏了ENABLE
即使event_scheduler是ON，新创建的事件默认状态也是DISABLE（除非显式声明ENABLE）。这和调度器开关无关，但新手常误以为“能CREATE就等于能跑”。执行SHOW EVENTS;看到Status列是DISABLE，就说明事件本身被挂起了。
修复方式分两种：
- 创建时就加
ENABLE：CREATE EVENT e_daily_archive ON SCHEDULE EVERY 1 DAY ENABLE DO ... - 已创建的事件启用：
ALTER EVENT e_daily_archive ENABLE; - 注意：普通用户执行
ALTER EVENT需有ALTER EVENT权限，不只是EVENT权限
另外，MySQL 8.0对DEFINER更严格：如果事件定义者账号不存在、密码过期或被锁，事件状态也可能卡在DISABLE且不报错——查information_schema.EVENTS里的DEFINER字段，再核对mysql.user表对应记录。
归档类事件执行失败却无日志？检查event_scheduler线程资源耗尽
大表归档事件（比如INSERT ... SELECT + DELETE）若频繁触发或单次处理量过大，可能因占用连接数过多，导致event_scheduler线程自身被挤出。现象是：事件状态一直是ENABLED，SHOW PROCESSLIST能看到event_scheduler线程，但Last_executed长期不更新，错误日志里也没有明显报错。
关键限制：
-
event_scheduler线程共享max_connections池，但它不计入Threads_connected统计，所以常规连接数监控会漏掉 - 每个事件执行都独占一个连接，若同时有10个事件在跑，就消耗10个连接名额
- 若事件体里有长事务（比如未分批的DELETE），可能引发锁等待，让后续事件排队阻塞
临时缓解：SET GLOBAL max_connections = 200;（根据服务器内存调整）；长期方案：给归档事件加LIMIT和循环逻辑，或改用存储过程控制并发粒度。别依赖“一次清空”，这是80%线上事件静默失败的根源。
最易被忽略的一点：MySQL 8.0的event_scheduler线程使用系统时区（@@system_time_zone），不是会话time_zone。如果服务器时区是UTC，但你想每天2点执行，却按本地时间写了STARTS '2026-10-14 02:00:00'，那它永远等不到那个时刻——务必先查SELECT @@system_time_zone;，再决定时间字面量怎么写。
