【数据存储】数据库索引：邮件表的时间复合索引

实战应用：用在哪里

邮件表的查询模式高度固定：按收件人拉未读、按时间清理过期、按发件人追审计。三个查询在百万级邮件表上没有索引就是全表扫描，一条慢查询拖垮整个登录流程的案例每个项目都遇到过。

复合索引设计

ALTER TABLE mail ADD INDEX idx_to_read (to_id, read_flag, expire_at);
ALTER TABLE mail ADD INDEX idx_expire (expire_at);
ALTER TABLE mail ADD INDEX idx_from (from_id, created_at);

收件人加已读加过期时间的三列复合索引覆盖登录拉取场景，过期时间单列索引服务清理任务，发件人复合索引支撑审计追查。列顺序遵循最左前缀：区分度高的列在前，等值列在范围列之前。

验证与效果

EXPLAIN SELECT id FROM mail
WHERE to_id = 10086 AND read_flag = 0 AND expire_at > NOW();

用 EXPLAIN 确认走 idx_to_read 且 rows 扫描量从 120 万降到 40，登录拉取耗时从 1.8 秒降到 3 毫秒。索引不是越多越好：写路径每次插入要维护全部索引，邮件表写入高峰每秒两千条，索引数控制在三个以内。定期用 sys.schema_unused_indexes 清理从未命中的索引，历史遗留的五个无用索引删除后插入耗时下降两成。

踩坑记录

曾经给邮件标题建过前缀索引想着支持标题搜索，实际运营用的是日志平台的全文检索，数据库里的标题索引从未命中，白白拖慢写入。复合索引列顺序也踩过坑：把范围列 expire_at 放在中间导致后半段索引失效，等值列全前置后才完整命中。

监控指标

慢查询日志按周 review，超过 100 毫秒的查询必须有对应索引或改写方案。

实施要点

索引的命名规范让维护成本大幅下降：idx_表名_列组的标准命名让后来者一眼看懂索引的用途，命名混乱时期的排查教训写进了团队规范。索引变更走审批流程，加索引前先在影子库跑 Explain 对比，确认收益才上生产。邮件表的分区策略与索引配合，按月分区后单区数据量可控，索引的层级高度保持稳定，老区的查询速度与新区一致，这是分区带来的隐性收益。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。