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

考虑下表：

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;

我的基本工作是：

每天插入约100万行，当前大小约为1亿个条目 删除所有超过100天的行： 语句1：从事件中删除，其中时间 我们计划增加插入负载，但是第一次测试导致线程挂起在系统块状态，我想这是由于I/O。服务器设置按照mysqltuner.pl的建议进行了优化。硬件系统肯定存在I/O问题，并且保持原样，不幸的是，由于几个原因，它无法更改。我们甚至没有根访问权限

---

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

只需使用即可获得可读的快照。这样，读者就不会被你的大删除作业所阻挡。我认为您不应该在这种相当标准的情况下使用分区。分区是一个巨大的锤击和入侵。也许一些简单的措施就足够了。

在您遇到分区的麻烦之前，请尝试以下几件事情：分区执行得很好，但可能是系统管理员的一个小问题

每天多次甚至每小时多次运行删除清理操作，这样它就不必每次运行时都要处理一百万行

试着跑步

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

---

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

投票结束：太宽。这是一个有趣的问题，但范围太广，无法在这里给出明确的答案，而且可以说这不是一个严格意义上的编程问题。我们可以告诉您如何进行分区，但不能抽象地进行优化。为什么不使用InnoDB？服务器设置是什么？什么是系统规格和负载？正在运行哪些其他查询？您多久删除一次，是否可以更频繁？您有适合您的查询模式的索引吗？我的猜测是，不完全如此。谢谢你的评论。我知道很难为一个广泛的问题给出优化建议。我认为像这样处理数据可能是一个普遍的问题。我添加了一些详细信息，希望能有所帮助。dba.stackexchange可能是一个更好的地方，可以询问哪些类型的优化是合适的，以及您如何衡量它们的有效性。谢谢，我们已经尝试了有限度删除。它可以工作，但会阻塞约10秒。绝对不能同时使用更多的插件。

 OPTIMIZE NO_WRITE_TO_BINLOG TABLE  event