1

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

4

8 回答 8

11

您是否会通过对数据进行分区来获得性能提升取决于数据以及您将在其上运行的查询。您可以在一个表中存储数百万行，并且具有良好的索引和精心设计的查询，它仍然会非常快。如果您已经确信您的索引和查询已经尽可能好，则仅考虑分区，因为它可能比它的价值更麻烦。

于 2008-09-20T15:42:56.217 回答
3

没有神奇的数字，但有几件事会特别影响性能：

  • 索引基数：不要费心索引具有 2 或 3 个值的行（如 ENUM）。在大表上，查询优化器将忽略这些。
  • 写入和索引之间存在权衡。您拥有的索引越多，写入所需的时间就越长。不要只索引每一列。分析您的查询并查看需要为您的应用编制索引的列。
  • 磁盘 IO 和内存起着重要作用。如果您可以将整个表放入内存中，那么您将磁盘 IO 排除在外（一旦表被缓存，无论如何）。我的猜测是，当您的表太大而无法在内存中缓冲时，您会看到很大的性能变化。
  • 考虑根据使用情况对服务器进行分区。如果您的事务系统正在读取/写入单行，您可能可以通过将数据复制到只读服务器以进行汇总报告来为自己争取一些时间。

您可能知道，表性能会根据数据大小而变化。密切关注您的表格/查询。你会知道什么时候需要改变。

于 2008-09-20T17:19:05.567 回答
2

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

于 2008-09-22T14:07:28.787 回答
0

虽然事后您可以指出性能成为问题的表大小，但我认为您无法预测它，当然也不能从此类网站上提供的信息中预测！

你可能会问自己一些有用的问题：

  • 目前的性能是否可以接受？
  • 如何衡量绩效 - 是否有衡量标准？
  • 我们如何识别不可接受的性能？
  • 我们是否以任何可能使我们能够预测问题的方式来衡量绩效？
  • 我们所有的查询都使用了有效的索引吗？
  • 我们是否模拟了系统上的极端负载和体积？
于 2008-09-20T16:31:22.590 回答
0

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

于 2008-09-20T16:34:48.213 回答
0

如果您认为不需要，请不要应用优化。理想情况下，这应该通过测试来确定（正如其他人所暗示的那样）。

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

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

于 2008-09-20T20:26:54.037 回答
0

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

看看他的功夫演示，看看他的帖子。我相信你会发现他写了一些有用的建议。

于 2008-09-20T20:46:04.070 回答
0

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

Jeremy Zawodny 有一篇关于如何解决这个问题的优秀文章。

于 2008-09-20T20:54:13.147 回答