MySQL索引与事件调度器：慢查询排查到自动化数据归档

对于很多从业务开发转过来，或者刚接触MySQL不久的同学来说，“索引”和“事件”这两个词往往处于两个极端：索引天天见，但又老是搞不明白为什么有时候加了索引还是慢；事件呢，很多人知道MySQL有个Event Scheduler，但真正用过的人少之又少，总觉得这东西不太靠谱，不如自己在应用里写个定时任务来得踏实。

我有段时间也在这种状态里打转，直到有一天，线上一个跑批量任务的库，每天早上都会被一个不走索引的慢查询拖垮，DBA半夜打电话让我看SQL；另一边，一个积累了半年的日志表，光清理数据就写了三版定时脚本，最后还得考虑服务器宕机脚本有没有补跑。从那时候起我才认真把MySQL索引和事件这两块放在一起研究，发现它们本身都不复杂，但组合起来能解决一类非常实际的问题：让数据库在无人值守的情况下，自己把“查得快”和“干得勤”这两件事做好。

这篇文章不打算从建表语句开始讲，也不打算贴几十页官方文档。我就按自己的实际使用经验，把这些年调索引、写事件调度、踩坑总结出来的东西梳理一遍。适合正在写业务SQL、想优化慢查询，或者被定期清理、定期汇总这类需求烦到的同学参考。

1. 索引的本质是顺序化，不是给表建目录这么简单

很多人理解索引，第一反应是“书的目录”。这个类比没毛病，但容易让人忽略一个关键点：目录本身也是一页一页的纸，你不能指望翻目录比翻正文快多少。MySQL的InnoDB索引默认用B+树结构，它真正的厉害之处在于把“随机查找”变成了“沿着有序结构查找”，同时叶子节点之间通过指针串联，让范围查询也能高效顺序扫描。

1.1 B+树到底解决了什么问题

可以这样理解：如果没有索引，你要在100万行数据里找一个id=500000的记录，只能从第一行往下扫，平均要扫50万行才能找到，这叫做全表扫描。而B+树通过多层分支结构，把“找某一条记录”的代价压缩到树的层数。InnoDB默认页大小是16KB，一个三层高的B+树大概能存2000多万条记录，也就是说绝大多数业务表，三次磁盘IO以内就能定位到目标行的位置。

这个“三层”的概念很关键。很多人问为什么MySQL不推荐用二叉树做索引，因为二叉树在极端情况下会退化成链表，而且树的层数太深，每一层都是一次磁盘随机IO。B+树特意把数据都放在叶子节点，非叶子节点只存索引键值，这样每层能覆盖的分支数就大得多，层数自然就浅了。

但是，B+树的收益不是白来的。每次插入、删除、更新，都要维护索引结构本身，B+树可能触发页分裂、页合并，这叫做写放大。如果一个表上建了七八个索引，写入时每个索引都要同步维护，写入性能会明显下降。所以索引不是越多越好，每一个多余的索引都是在给写入路径添堵。这也是为什么热搜词里有“数据库开启审计引起索引争用”这种说法——当数据库开启审计功能，会产生大量额外的读取和写入操作，这些操作同样要走索引，多个高并发访问争抢同一个索引页面，就出现了索引争用。

1.2 聚簇索引和二级索引，各管各的

InnoDB里，每张表只能有一个聚簇索引，它决定了数据行在磁盘上的物理排列顺序。主键就是聚簇索引；如果没有主键，InnoDB会找一个非空的唯一键；如果也没有，它会偷偷生成一个内部隐藏列作为聚簇索引。这一点常被忽略，但它非常影响插入性能——如果一张表没有明确的主键，InnoDB用隐藏的ROW_ID自增，不但浪费空间，而且这个隐藏ID是全局共享的，多张表会竞争同一个计数器，在高并发插入场景下会成为隐性瓶颈。

二级索引则是另外一棵B+树，叶子节点存的是索引列的值加上对应行的主键值。所以，一个查询如果用到了二级索引，它需要先在二级索引树里找到主键，再回到聚簇索引树里找到完整的数据行，这个动作叫回表。回表不是免费的，如果查出来的数据量很大，回表的随机IO会非常可观。

这里就引出一个优化思路：覆盖索引。如果查询需要的所有列都包含在同一个二级索引里，MySQL就不需要回表了，直接在索引树上就能拿到全部数据。比如你有idx_user_id(user_id, status, create_time)这个索引，查询SELECT status, create_time FROM t WHERE user_id = 123，直接走索引就能返回结果，连数据页都不用碰。这就是为什么很多优化case里，明明已经有了单列索引，还要把它改成联合索引的原因——不是为了查得更快，就是为了免掉回表这一步。

2. 一条慢SQL的完整排查链路，比背一百条优化口诀有用

索引优化的难点从来不是“会不会建索引”，而是“能不能判断现有索引是否在正常工作”。我见过太多人一遇到慢查询，第一反应就是加索引，结果加完发现还是慢，然后就开始怀疑MySQL是不是有bug。实际上，大部分问题在EXPLAIN输出的那一瞬间就能看出来。

2.1 先看EXPLAIN里的type列

type列反映了访问类型，从小到优分别是：ALL、index、range、ref、eq_ref、const/system。正常情况下，ALL就是全表扫描，index是遍历整棵索引树，range是范围扫描，ref是非唯一索引等值匹配，eq_ref是唯一索引等值匹配，const最多返回一条记录。

我自己的排查习惯，第一步就是看type是不是ALL。如果是ALL，不管key列有没有显示用到了索引，都要想想是不是条件列本身不具备走索引的条件。这里有个容易看走眼的点：有时候EXPLAIN显示possible_keys里有索引，但key列是NULL，这代表优化器评估之后认为走索引还不如全表扫描快——比如要查的数据占了全表的百分之二三十以上，优化器会直接放弃索引，因为回表成本太高了。

2.2 联合索引的最左前缀不是死规则，是数学规则

联合索引的本质是一个按照多列排序的B+树，顺序是先按第一列排序，第一列相同再按第二列排序，以此类推。所以，查询条件里如果不包含联合索引的最左列，那这个联合索引基本用不上。这不是MySQL故意刁难，而是B+树的结构决定了它没办法越过第一列直接定位第二列。

但这里有个反直觉的点：最左前缀不只是“从第一列开始连续匹配”，还允许范围匹配。比如联合索引idx(a, b, c)，查询WHERE a = 1 AND c = 3，a能走索引，c走不了，但因为a的等值条件把范围缩小到了一小撮数据，c的过滤是在这个范围内进行的，实际效率通常可以接受。而WHERE b = 2 AND c = 3这种完全不涉及a的查询，这个索引就一点忙都帮不上。

2.3 隐式类型转换，一个极其隐蔽的索引杀手

热搜词里有个“mysql中int+5”，刚好对应一个典型场景：WHERE mobile = 13800138000，如果mobile列是VARCHAR类型，手机号是字符串，那这里的数字常量会被转换成字符串去匹配，没问题。但反过来，WHERE int_col = '123'，如果int_col是INT类型，MySQL会把字符串常量'123'转换成数字123再比较，这种情况索引通常还是能走的。

真正问题出在你用函数包住索引列的时候，比如WHERE DATE(create_time) = '2024-06-01'，或者WHERE id + 5 = 100。一旦对索引列做了运算，索引就失效了，因为B+树里存的是原始值，没法直接根据运算后的值去匹配。优化器也不是完全不能处理这种情况，5.7之后它有能力把WHERE DATE(create_time) = '2024-06-01'改写成create_time >= '2024-06-01 00:00:00' AND create_time < '2024-06-02 00:00:00'这样的范围条件，但这种改写有限制，不能所有场景都指望它。

所以稳妥的写法是：能不改列就不改列。WHERE id = 95直接写成WHERE id = 95 - 5，让MySQL去算常量，而不是把id套进表达式里。

2.4 FIND_IN_SET到底能不能走索引

这个问题在热搜词里出现了，估计不少人被它坑过。FIND_IN_SET(col, '1,2,3')这个函数，含义是在逗号分隔的字符串列表里查找col的值。它本身是为逗号分隔字段设计的，但这个函数把列表解析的逻辑放到了每一行上，所以它无法使用索引。通俗地说，它得先取出每一行，把col的值和列表里的每个元素挨个比一遍，才能知道结果。

如果你真的需要在逗号分隔的字段里查某个值，而且这个字段很大、查询很频繁，那正确做法是拆分成关联表，而不是硬扛。如果字段没法拆，就走全表扫描，同时尽量把其他条件先过滤掉一批数据，让全表扫描的行数尽量少。

3. 事件调度器是个好东西，只是很多人不知道它有多可靠

MySQL的事件调度器（Event Scheduler）从5.1版本就有了，但一直是个“知道的人多，用的人少”的功能。它本质上是一个在MySQL内部运行的定时任务线程，可以在指定时间点或按固定周期执行一段SQL语句、一个存储过程，相当于把crontab的能力内置到了数据库引擎里。

3.1 它和触发器、应用定时任务有什么区别

触发器和事件名字听起来像，但完全是两码事。触发器是表上的被动响应，某行数据发生增删改时立刻执行；事件则是时间驱动的主动任务，到了时间点自动执行。应用定时任务的思路是在业务代码里用Quartz、xxl-job这类框架去调用SQL，但如果应用服务本身挂了，任务也就没了；事件调度器跑在MySQL内部，只要MySQL进程活着，它就会按计划执行，天然跟应用服务的生命周期解耦。

事件调度器还有一个优势是部署简单。不需要额外装组件，不需要配置独立的调度平台，一条CREATE EVENT语句就搞定。对中小型项目来说，用它来做每日统计、定期清理、归档数据，完全够用。

3.2 如何开启调度器和基本语法

MySQL默认情况下事件调度器是关闭的，需要手动打开。查看当前状态：

sql复制SHOW VARIABLES LIKE 'event_scheduler';

如果值是OFF，可以通过以下方式临时开启：

sql复制SET GLOBAL event_scheduler = ON;

但这样只是当前实例生效，重启MySQL之后会恢复默认值。想要永久生效，需要修改配置文件my.cnf或my.ini，在[mysqld]下加一行：

ini复制event_scheduler = ON

创建事件的基本语法长这样：

sql复制CREATE EVENT IF NOT EXISTS daily_cleanup
ON SCHEDULE EVERY 1 DAY
STARTS '2024-06-01 03:00:00'
DO
BEGIN
    DELETE FROM operation_log WHERE create_time < NOW() - INTERVAL 90 DAY;
END;

这里有几个参数可以留意一下。EVERY 1 DAY代表执行周期，可以是1 HOUR、5 MINUTE、1 WEEK等，甚至可以配合STARTS和ENDS指定有效时间范围。如果不写STARTS，默认创建后立刻执行一次；如果希望任务永续运行，可以不加ENDS。还有一种一次性事件，把EVERY 1 DAY换成AT '2024-06-01 10:00:00'即可，执行完事件会自动删除。

3.3 和crontab相比，事件调度器的坑在哪里

事件调度器虽然方便，但它有几个隐藏的坑。

第一，时区问题。如果MySQL服务器的系统时区不是北京时间，STARTS和ENDS的时间会按服务器的系统时区解析。这就导致你在本地连数据库看到的创建语句里时间是正常的，实际执行时间却偏了几个小时。解决方法是设置全局时区：

sql复制SET GLOBAL time_zone = '+08:00';

或者直接在配置文件的[mysqld]段里写default-time-zone = '+08:00'。在创建事件时，也可以指定ON SCHEDULE后面的时间带时区偏移，比如STARTS '2024-06-01 03:00:00' +08:00，但最省事的还是统一全局时区。

第二，事件执行失败不会自动告警。事件调度器执行SQL的过程中出了错，比如表不存在、权限不足、锁等待超时，MySQL默认只会把错误写进错误日志，不会主动通知你。所以生产环境如果依赖事件做了核心的清理或统计任务，一定要定期检查事件执行状态。可以通过information_schema.events表查看：

sql复制SELECT event_name, status, last_executed, last_alter_time
FROM information_schema.events
WHERE event_schema = 'your_database';

last_executed字段表示上次执行时间。如果这个时间一直不更新，说明事件可能已经挂掉了。

第三，事件执行期间MySQL重启，错过的任务不会补跑。比如你设置每天晚上三点执行，那天MySQL刚好三点十分宕机了，重启之后这个任务不会自动补执行，只能等下一个周期。对严格的业务来说，这个特性需要自己做个补偿机制，或者在应用层再留一道保险。

4. 一个真实案例：用“事件+索引”搭起自动化数据归档

理论说了一大堆，还是用一个实际场景把它们串起来。我之前接手过一个后台系统，有一张操作日志表，每天新增几十万行，半年下来已经积累了三千多万行。最直观的问题是：查询变慢了，虽然建了索引，但数据量大了之后，索引树的层级加深，回表成本也在增加。更麻烦的是，这张表的清理工作一直靠人工写脚本，每个月手工跑一次，有一次漏跑了，第二个月查询直接把人卡死。

4.1 拆解思路：为什么归档比直接删更靠谱

面对大表，直接定期删除过期数据是最简单的方案，但有一个致命问题：DELETE在InnoDB里不是物理释放空间，只是把记录标记为删除，空间不会归还给操作系统，而且会产生大量binlog，在主从环境下会传导到从库，造成从库延迟。数据量特别大时，大批量DELETE还会引发锁竞争，影响在线业务。

归档的思路是把过期数据从主表搬到历史表，然后再从主表删除。这样主表始终保持一个合理的体积，查询性能稳定，历史数据也能随时回溯。

4.2 具体实操过程

第一步，创建一张历史表，结构和主表保持一致，但可以按月份做分区，方便后续管理：

sql复制CREATE TABLE operation_log_archive (
    id BIGINT NOT NULL,
    user_id INT NOT NULL,
    action VARCHAR(64) NOT NULL,
    create_time DATETIME NOT NULL,
    PRIMARY KEY (id, create_time)
) PARTITION BY RANGE (TO_DAYS(create_time)) (
    PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01')),
    PARTITION p202402 VALUES LESS THAN (TO_DAYS('2024-03-01')),
    PARTITION p202403 VALUES LESS THAN (TO_DAYS('2024-04-01')),
    PARTITION p202404 VALUES LESS THAN (TO_DAYS('2024-05-01'))
);

第二步，写一个存储过程，负责搬运数据。为了保证批量操作不会锁太久，我按每次搬5000条的节奏循环执行：先插入历史表，再删除主表。插入用INSERT IGNORE是为了避免主键冲突导致重复数据报错。

sql复制DELIMITER //

CREATE PROCEDURE archive_operation_log()
BEGIN
    DECLARE v_count INT DEFAULT 1;
    DECLARE v_batch_size INT DEFAULT 5000;
    DECLARE v_deadline DATETIME DEFAULT NOW() - INTERVAL 180 DAY;

    WHILE v_count > 0 DO
        INSERT IGNORE INTO operation_log_archive
            (id, user_id, action, create_time)
        SELECT id, user_id, action, create_time
        FROM operation_log
        WHERE create_time < v_deadline
        ORDER BY create_time
        LIMIT v_batch_size;

        DELETE FROM operation_log
        WHERE create_time < v_deadline
        LIMIT v_batch_size;

        SET v_count = ROW_COUNT();
        COMMIT;
    END WHILE;
END//

DELIMITER ;

这里值得展开讲一下为什么要ORDER BY create_time。如果不排序，每次SELECT取出的数据是随机的，可能导致本次删了5000条，下次又删到相邻区域的数据，长期下来容易出现删除碎片不连续。按时间顺序删，可以让每次删除都集中在一个时间段，减少页碎片。

第三步，创建事件，每天晚上两点执行一次归档。之所以选凌晨两点，是因为这个时间段业务量最低，归档对在线查询的影响最小。

sql复制CREATE EVENT IF NOT EXISTS ev_archive_operation_log
ON SCHEDULE EVERY 1 DAY
STARTS '2024-06-01 02:00:00'
DO
CALL archive_operation_log();

第四步，在归档事件执行完之后，再做一次OPTIMIZE或ANALYZE，更新表的统计信息。这是一个容易被忽略但很重要的步骤。因为大批删除之后，索引统计信息可能已经过时，优化器在生成执行计划时，可能还照着旧的数据分布去估算行数，导致选错索引。

sql复制CREATE EVENT IF NOT EXISTS ev_analyze_operation_log
ON SCHEDULE EVERY 1 WEEK
STARTS '2024-06-02 03:00:00'
DO
ANALYZE TABLE operation_log;

4.3 这个组合拳为什么有效

这套方案里，索引的作用体现在两个地方。主表的create_time索引保证归档SQL查找过期数据时能走索引范围扫描，user_id + action联合索引保证业务查询在检索用户操作记录时依然高效。事件的作用则是把归档动作“托管”给了数据库自己，不依赖外部定时任务。两者结合，相当于数据库在低峰期自己给自己做了一次“瘦身”，同时业务高峰期查询依然能靠索引快速响应。

我在这个方案上线后观察了两个月，主表数据量维持在一千五百万左右，查询稳定性明显改善。之前每月手工删数据时那种“删得多了怕锁表，删得少了怕查询慢”的纠结感，彻底没有了。

5. 索引与事件联动的几个深入坑位，提前避开

这两个功能单独用都还算简单，放到一起后，一些边界情况就暴露出来了，而且网上很少有人说清楚。我把自己踩过、也帮别人排查过的几个典型问题列出来，供大家参考。

5.1 事件里的大事务会把从库拖垮

如果你有主从复制架构，一定要小心事件里的大事务。还是上面那个归档例子，如果删除操作不是分批次，而是一条超大DELETE一次性清理几百万行，主库会生成一个巨大的事务，binlog传到从库后，从库执行这条事务可能耗时几十秒甚至几分钟，这段时间里从库的查询全部堆积，表现出来就是从库查询延迟飙升。

解决思路就是刚才写的这种分批提交。每次控制在一个合理的数据量，比如5000行，事务提交一次，binlog文件里就是一条一条的小事务，从库每次只需要重放一个小批次，压力会平滑很多。

5.2 事件调度器的线程会不会和业务抢资源

事件调度器本身是一个后台线程，它执行任务时确实会占用CPU和IO。但默认情况下，它的优先级并不高，不会抢业务SQL的资源。真正的问题往往出在事件里写的SQL不够收敛，比如一个循环里执行了上千次DELETE，每次DELETE都会独立提交，大量小事务产生，反而加剧了CPU和IO的消耗。

所以写事件里的SQL时，一定要考虑“一次事件执行的总工作量”。如果任务天生很重，可以拆成多个子事件，分别在不同时间点执行，或者用存储过程控制循环节奏，每执行一批都做一次DO SLEEP(1)，给其他查询留出缓冲时间。

5.3 索引统计信息过旧导致优化器选错索引

索引优化不只发生在建索引那一刻，还会发生在数据变化之后。ANALYZE TABLE的作用是重新统计索引的基数（distinct value数量），让优化器更准确地估算行数。但很多人的线上环境从来没有跑过这个命令，导致优化器一直用着旧统计信息做决策。

尤其在使用事件做大量删除的场景下，删掉几百万行之后，索引基数已经发生了天翻地覆的变化，旧统计信息完全失真。优化器可能以为某个选择性最高的索引只有几百个值，实际却有几十万，结果选了错误的索引，查询瞬间变慢。

建议做法是，在批量写操作结束后的低峰期，对受影响的关键表执行一次ANALYZE TABLE，更新统计信息。需要注意，ANALYZE在5.6以上的InnoDB中不会锁全表，但对大表仍然有一定IO开销，所以尽量放在低峰期。

6. 关于索引选择和事件使用习惯，一些个人层面的建议

写了这么多，最后说一点个人体会。

索引和事件这两个东西，单独理解都不难，但真正用好它们，靠的是对业务数据量和查询模式的深入了解。索引不是越多越好，每建一个索引之前，都应该问自己一句：这个查询的频率有多高？返回的行数有多少？能不能通过覆盖索引避免回表？代价是每次写入都要多维护一棵B+树，这笔账要会算。

事件调度器也是如此。它不是银弹，不适合所有定时任务，特别是那些需要跨服务调用、需要复杂业务判断的任务，放应用层更合适。但如果是纯SQL层面的周期性操作，比如清理过期数据、生成每日汇总、更新统计信息，用事件调度器不仅省事，还天然跟业务代码解耦，应用发布、重启都不影响它执行。

从实际运维的角度来看，我建议每个有点规模的项目都做这么两件事：一是建一个索引基线文档，把核心查询对应的索引都记下来，不要靠人脑记；二是给事件调度器建立一个状态巡检清单，每周或每月看一眼information_schema.events里的last_executed字段，确保任务都在正常跑。

毕竟，数据库这东西，平时不出问题的时候大家感受不到它的存在，但一旦出了问题，往往就是线上事故级别的。提前把索引设计好、把数据库能干的事交给数据库干，比临时抱佛脚要踏实得多。