MySQL 事件调度器执行了但任务表没有更新怎么排查

MySQL 事件调度器显示“执行过”，但任务表没有新记录或状态没有变化时，先不要重写 UPDATE。这类现象通常要拆成两件事：事件是否真的按计划触发，以及事件体是否以正确的定义者权限写到了正确的表。只看客户端返回的创建成功，无法证明后续调度成功。

最稳妥的判断链是：全局调度器为 ON，事件状态为 ENABLED 且计划有效，LAST_EXECUTED 能前进，定义者拥有目标表权限，最后再核对 SQL 的筛选条件和实际影响行。

一、步骤一：先确认 Event Scheduler 真在运行

先查实例级开关和事件本身的元数据，不要只在应用连接上执行一次 SHOW EVENTS 就下结论。event_scheduler 为 ON 时，服务器才会调度事件；为 OFF 时事件定义仍然保留，但不会执行；如果是 DISABLED，通常需要在启动配置中处理，不能把它当成普通运行时开关。

-- 查看实例级调度开关；这是所有事件的共同前提
SELECT @@global.event_scheduler AS event_scheduler;

-- 查看目标库的事件状态，不修改任何定义
SHOW EVENTS FROM app_db;

-- 只有确认有 SYSTEM_VARIABLES_ADMIN 等相应权限后，才在维护窗口启用
SET GLOBAL event_scheduler = ON;

如果第一条返回 OFF，先确认是否有其他运维策略会在重启后覆盖配置。不要为了临时验证直接在生产实例反复切换开关，因为它影响的是整个实例上的事件，而不是某一条事件。

二、步骤二：核对事件状态、计划和 LAST_EXECUTED

接着确认事件没有被禁用、计划没有过期，且查的是正确的数据库对象。一次性事件默认可能在完成后不保留；重复事件还要检查 STARTS、ENDS、间隔字段以及创建时采用的时区。建议同时看定义全文和结构化元数据：

-- 先看完整定义，确认目标 schema、计划和 DO 后面的 SQL
SHOW CREATE EVENT app_db.refresh_task\\G

-- 再看可用于排查的状态字段和最近触发时间
SELECT EVENT_SCHEMA, EVENT_NAME, STATUS, EVENT_TYPE,
       EXECUTE_AT, INTERVAL_VALUE, INTERVAL_FIELD,
       STARTS, ENDS, LAST_EXECUTED, DEFINER
FROM INFORMATION_SCHEMA.EVENTS
WHERE EVENT_SCHEMA = 'app_db'
  AND EVENT_NAME = 'refresh_task';

STATUS 应该是 ENABLED，LAST_EXECUTED 也要和预期时间窗口相符。它仍然只是调度层证据：时间前进说明事件被触发过，不等于 UPDATE 命中了行。若事件被禁用，可在确认变更范围后使用 ALTER EVENT app_db.refresh_task ENABLE；先记录原定义，避免误改计划。

三、步骤三：按 DEFINER 检查真正的执行权限

MySQL 事件执行时使用定义者账户的权限。你用管理员账号查询到事件，并不代表事件里的账户能更新任务表。尤其是迁移环境中，定义者可能是旧账号、主机部分不匹配的账号，或者只拥有 SELECT 而没有目标表的 UPDATE、INSERT 权限。

-- 先取得事件定义者，再按返回的精确 user@host 检查授权
SELECT DEFINER
FROM INFORMATION_SCHEMA.EVENTS
WHERE EVENT_SCHEMA = 'app_db'
  AND EVENT_NAME = 'refresh_task';

-- 示例：把上一步返回的账户替换到这里，不要凭当前登录用户猜测
SHOW GRANTS FOR 'event_runner'@'localhost';

如果事件体调用了存储过程，还要继续检查过程内部涉及的表和权限。不要只给当前 DBA 账号加权限；应按照最小权限原则修复事件定义者的授权，并把错误日志中的拒绝信息与目标对象对上。

四、步骤四：把“事件执行”与“任务表更新”分开确认

当 LAST_EXECUTED 已经前进，重点转向事件体。用 SHOW CREATE EVENT 检查 UPDATE 或 INSERT 指向的 schema、表名和列名，再核对 WHERE 条件是否仍能命中待处理数据。常见情况是事件确实运行了，但条件已经不成立，所以影响行数为零。

错误或警告结束的事件会把相关信息写入 MySQL 错误日志，因此应结合实例日志、目标 schema 和任务表的实际变化判断。修复后只做一次反向验证：确认下一次 LAST_EXECUTED 前进，并在同一 schema 中看到符合条件的记录变化。这样才能把“调度成功”和“业务结果正确”闭合起来。

常见问题

事件创建成功后为什么一直不执行？

创建成功只说明定义被保存，还要确认全局 event_scheduler 为 ON，事件状态为 ENABLED，并且当前时间落在计划范围内。

LAST_EXECUTED 有值能证明任务表更新了吗？

不能。它证明事件曾被触发，不能证明 SQL 命中了行；还要检查定义者权限、目标表、WHERE 条件和错误日志。

应该给当前登录用户补权限吗？

通常不应该。先读取事件的 DEFINER，再为真正执行账户补齐目标对象所需的最小权限，并重新观察下一次计划执行。