普通用户无法通过set global event_scheduler=on开启调度器，因需system_variables_admin等高危权限；真正可授予的仅是按库显式授予event权限（如grant event on app_log.*）、配合dml权限、create event必须带enable、且事件执行依赖definer账户权限。
普通用户无法通过 SET GLOBAL event_scheduler = ON 开启调度器，这是硬性权限限制，不是配置漏了——你真正能给的“事件权限”，只包括创建、修改、删除事件的能力，不包括控制全局开关。
event_scheduler 必须由 DBA 在配置文件中开启
用户没有权限动态开启调度器。SET GLOBAL event_scheduler = ON 需要 SYSTEM_VARIABLES_ADMIN（或旧版 SUPER）权限，属于高危权限，绝不应授予普通用户。
- DBA 必须在
my.cnf或my.ini的[mysqld]段下添加：event_scheduler = ON - 保存后必须重启 MySQL 服务：
sudo systemctl restart mysql（Linux）或通过 Windows 服务管理器 - 验证是否生效：
SELECT @@event_scheduler;返回值必须是ON（不是DISABLED或OFF） - 主从环境只应在主库开启，从库保持
OFF，避免重复执行
EVENT 权限必须按库显式授予，不能用 ON *.*
MySQL 8.0 默认严格校验通配符权限，GRANT EVENT ON *.* 对普通用户基本无效——即使执行成功，后续 CREATE EVENT 仍会报错 ERROR 1227。
Yuanfang Design System
下载
yuanfang-skills 的共享设计系统，提供 token CSS 变量、12+ 主题以及可复用的布局类型 HTML 块，供 yuanfang-html-image（以及 fu...）使用。
- 先确保目标数据库存在：
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 - 验证是否生效：
SELECT event_priv FROM mysql.db WHERE Db = 'app_log' AND User = 'app_user'，返回Y才算成功
CREATE EVENT 必须带 ENABLE，否则默认不执行
即使调度器已开、权限已给，CREATE EVENT 默认生成的是 DISABLED 状态——它不会触发，SHOW EVENTS 中显示为 DISABLED，Last_executed 始终为 NULL。
- 显式启用方式一（建时声明）：
CREATE EVENT my_event ON SCHEDULE EVERY 1 DAY ENABLE DO ... - 显式启用方式二（建后启用）：
ALTER EVENT my_event ENABLE - 禁用命令：
ALTER EVENT my_event DISABLE - 检查状态：
SELECT EVENT_NAME, STATUS, LAST_EXECUTED, NEXT_EXECUTED FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'app_log'
事件运行时依赖 DEFINER 账户权限，不是创建者权限
最容易被忽略的是：EVENT 权限和事件能否真正执行是两层隔离。你可能已经正确授了权、开了调度器、建了事件，但只要 DEFINER 账户缺失某张表的 UPDATE 权限，或者事件体里用了未授权的数据库名，它就完全不报错也不执行——只能靠查错误日志定位。
- 未显式指定
DEFINER时，默认是DEFINER = CURRENT_USER，这是安全默认值 - 若事件内含
INSERT等操作，DEFINER账户必须有对应表的 DML 权限 - 事件失败是静默的，不会抛异常，只会记一条类似
INSERT command denied的错误到 MySQL 错误日志 -
max_connections和event_scheduler共享线程资源；高并发事件可能因连接数耗尽而静默失败
