何时开始担心数据库表中的行
我正在构建一个会快速增长的数据库。有些表在一年内将包含数百万行。我什么时候应该开始担心数据库大小？
3000万行的表无法处理吗？这通常是如何解决的？
I'm constructing a database that will grow fast. Some tables will contain several millions of rows within a year. When should I start to worry over the database size?
Is a table with 30 million rows impossible to handle? How is this usually solved?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
几百万行并不算大。为查询工作负载创建适当的索引将使事情变得更快。
SQL Server 的（松散）经验法则是您应该考虑在 20 - 3000 万行左右进行分区。 [假设您在生产环境中拥有 SQL Server 企业版。但分区并不总是解决方案。]
分区表和索引概念
分区表和索引策略使用 SQL Server 2008
<一个href="http://www.brentozar.com/archive/2008/06/sql-server-partitioning-not-the-answer-to-everything/" rel="nofollow">SQL Server 分区：不是最佳实践对于一切
Several million rows is not that large. Creating appropriate indexes for your query work load will keep things fast.
The (loose) rule of thumb with SQL Server is that you should consider partitioning at around the 20 - 30 million row mark. [Assuming you have Enterprise Edition of SQL Server in Production. But partitioning is not always the solution.]
Partitioned Table and Index Concepts
Partitioned Table and Index Strategies Using SQL Server 2008
SQL Server Partitioning: Not the Best Practices for Everything
正确调整的表可以处理数十亿行，所以不用担心 8-)
我的生产项目中有几个表与 >每个 15 亿行
但是 - 是的！
处理和维护这些表需要更多时间
Properly tuned tables can handle billions of rows, so don't worry 8-)
I have several tables in my production project with > 1.5 billion rows each
BUT - yes!
Its taking more time to handle and maintain these tables