MySQL表的最大行数是多少
注意：我在这里搜索了其他类似的问题，并且其他回答的问题都没有一点相似。因此... 我有一个关于 MySql 表的问题（更准确地说，是关于表中的特定字段 - 即 tweets 或 updates ）。
那么问题是……InnoDB 表上的最大行数是多少？也就是说，如果 MyIsam、InnoDB 和其他数据库可以容纳的数量之间存在显着差异，如果没有，那么一般而言。 其次，如果表变得非常大，存储数据的最佳实践是什么（同一个表，或拆分/多个表/数据库）？
我读到 Twitter 每天会收到大约 1 亿条推文。在同样的情况下，我的第二个问题如何适用于像 Twitter 这样的东西？
Note: I've searched for other similar Qs here, and none of the other answered questions are even remotely similar.. With that...
I have a question about MySql tables (more precisely, on specific fields from a table- i.e. tweets or updates ).
So the question... what are the maximum amount of rows on an InnoDB table? That is if there is a significant amount of difference between the amounts MyIsam, InnoDB, and others can hold, if there isn't, then, in general.
Secondly, if the table gets really large, what are the best practices for storing the data- (same one table, or split/multiple tables/dbs)?
I read that twitter gets something like 100 million tweets a day. In the same context, how would my second question apply to something like twitter?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
没有行限制，但有大小限制 在 InnoDB 数据库上：
您始终可以通过将行存储在水平分区表中同一个表的多个分区位于多个文件中。
There isn't a row limit, but a size limit on an InnoDB database:
You could always horizontally partition your tables by storing rows in multiple partitions of the same table, in multiple files.
http://dev.mysql.com/doc/refman/5.5 /en/innodb-restrictions.html 将允许您根据密钥大小计算限制。
但我谦虚地建议您不想在具有引用完整性和 InnoDB 的其他功能的事务引擎中存储诸如推文之类的信息，并且您绝对不要将它们全部存储在单个表中数据库实例。您将它们放入大量独立的非 SQL 数据库中，这些数据库允许您快速追加，然后将元信息（如主题标签、RT 等）提取到更复杂的数据库中。 Twitter DB 架构上的演示很容易通过 Google 搜索（例如 http://www.slideshare.net/ nkallen/q-con-3770885）。
如果您必须在一张表中存储大量数据，那么分区是您的朋友，并且 Postgres 可能对此有更好的支持。分区表在物理上是几张逻辑上看起来像一张表的表。您将这些子表（分区）放置到不同的磁盘上，对它们独立运行维护等。此外，“星型模式”具有一个非常长的表，仅包含基本列和多个存储较大但可选列的表。帮助。
http://dev.mysql.com/doc/refman/5.5/en/innodb-restrictions.html will allow you to calculate restrictions from your key size.
But I humbly suggest that you don't want to store info like tweets in a transactional engine with referential integrity and other features of InnoDB, and you definitely don't store them all in one table in a single DB instance. You put them into lots and lots of independent non-SQL databases that allow you to append fast, and then extract meta-information (like hashtags, RTs, etc) into a more complex database. Presentations on Twitter DB architecture are easy to google (e.g. http://www.slideshare.net/nkallen/q-con-3770885).
If you must store large amounts of data in one table, partitioning is your friend, and possibly Postgres has better support for it. A partitioned table is physically several tables that logically look as one table. You put these sub-tables (partitions) to different disks, independently run maintenance on them, etc. Also, a "star schema" with one very long table that contains only essential columns and a number of tables that store bigger but optional columns may help.
表的 64TB 限制有以下例外情况：
innodb_page_size = 16K（默认值）。可以将其设置为 4K 和 64K 之间的 2 的幂，从而按比例更改表空间限制。好的，这只给你一个字节限制。此外，它还包括开销和索引。然后，您需要除以平均记录的大小以获得最大行数。
（计算平均记录大小并不容易。）
简单答案：
您可能可以轻松地在 InnoDB 表中获得 1 万亿条“小”记录。经过一些努力，你可能会达到1000万亿。但我怀疑您的磁盘驱动器预算在此之前就会耗尽。此外，需要数年时间才能完成所有
INSERT才能将其填满！所以，现实的答案是：MySQL 可以处理“无限”数量的行。
现实生活？我听说过有几个表的行数超过10亿行，甚至有150亿行之多。
请参阅我的限制，但它没有说明更多行的问题。
The 64TB limit for a table has the following exceptions:
innodb_page_size = 16K(the default). That can be set to powers of 2 between 4K and 64K, changing the tablespace limit proportionately.PARTITIONedtable is essentially a bunch of 'sub-tables' organized together and acting as one big table. The pre-5.6.7 limit on number of partitions was 1024. After that, it has been 8192. So multiply the 64TB by that.OK, that only gives you a byte limit. Furthermore, it includes overhead, and indexes. You then need to divide by how big an average record is to get the max number of rows.
(It is not easy to compute the average record size.)
Simple answer:
You can probably easily get 1 trillion "small" records in an InnoDB table. With some effort, you might get to 1000 trillion. But I suspect you budget for disk drives would be exhausted before that. Furthermore, it would take years to do all the
INSERTsto fill it up!So, realistic answer: MySQL can handle an 'unlimited' number of rows.
Real life? I have heard of a few tables with more than a billion rows, even as much as 15 billion.
See my Limits, but it does not say more on the question of Rows.