数据库中有多少行？

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

我有一个带有1000000个寄存器的MySQL InnoDB表。这太多了吗？

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

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

该声明有很多要说明的地方。通常的嫌疑人是：

1. 写得不好的查询
2. 假设表上甚至存在一个主键，则不使用主键
3. 设计不良的数据模型（表结构）
4. 缺乏索引

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

只要记住定义和改进表索引即可。

因此，很明显1,000,000不是很多！（但是如果您不编制索引，是的，这是很多）

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

我认为这是一个普遍的误解-在数据库可伸缩性方面，大小只是方程式的一部分。还有其他一些困难（或更难解决）的问题：

• 工作集有多大（即需要将多少数据加载到内存中并进行有效处理）。如果您只是插入数据，然后不执行任何操作，则实际上这是一个容易解决的问题。

• 需要什么级别的并发？是只有一个用户在插入/读取数据，还是我们有成千上万的客户端同时运行？

• 需要什么级别的承诺/耐久性和性能一致性？我们是否必须确保我们能够兑现每次承诺。如果平均交易速度快，还是可以确保所有交易速度都快（六个sigma质量控制，例如-http: //www.mysqlperformanceblog.com/2010/06/07/performance-optimization-和6-sigma /）。

• 您是否需要执行任何操作问题，例如更改表架构？在InnoDB中，这是可能的，但是却非常慢，因为它通常必须在前台创建一个临时表（阻止所有连接）。

因此，我要说明的两个限制问题将是：

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

如果您指的是一百万行，那么这取决于索引的完成方式和硬件的配置。一百万行对于一个企业数据库，甚至对于像样的设备的开发数据库来说，都不是很大的数目。

如果您的意思是一百万个列（不确定在MySQL中甚至可能），那么是的，这似乎有点大，并且可能会引起问题。

寄存器？你是说记录吗？

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

现在，显然某些查询要比其他查询慢，但是如果两个非常相似的查询在截然不同的时间运行，则需要找出数据库的执行计划并对其进行优化，即使用正确的索引，适当的规范化等。

顺便说一句，从逻辑上看，它们没有固有的顺序，因此在表中没有“最后”记录之类的东西。

我已经看到了具有数十亿个（索引）记录的非分区表，这些表可以自动进行分析工作。我们最终将东西分开了，但是说实话，我们并没有太大的区别。

就是说，那是在Oracle中进行的，而我还没有在MySQL中测试过该数据量。索引是你的朋友:)

假设您是用“寄存器”来表示“记录”，那不是太多，MySQL的扩展性很好，可以在硬盘中容纳尽可能多的记录。

显然，尽管搜索查询会变慢。除了确保正确索引字段外，实际上没有其他方法可以解决。

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

虽然1M行不是很多，但这还取决于数据库服务器上有多少内存。如果表太大而无法由服务器缓存在内存中，则查询将变慢。

由于使用排序合并方法对数据进行排序，因此使用提供的查询会格外缓慢。

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