该场景下适用的MySQL表引擎选型咨询

嗨，咱们先拆解下你的核心场景：1000个用户每分钟生成一条记录，每天就是144万条数据，保留14天，每小时批量处理，还要定期滚动清理旧数据。之前用InnoDB删大量数据踩坑，Memory引擎又没法持久化，确实得找个更适配的路子。

先聊聊你之前的InnoDB问题 #

你遇到的InnoDB批量删除问题，大概率是因为直接用DELETE FROM ... WHERE FixTime < ...这种大范围删除——InnoDB的事务机制会生成大量undo日志，而且行锁会导致长时间锁表，拖垮性能。但其实InnoDB本身是适合你的场景的，只是删除方式不对，咱们可以换个玩法。

最优方案：InnoDB + 分区表 #

把你的map_data表按FixTime做RANGE分区（按天划分），这样清理14天前的数据时，不用一条条删，直接执行：

ALTER TABLE map_data DROP PARTITION p_20240501; -- 替换成对应日期的分区名

这是元数据级别的操作，瞬间完成，完全避开了批量删除的性能问题。而且分区还能优化你的每小时查询任务——查询指定时间范围的数据时，MySQL会直接定位到对应的分区，不用扫全表，效率提升一大截。

修改表结构的大致步骤（注意先备份数据）：

-- 先移除和分区键冲突的冗余索引（比如单独的FixTime索引，分区会自动优化这类查询）
ALTER TABLE map_data DROP INDEX IDX_map_data_FixTime;

-- 创建按天的RANGE分区
ALTER TABLE map_data PARTITION BY RANGE (TO_DAYS(FixTime)) (
    PARTITION p_20240501 VALUES LESS THAN (TO_DAYS('2024-05-02')),
    PARTITION p_20240502 VALUES LESS THAN (TO_DAYS('2024-05-03')),
    -- 提前创建好未来14天的分区，或者写个脚本每天自动创建新分区、删除旧分区
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

之后只需要写个简单的脚本（配合cron），每天自动删除14天前的分区，同时创建第二天的新分区就行。

备选方案1：Archive引擎 #

如果你的数据写入后几乎只做批量读取（每小时处理），很少做单条查询或修改，Archive引擎会是个不错的选择：

• 写入速度超快，比InnoDB/MyISAM都快，还自带压缩，磁盘占用能省不少
• 支持批量插入，完美适配你每分钟1000条的写入场景
• 同样可以结合分区来快速清理旧数据
• 缺点：只支持INSERT和SELECT，不支持UPDATE/DELETE单条记录，而且只能建主键/唯一索引——你的那些复合索引（比如IDX_map_data2）在Archive引擎下没法用，如果你的处理任务依赖这些索引，这个方案就不合适了。

备选方案2：MyRocks引擎 #

MyRocks是Facebook开源的基于RocksDB的MySQL引擎，专门针对高写入、大容量的场景优化：

• 写入性能比InnoDB更出色，尤其是批量写入
• 压缩比极高，磁盘占用比InnoDB小很多
• 删除数据是异步执行的，不会像InnoDB那样阻塞业务，很适合你的滚动清理需求
• 支持事务和行锁，并发性能比MyISAM好太多
• 缺点：需要额外安装，部分MySQL特性支持不如InnoDB完善，学习成本略高。

额外优化小Tips #

不管选哪个引擎，这些优化都能帮你提升性能：

• 写入时用批量插入：把每分钟的1000条记录拼成一个INSERT语句，而不是单条插入，能大幅提升写入效率
• 处理任务用分批读取：比如每次读10000条，循环处理，避免一次性读取大量数据导致内存过载
• 如果用InnoDB，调整innodb_buffer_pool_size（建议设为内存的50%-70%）、innodb_log_file_size（调大到1G-2G）等参数，优化写入和删除性能

内容的提问来源于stack exchange，提问作者Computation Smomputation