mysql - MySQL 中的解耦表能提高多少性能？

Question

我正在设计数据库以在 MySQL 中存储一些博客文章。我最近遇到了这个 answer这表明当你有:

1. 将定期查询的表格(例如博客文章列表)，但是
2. 该表中的一列包含大量不会定期访问的数据(博客内容)

然后，如果您将内容存储在单独的表中，性能会更好，因此当您生成列表时，它会更快。

CREATE TABLE article (
    id INT(10) UNSIGNED,
    title VARCHAR(40),
    author_id INT(10) UNIGNED,
    created DATETIME,
    modified DATETIME
);

CREATE TABLE article_text (
    id INT(10) UNSIGNED,
    body TEXT
);

即使该列不是查询的一部分，这是否会影响性能:

SELECT id, title FROM article WHERE author_id=33 ORDER BY created DESC LIMIT 5

它在多大程度上会成为性能问题？ (几百、几千？几百万？)

Answer 1

对于 MySQL 5.5 及更高版本，InnoDB 存储引擎支持 Barracuda file format .为了将 Barracuda 文件格式用于 InnoDB，您必须使用 file-per-table 表空间，或使用通用表空间(单文件“系统”InnoDB 表空间不支持 Barracuda)。

在梭子鱼(羚羊)之前，MySQL always stored at least the first 768 bytes of a TEXT column in the clustered (primary key) index .在这种情况下，即使没有引用 TEXT 列，也会增加聚集索引(叶节点)中每一行的大小。这减慢了对其他非文本列的表扫描，因为每页适合的页面更少(平均扫描更多页面以找到您要查找的内容)，但在扫描文本列时提高了性能(无论如何前 768 个字节) .你在做大量的表扫描吗？希望您能够使用索引来避免表扫描。

索引是 b-trees并且 key 搜索是在仅包含 key 的内部节点上完成的。对于聚集索引，它只是主键，因此聚集索引搜索不受叶节点中数据量的影响(但受主键大小影响)。

对于 InnoDB 的 Barracuda 文件系统，整个 TEXT 列存储在溢出页中(可以压缩)。它的任何部分都不存储在聚集索引(叶节点)中。因此，如果您使用的是 Barracuda 文件系统，让 MySQL 为您进行分离，只需将 TEXT 列放在同一个表中即可。在这种情况下，您不会获得任何好处，因为 MYSQL 已经将 TEXT 列放在其他地方并且不会影响扫描非 TEXT 列。

如果您正在使用 Antelope，如果您经常扫描非 TEXT 列(无论如何都应该避免)，并且您很少引用 TEXT 列，则可以考虑拆分它。将其拆分为两个表，要读取整个记录，您现在必须对两个聚簇索引进行搜索，这是一个的两倍。

我还可以看到想要在 MySQL 的 InnoDB 缓冲区空间 RAM 有限的系统上将它与 Antelope 拆分，并且您很少引用 TEXT 列。包含非 TEXT 列的叶节点如果较小，则更有可能保留在内存中。