日志表的Mysql设计答案

【问题标题】：Mysql design for logtable日志表的Mysql设计
【发布时间】：2013-03-31 15:54:15
【问题描述】：

我想获得有关事件记录器的 mysql 表设计的建议。

我们的需求： - 跟踪很多动作 - 10 000 次动作/秒 - 此时有 10 亿行

我们的硬件： - 2*Xeon（系统视为 32 CPU） - 128 GB 内存 - 6*600 SSD 与 Raid 10

我们的餐桌设计：

CREATE TABLE IF NOT EXISTS `log_event` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `id_event` smallint(6) NOT NULL,
  `id_user` bigint(20) NOT NULL,
  `date` int(11) NOT NULL,
  `data` bigint(20) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `id_event_2` (`id_event`,`data`),
  KEY `id_inscri` (`id_inscri`),
  KEY `date` (`date`),
  KEY `id_event_4` (`id_event`,`date`,`data`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8


ALTER TABLE `log_event`
  ADD CONSTRAINT `log_event_ibfk_1` FOREIGN KEY (`id_inscri`) REFERENCES `inscription` (`id_inscri`) ON DELETE CASCADE ON UPDATE CASCADE;

我们的问题： - 我们有一个自动增量作为主要，但它并没有真正使用。删除它有问题吗？如果我们删除它，我们将没有主键 => 如何识别一行？

我们想做partionning，但是用foreigning好像是不可能的？
我们不进行批量插入。在没有索引的内存表中插入并每 5 分钟复制一次数据是个好主意吗？

你有什么优化的想法吗？你有这种系统的最佳实践吗？

谢谢！

弗朗索瓦

【问题讨论】：

这里有一个相关的问题可能会有所帮助：stackoverflow.com/questions/11904720/…
问题不是真的要插入数百万行（我们有数十亿）我们非常高的并发性。我们也在寻找任何优化/最佳实践的想法

标签： mysql performance innodb

【解决方案1】：

关系表（relations）的主键可能有两种：

自然 - 存在于主题区域以完全确定关系表的每一行。自然主键可能是简单（如果仅包含一列）或复杂（如果包含多列）。不建议在大字符串列上设置自然主键。
人工 - 特殊列，由数据库设计人员/开发人员注入以提高表性能，如果自然键很复杂，并且必须在相关表中使用（是某事的外键），或者如果它很简单，但很大并且在作为外键复制到相关表中时会产生数据开销，或者如果搜索很复杂（例如，VARCHAR ID 上的 CRUD 操作可能比@ 987654324@ ID）。可能还有其他原因。 TL;DR：人工键 - 一个特殊的列，用于完全确定关系表的每一行并提高其对 CRUD 操作的性能。

我们有一个自动增量作为主要，但它并没有真正使用。是吗有问题要删除吗？如果我们删除它，我们将没有主键 => 如何识别线？

如果您不需要将您的表引用到另一个表（作为源），那么您可能会删除人工密钥而不会产生任何后果。尽管如此，我还是建议您在此表中设置任何其他 PRIMARY KEY 以避免数据重复和明显性（如果重要）。

您的表本身（如果正确normalized）将具有自然键作为“关键候选者”之一。它可能很复杂（由几列组成）。这是正常的。但是不要为字符串设置primary，因为PRIMARY总是有索引，会产生数据开销。如果是INT 或 "small" VARCHAR 列的组合，则正常。

考虑作为一个选项： id_event + id_user + date。

我们不进行批量插入。插入内存表是个好主意吗没有索引，每 5 分钟复制一次数据？

这不是一个坏主意。但这不是一个好主意，直到它经过适当的测试。在实际使用之前尝试执行负载测试。

如果您没有将MEMORY 表引用给其他人，那么您仍然可以将它与任何其他InnoDB 表连接起来。但是您将失去InnoDB 功能（referential integrity）。如果父表ON DELETE CASCADE ON UPDATE CASCADE 的丢失不是问题，那么它可能会完成。至于我，InnoDB 在你的情况下切换表引擎并没有那么慢。

【讨论】：