我还有very large table in SQL Server（2008 R2开发人员版）存在一些性能问题。
我想知道另一个DBMS是否会更好地处理大型表。我主要只考虑以下系统：SQL Server 2008，MySQL和PostgreSQL 9.0。
或者，正如上面引用的问题所述，表的大小和性能主要是索引和缓存的一个因素吗？
此外，更大的正常化会提高性能还是会阻碍它？
编辑：
下面的评论之一声称我含糊不清。我有超过2000万行（20年的库存数据和2年的期权数据），我试图弄清楚如何将性能提高一个数量级。我只关心读/计算性能;我不关心写性能。唯一的写操作是在数据刷新期间，那些是BulkCopy。
我已经有了一些索引，但希望我做错了，因为我需要加快速度。我也需要开始查看我的查询。
提供的评论和答案已帮助我了解如何开始分析我的数据库。我是程序员，而不是DBA（因此 Marco的书推荐是完美的）。我没有那么多的数据库经验，我以前从未对数据库进行过分析。我会尝试这些建议并在必要时报告。谢谢！
答案 0 :(得分：11)
80M行不大。您只需要学习如何设计和查询该大小的数据。其中可能包括规范化，非规范化，聚类，索引，但往往权衡它们看起来更深。添加索引实际上会损害性能，即使是读取，例如，如果优化程序不够好或者判断错误的统计信息。
我建议你阅读Refactoring SQL Applications，因为它不是来自“数据库调谐器”而是来自开发人员的角度来解决问题。
本书由The Art of SQL的作者撰写，并在许多场景下对Oracle，SQL Server和MySQL进行了比较。这是务实的，并带有一些有用的图表。
除非被迫，否则我会远离MySQL。根据“摇滚”的几个定义，Postgres 9.0摇滚，但我仍然会在生产中使用8.4几个月。
如果您希望人们帮助您使用此表，请提供尽可能多的详细信息：架构，索引，数据分布，使用模式等。
答案 1 :(得分：4)
切换DBMS不是解决方案。
有多大？ 它有什么指数？
如果真的那么大那么你能分区吗？
答案 2 :(得分：4)
距离最大化SQL Server还有很长的路要走。如果您没有解决作为性能问题根源的设计和索引问题，您最终会将它们移植到不同的平台。
没有一个银弹解决方案可以“让数据库快速运行”，否则很多DBA都会失业。您只需要进行一些性能分析并对您的数据库设计和索引策略进行微调，以使性能符合您的要求。
抱歉，确实没有捷径。
如果你提供有关在性能和基础表结构/索引方面存在问题的查询的更多细节，我敢打赌SO上的聪明人将能够提供一些指导。
答案 3 :(得分：1)
我认为simpledb是你的选择。考虑到亚马逊将其用于平台。
答案 4 :(得分：1)
刚看到这个。你需要查看infobright.org。对于数字计算，它很棒。它为mysql提供了一个数据库引擎，但是为了分析而不是事务性更新而构建。
你唯一的问题是你的数据集对于infobright来说有点小，但应该可以正常工作。
答案 5 :(得分：0)
大多数真正大公司，银行，军队，政府委托大量数据的两个数据库产品是 Oracle 和 DB2 。两者都带有适当的价格标签。这两种产品都经过了数十年的密集专业调整，尽管这些优势通常只适用于那些为高级顾问提供法案的人（另外！）。我有一位朋友，他是这样的DB2顾问;他指责一只胳膊和一条腿但是通过其他人不会考虑的措施获得了惊人的性能提升。
这些都不在你的短名单中，所以你很可能不会考虑它们。我怀疑任何其他产品也可以处理你的负载，虽然我对微软产品有些不信任。所以......考虑到这只是信息的信息。