数据库中有多少行太多了？答案

【问题标题】：How many rows in a database are TOO MANY?数据库中有多少行太多了？
【发布时间】：2010-12-27 22:03:31
【问题描述】：

我有一个包含 1,000,000 条记录的 MySQL InnoDB 表。这太多了吗？或者数据库可以处理这个以及更多？我之所以问，是因为我注意到在具有 100 行的表中，某些查询（例如，从表中获取最后一行）比具有 100 行的表中的查询要慢（秒）。

【问题讨论】：

标签： sql mysql database performance

【解决方案1】：

我有一个包含超过 97,000,000 条记录（30GB 数据文件）的数据库，没有问题。

请记住定义和改进您的表格索引。

所以很明显 1,000,000 并不多！（但如果你不索引；是的，很多）

【讨论】：

是否将“主键”添加到列（通过选择自动增量）作为索引？
@Nathan ，其实当你把一个列指定为主键时，它会自动被索引，但是每个表只能有一个主键，如果你需要为某些列添加索引，以优化查询使用这个stackoverflow.com/a/3002635/932473
我的表格有 1 万亿，但选择 IN LIFO 格式的数据很慢？
定义没有问题。最复杂的查询需要多长时间？我们有一个包含 1 亿行的表，客户希望查询最多在 5 秒内完成，无论他们使用什么分组或排序标准。我们的索引可以改进，但在我们锁定所有尝试添加索引之前
20% 的生产表（根据一项旧研究）有超过 100 万行。我见过几个有几十亿行。

【解决方案2】：

我认为这是一个常见的误解 - 在数据库可扩展性方面，大小只是等式的一部分。还有其他困难（或更难）的问题：

工作集有多大（即需要在内存中加载多少数据并积极处理）。如果你只是插入数据，然后什么都不做，这实际上是一个很容易解决的问题。
需要什么级别的并发？是只有一个用户插入/读取，还是我们有成千上万的客户端同时操作？
需要什么级别的承诺/持久性和性能一致性？我们是否必须确保我们能够兑现每一次提交。平均交易速度是否可以，或者我们是否要确保所有交易都可靠快速（六西格玛质量控制，如 - http://www.mysqlperformanceblog.com/2010/06/07/performance-optimization-and-six-sigma/）。
您是否需要执行任何操作问题，例如 ALTER 表架构？在 InnoDB 中这是可能的，但速度非常慢，因为它经常需要在前台创建一个临时表（阻塞所有连接）。

所以我要说明两个限制性问题是：

您自己编写查询的技能/拥有良好的索引。
您可以忍受等待 ALTER TABLE 语句的痛苦。

【讨论】：

编辑：关于 ALTER TABLE 创建临时表的建议有点过时了。 MySQL 5.5 具有快速索引创建，5.6 现在具有在线 DDL。

【解决方案3】：

我见过包含数十亿条（索引）记录的非分区表，它们自联接用于分析工作。我们最终对事物进行了分区，但老实说，我们并没有看到太大的区别。

也就是说，那是在 Oracle 中，我还没有在 MySQL 中测试过这么多的数据量。索引是你的朋友:)

【讨论】：

【解决方案4】：

使用“解释”检查您的查询，看看查询计划是否有任何问题。

【讨论】：

虽然这是一个好主意，但这个答案本身并不适合给新手。 EXPLAIN 的输出不是很直观...
没有其他工具可以帮助您检查查询，所以最好开始学习EXPLAIN - 新手与否。
如果有人可以EXPLAIN EXPLAIN ;) 会很好
@Deadpool Mysql Explain Explained

【解决方案5】：

使用提供的查询将异常缓慢，因为使用排序合并方法对数据进行排序。

我建议重新考虑设计，以便使用索引来检索它，或者确保它已经以这种方式排序，因此不需要排序。

【讨论】：

【解决方案6】：

我有一个包含 1000000 个寄存器的 MySQL InnoDB 表。是不是太过分了？

不，1,000,000 行（AKA 记录）对于数据库来说并不算多。

我之所以问，是因为我注意到在具有 100 万个寄存器的表中，某些查询（例如，获取表的最后一个寄存器）比在具有 100 个寄存器的表中要慢（秒）。

这句话有很多要说明的地方。通常的嫌疑人是：

写得不好的查询
不使用主键，假设表上什至存在主键
设计不佳的数据模型（表结构）
缺少索引

【讨论】：

5.过时的服务器规格
@Brimstedt：我也一直认为这个名词应该是“索引”，但我认为我从未见过有人将它用于数据库：从维基百科：en.wikipedia.org/w/… 到 Mr. Coding Horror： codinghorror.com/blog/archives/000638.html。关于这个主题有一个有趣的 SO 帖子：stackoverflow.com/questions/1001366.
6.没有为 innodb 的各种缓存分配足够的内存
是否必须使用 PrimaryKey 以获得更好的性能？如何使用其他键，例如索引、唯一键？我可以用这些吗？谢谢
可能正如 Jason 所说，计算机被内存占用并在处理过程中中断

【解决方案7】：

表越大（因为其中的行越多），如果没有索引，查询通常会运行得越慢。添加正确的索引后，您的查询性能应该会随着表的增长而提高或至少不会降低。但是，如果随着表变大，查询本身返回更多行，那么您将再次开始看到降级。

虽然 1M 行并不多，但它还取决于您在 DB 服务器上有多少内存。如果表太大而无法被服务器缓存在内存中，那么查询会变慢。

【讨论】：

【解决方案8】：

注册？你是说录音吗？

如今，一百万条记录对于数据库来说并不是什么大问题。如果您遇到任何问题，很可能不是数据库系统本身，而是您运行它的硬件。在您用尽硬件之前，您不会遇到数据库问题，很有可能。

现在，显然有些查询比其他查询要慢，但是如果两个非常相似的查询在完全不同的时间运行，您需要弄清楚数据库的执行计划是什么并针对它进行优化，即使用正确的索引、适当的规范化等.

顺便说一句，表中没有“最后”记录这样的东西，从逻辑的角度来看，它们没有内在的顺序。

【讨论】：

我的意思是“SELECT * FROM table ORDER BY id DESC LIMIT 0”
也许你需要SELECT LAST_INSERT_ID() 而不是那个查询。

【解决方案9】：

如果您的意思是 100 万行，那么这取决于您的索引是如何完成的以及您的硬件配置。一百万行对于企业数据库甚至体面设备上的开发数据库来说都不是很大。

如果您的意思是 100 万列（不确定这在 MySQL 中是否可行），那么是的，这似乎有点大，可能会导致问题。

【讨论】：

【解决方案10】：

假设您指的是“寄存器”中的“记录”，不，它并不过分，MySQL 的扩展性非常好，可以在硬盘中容纳尽可能多的记录。

显然搜索查询会更慢。除了确保字段被正确索引之外，真的没有办法解决这个问题。

【讨论】：

从技术上讲，表的大小也可能受到您正在使用的文件系统的最大文件大小的限制。