MySQL 分区：按 ID 选择，但按日期删除

Question

考虑下表：

CREATE TABLE `event` (
  `uid` bigint(13) NOT NULL,
  `time` bigint(14) NOT NULL,
  `type` smallint(5) NOT NULL,
  `msg` varchar(2048) DEFAULT NULL,
  KEY `uid` (`uid`),
  KEY `time` (`time`),
  KEY `time_type_uid` (`time`,`type`,`uid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

我基本上是做什么的：

• INSERT 每天约 100 万行，当前大小约为 1 亿条条目
• DELETE 超过 100 天的所有行：
  • 声明 #1：DELETE FROM event WHERE time < unix_timestamp()-100*86400;
  • 声明 #2：DELETE FROM event WHERE time < unix_timestamp()-100*86400 LIMIT 1000;
• 用户将SELECT所有事件按UID，每天总共约500个查询，所以不是那么多：
  • 声明 #1：SELECT * FROM event WHERE uid=4711 AND type IN (23,1002,12,1);
  • 声明 #2：SELECT * FROM event WHERE uid=4711 AND type IN (23,1002,12,1) AND time BETWEEN 1381051061 AND 1381051861;

处理这张桌子变得很慢，特别是因为DELETE 作业阻塞了桌子上的INSERTs/SELECTs。如上所述（声明#1），我们尝试了每日批量DELETE，如果不阻塞表格，它就不再起作用了。目前我们每 30 秒删除一次（声明 #2），但这会阻塞 10 秒。

我们计划增加INSERT 负载，但第一次测试导致线程挂在“系统块”状态，我猜这是由于 I/O。服务器设置按照 mysqltuner.pl 的建议进行了优化。硬件系统肯定有 I/O 问题并且是“原样”，不幸的是它不能因为几个原因而改变。我们甚至没有 root 访问权限。

分区甚至是一种解决方案吗？MyISAM 是最好的引擎吗？在改进硬件之前，我们需要优化任何东西。

Answer 1

只需使用InnoDB with snapshot isolation 即可获取可读快照。这样读者就不会被你的大删除工作所阻止。我认为您不应该针对这种相当标准的情况进行分区。分区是一个大锤子和侵入性的。也许一些简单的措施就足够了。

Answer 2

在你去麻烦分区之前（它执行得很好，但可能是系统管理员的毛球）尝试一些事情。

每天多次（甚至一小时多次）运行您的 DELETE 清理操作，因此它不必每次运行时都处理一百万行。

尝试运行

    DELETE FROM event
          WHERE TIME < < unix_timestamp()-100*86400
         LIMIT 10000

一遍又一遍。这将减少每个 DELETE 操作锁定您的表的时间，并将其释放给其他操作。

弄清楚您是否拥有正确的复合索引（时间、类型、uid）。您向我们展示的查询不会利用该索引，并且索引会在您插入时占用时间。看起来您可以尝试简单地删除该索引。您可能需要在 (uid,type) 上为您提到的查询建立索引。

摆脱SELECT *的使用。相反，只检索您的应用程序需要的列。当 MySQL 准确地知道您需要哪些数据项时，它可以进行令人惊讶的优化。

您能承受每天或每周的停机时间吗？如果是这样，请使用

 OPTIMIZE NO_WRITE_TO_BINLOG TABLE  event

偶尔整理一下表和索引结构。