InnoDB - 使用复合主键而不是二级索引来聚集行的缺点？答案

【问题标题】：InnoDB - drawbacks of using composite primary key to cluster rows, instead of secondary indexes?InnoDB - 使用复合主键而不是二级索引来聚集行的缺点？
【发布时间】：2014-11-19 18:41:33
【问题描述】：

以论坛帖子为例：

CREATE TABLE Post (
    threadId INT,
    order INT,
    message VARCHAR(255),
    PRIMARY KEY (threadId, order)
) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

InnoDB 按主键对行进行物理排序。在这种情况下，可以通过questionId 查找问题的答案，并且它们在磁盘上的顺序相同，因此需要更少的磁盘查找。

使用这种方法进行快速读取访问有什么明显的缺点吗？

我主要关心数据库大小和读取吞吐量，而不太关心写入吞吐量。表大小预计最大为 150GB。我的桌子上没有其他索引。记录是批量插入的，通常通过主键。我的查询都是按主键查找记录。

【问题讨论】：

“InnoDB 按主键对行进行物理排序”：我对此表示怀疑。删除和插入后太难了。但如果您不指定另一个行，它本质上应该按该顺序返回行。

标签： mysql innodb

【解决方案1】：

我假设您的查询通常如下所示：

SELECT * FROM Post
  WHERE threadID = '1'
  ORDER BY `order`

如果您不介意在订单更改时更新记录的困难，那么您的设计很好。

向主键添加顺序会强制顺序值是唯一的（每个线程 ID）。所以，当你想重新排序时，你不能暂时有重复的数字。相反，您必须想出一些方案来更新不会产生重复的记录的顺序。

要获得更好的性能，请减小 message 列的大小。

为避免影响写入性能，请按顺序插入记录。

其他注意事项

以写入性能和存储为代价，您可以添加一个覆盖索引。假设您已将 InnoDB 配置为使用足够的内存并且您的系统有足够的可用内存，那么 MySQL 可以使用覆盖索引从 RAM 上提供整个查询结果。

此外，您可以使用内存表以牺牲写入性能来提高读取性能。

【讨论】：