考虑一个有7列的索引MySQL表，该表会不断查询和写入。通过将数据拆分到其他表来提高性能之前，应允许该表包含的建议行数是多少？

解决方案

通过对数据进行分区是否会提高性能取决于数据和将在其上运行的查询。我们可以在一个表中存储数以百万计的行，并且具有良好的索引和精心设计的查询，它仍将是超快的。仅当我们已经确信索引和查询尽可能好时，才考虑进行分区，因为这样做比其价值更大。

尽管事实上我们可以指出性能成为问题的表大小，但我认为我们无法预测它，当然也不能根据此类网站上提供的信息来预测！

我们可能会问自己的一些问题：

• 目前性能可以接受吗？
• 如何衡量效果-是否有指标？
• 我们如何识别不可接受的性能？
• 我们是否以可能允许我们预测问题的任何方式衡量绩效？
• 我们所有的查询都使用有效的索引吗？
• 我们是否已经模拟了系统上的极限载荷和极限体积？

使用MyISAM引擎，除非更改默认值，否则表大小将受到2GB的硬限制。

没有魔幻数字，但是有一些因素会特别影响性能：

• 索引基数：不要麻烦索引具有2或者3个值的行(例如ENUM)。在大表上，查询优化器将忽略它们。
• 在写和索引之间需要权衡。我们拥有的索引越多，写入所需的时间就越长。不要只是索引每一列。分析查询，并查看需要为应用程序索引的列。
• 磁盘IO和内存起着重要的作用。如果我们可以将整个表装入内存，则可以将磁盘IO从等式中取出(无论如何，一旦缓存了表)。我的猜测是，当表太大而无法在内存中缓冲时，我们会看到性能的巨大变化。
• 考虑根据使用情况对服务器进行分区。如果事务系统正在读取/写入单行，则可以将数据复制到只读服务器以进行汇总报告，从而节省一些时间。

我们可能知道，表性能根据数据大小而变化。留意桌子/查询。我们会知道何时该进行更改。

如果我们认为不需要优化，则永远不要进行优化。理想情况下，这应该通过测试确定(就像其他人提到的那样)。

水平或者垂直分区可以提高性能，但也会使应用程序复杂化。除非我们确定自己需要它，否则不要这样做，它肯定会有所帮助。

2G数据MyISAM文件大小只是默认值，可以在创建表时更改(或者稍后通过ALTER更改，但需要重建表)。它不适用于其他引擎(例如InnoDB)。

实际上，这是一个很好的性能问题。你读过杰伊·派珀斯(Jay Pipes)吗？没有特定的行数，但是有特定的读取页面大小，并且垂直分区可能有充分的理由。

查看他的功夫演示文稿，并浏览他的帖子。我相信我们会发现他为此写了一些有用的建议。

我们正在使用MyISAM吗？我们是否打算存储超过几GB的数据？注意MAX_ROWS和AVG_ROW_LENGTH。

Jeremy Zawodny在解决该问题方面有出色的著作。

MySQL 5具有内置的分区，非常好。不错的是，我们可以定义如何拆分表。例如，如果我们主要基于用户ID进行查询，则可以基于用户ID来对表进行分区，或者如果我们要按日期查询，请按日期进行查询。这样做的好处是MySQL会确切知道要搜索哪个分区表以找到值。不利的一面是，如果我们在未定义分区的字段中进行搜索，则该字段将扫描每个表，这可能会降低性能。