blocks|key|1163907|text|假设你说的“记录”指的是“寄存器”不，它不是太多，MySQL的伸缩性真的很好，并且可以在你的硬盘上容纳尽可能多的记录。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1163908|显然，搜索查询的速度会更慢。除了确保字段被正确编入索引之外，实际上没有其他方法。|1163909|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Assuming you mean "records" by "registers" no, it's not too much, MySQL scales really well and can hold as many records as you have space for in your hard disk.

Obviously though search queries will be slower. There is really no way around that except making sure that the fields are properly indexed.

blocks|key|1378994|text|如果你指的是一百万行，那么这取决于你的索引是如何完成的，以及你的硬件的配置。对于一个企业数据库来说，一百万行并不是一个很大的数量，甚至对于一个像样的设备上的开发数据库来说也不是一个大数目。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1378995|如果你指的是一百万列(甚至不确定这在MySQL中是不可能的)，那么是的，这看起来有点大，可能会导致问题。|1378996|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you mean 1 million rows, then it depends on how your indexing is done and the configuration of your hardware. A million rows is not a large amount for an enterprise database, or even a dev database on decent equipment.

if you mean 1 million columns (not sure thats even possible in MySQL) then yes, this seems a bit large and will probably cause problems.

blocks|key|1164038|text|注册？你是说唱片吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1164039|如今，对于一个数据库来说，一百万条记录并不是什么大问题。如果您遇到任何问题，很可能不是数据库系统本身，而是运行它的硬件。在硬件耗尽之前，您很可能不会遇到DB的问题。|1164040|现在，一些查询显然比其他查询慢，但如果两个非常相似的查询在非常不同的时间运行，您需要找出数据库的执行计划并对其进行优化，即使用正确的索引、适当的规范化等。|1164041|顺便说一句，表中没有“最后”记录这样的东西，从逻辑的角度来看，它们没有固有的顺序。|1164042|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Register? Do you mean record?

One million records is not a real big deal for a database these days. If you run into any issue, it's likely not the database system itself, but rather the hardware that you're running it on. You're not going to run into a problem with the DB before you run out of hardware to throw at it, most likely.

Now, obviously some queries are slower than others, but if two very similar queries run in vastly different times, you need to figure out what the database's execution plan is and optimize for it, i.e. use correct indexes, proper normalization, etc.

Incidentally, there is no such thing as a "last" record in a table, from a logical standpoint they have no inherent order.

blocks|key|1379112|text|表越大(如表中的行数越多)，如果没有索引，查询通常会运行得越慢。一旦添加了正确的索引，您的查询性能应该会提高，或者至少不会随着表的增长而降低。但是，如果查询本身随着表的变大而返回更多的行，那么您将开始再次看到性能下降。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1379113|虽然1M行并不是很多，但这也取决于您在DB服务器上有多少内存。如果表太大，服务器无法将其缓存在内存中，那么查询将变慢。|1379114|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The larger the table gets (as in more rows in it), the slower queries will typically run if there are no indexes. Once you add the right indexes your query performance should improve or at least not degrade as much as the table grows. However, if the query itself returns more rows as the table gets bigger, then you'll start to see degradation again.

While 1M rows are not that many, it also depends on how much memory you have on the DB server. If the table is too big to be cached in memory by the server, then queries will be slower.

blocks|key|1164154|text|使用提供的查询将非常慢，因为使用排序合并方法对数据进行排序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1164155|我建议重新考虑设计，这样你就可以使用索引来检索它，或者确保它已经以这种方式排序，所以不需要排序。|1164156|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Using the query provided will be exceptionally slow because of using a sort merge method to sort the data.

I would recommend rethinking the design so you are using indexes to retrieve it or make sure it is already ordered in that manner so no sorting is needed.

blocks|key|1379226|text|使用'explain‘检查您的查询，查看查询计划是否有任何错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1379227|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Use 'explain' to examine your query and see if there is anything wrong with the query plan.

blocks|key|1379266|text|我见过具有数十亿(索引)记录的非分区表，它们自连接以进行分析工作。我们最终对这个东西进行了分区，但老实说，我们并没有看到太多的区别。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1379267|也就是说，这是在甲骨文中，我还没有在MySQL中测试过那么多的数据。索引是您的朋友:)|1379268|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I've seen non-partitioned tables with several billion (indexed) records, that self-joined for analytical work. We eventually partitioned the thing but honestly we didn't see that much difference. 

That said, that was in Oracle and I have not tested that volume of data in MySQL. Indexes are your friend :)

I've a MySQL InnoDB table with 1,000,000 records. Is this too much? Or databases can handle this and more? I ask because I noticed that some queries (for example, getting the last row from a table) are slower (seconds) in the table with 1 millon rows than in one with 100.

How many rows in a database are TOO MANY?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

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

问数据库中有多少行是太多？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问数据库中有多少行是太多？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问数据库中有多少行是太多？
EN