提高数据库性能的提示,大小超过40 GB(Sql Server 2005),每月增长约3GB

Question

当前的数据库或我们的项目本月已超过40 GB,平均每月增长约3 GB.现在所有表都是最佳规范化的,并且已经使用了正确的索引.但是随着规模的不断扩大,即使是从表格中选择"计数(1)"等基本查询也需要更多的时间.那么你可以分享一些有助于这方面的要点.数据库是Sql Server 2005.此外,如果我们实现分区,它不会创建开销吗？

提前致谢.

Answer 1

1. 确保你有合适/适当的索引
2. 确保你有一个很好的索引维护策略(例如,重建/碎片整理/保持统计数据是最新的,以确保索引保持良好的性能)
3. 识别性能不佳的查询并对其进行优化(可能在性能问题未显示时针对小数据量编写/测试)
4. 考虑对数据进行分区(例如,如果你有Enterprise Edition,SQL 2005及以后版本就支持分区).编辑:详细说明SQL Server分区,我完全建议阅读这篇 MSDN文章,了解其中的主题和方法.总的来说,Randy Shoup(eBay架构师)在QCon 2008上也就可扩展性进行了很好的讨论,其中关于扩展系统的一个关键点是分区.这里总结了一下.
5. 你的数据库服务器硬件足够吗？它可以从更多的记忆中受益吗？ 编辑:用您的硬件信息查看您的评论,我认为您可以(至少)在其中投入更多内存
6. 你可能会受益于一些非规范化.在不知道确切的数据库结构的情况下很难具体,但是非规范化可能会以牺牲数据复制/磁盘空间为代价来改进某些查询

Answer 2

如今,40 GB的数据库绝不算是一个大数据库.每月3 GB的增长也不例外.

但是,在这些区域中,您必须要小心一些可能在较小的数据库中使用的小东西.由于您撰写了关于发出"SELECT COUNT(1)..."查询的文章,因此您可能需要考虑是否需要此类查询.这听起来像是"在表中显示行数"类型的功能.你真的需要这种你称之为"基本查询"的东西,还是你可以不用？特别考虑这个问题:你是否需要结果准确或者它是否也是一个"好估计"？如果是这样,你可能想在这里和那里抛出一个WITH(NOLOCK)提示,其中精度不是强制性的.但是,明智地使用NOLOCK,因为它将以令人难以置信的速度返回错误的数据.:-)

AdaTheDev已经提到了很多好的建议,请给我一点:

没有什么比声音和可靠的架构更好的性能.而且,谁知道,在您设计架构时可能认为合适的东西,可能需要在生产一段时间后进行修改.对于指数尤其如此.