没有限制。它只取决于您的空闲内存和系统最大文件大小。但这并不意味着您不应该采取预防措施来处理数据库中的内存使用问题。始终创建一个脚本，该脚本可以删除不再使用的行，或者将保持特定数字(比如1000)内的行总数。

根据http://dev.mysql.com/doc/refman/5.6/en/features.html中的可伸缩性和限制部分， MySQL支持大型数据库。他们使用MySQL服务器，数据库包含5000万条记录。一些用户使用的MySQL服务器有20万个表和约50亿行。

Mysql int类型可以做相当多的行:http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

Unsigned int的最大值是4294967295 Unsigned bigint的最大值为18,446,744,073,709,551,615

没有限制。它只取决于您的空闲内存和系统最大文件大小。但这并不意味着您不应该采取预防措施来处理数据库中的内存使用问题。始终创建一个脚本，该脚本可以删除不再使用的行，或者将保持特定数字(比如1000)内的行总数。

行大小限制

给定表的最大行大小由以下几个因素决定:

The internal representation of a MySQL table has a maximum row size limit of 65,535 bytes, even if the storage engine is capable of supporting larger rows. BLOB and TEXT columns only contribute 9 to 12 bytes toward the row size limit because their contents are stored separately from the rest of the row. The maximum row size for an InnoDB table, which applies to data stored locally within a database page, is slightly less than half a page. For example, the maximum row size is slightly less than 8KB for the default 16KB InnoDB page size, which is defined by the innodb_page_size configuration option. “Limits on InnoDB Tables”. If a row containing variable-length columns exceeds the InnoDB maximum row size, InnoDB selects variable-length columns for external off-page storage until the row fits within the InnoDB row size limit. The amount of data stored locally for variable-length columns that are stored off-page differs by row format. For more information, see “InnoDB Row Storage and Row Formats”. Different storage formats use different amounts of page header and trailer data, which affects the amount of storage available for rows.

我建议，永远不要删除数据。不要说如果表的长度大于1000，就截断表的末尾。你的计划中需要有真实的业务逻辑，比如这个用户不活跃了多长时间。例如，如果它长于1年，那么将它们放在不同的表中。在维护脚本中，您可能每周或每月都遇到这种情况。

When you run into to many rows in your table then you should start sharding the tables or partitioning and put old data in old tables by year such as users_2011_jan, users_2011_feb or use numbers for the month. Then change your programming to work with this model. Maybe make a new table with less information to summarize the data in less columns and then only refer to the bigger partitioned tables when you need more information such as when the user is viewing their profile. All of this should be considered very carefully so in the future it isn't too expensive to re-factor. You could also put only the users which comes to your site all the time in one table and the users that never come in an archived set of tables.