我是一名开发人员，需要一些DBAbuild议。
我们开始得到一个MSSQL2005数据库的性能问题。 事件的可见效应主要是服务器上的CPU占用率，但是操作报告说，这也是从SAN中耗尽资源（并不总是）。 问题的主要来源在某些应用程序中是肯定的，但是我想知道是否应该划分一些主要的表来缓解I / O压力。
一个文件中的基数约为60GB。
主表（订单）有2.1百万行215科朗（但没有巨大的）。
我们有一个整数作为PK，所以应该可以定义一个分区函数。
我们会用分区来赢得一些东西吗？ 将分区索引给我们买东西？
这里是关于数据库和表格的一些更多的事实
database_name database_size unallocated space My_base 57173.06 MB 79.74 MB reserved data index_size unused 29 444 808 KB 26 577 320 KB 2 845 232 KB 22 256 KB name rows reserved data index_size unused Order 2 097 626 4 403 832 KB 2 756 064 KB 1 646 080 KB 1688 KB 大教堂
呃 – 为什么？ 15年前，100万行被认为是小的。 今天，1亿行被认为是小的。
如果你有一个CPU热，我会开始寻找问题是什么 – 这看起来更像是一个索引问题和/或糟糕的领域devise比其他任何东西。
现在，SAN垃圾邮件 – 这对任何SQL Server来说都是正常的。 对于数据库服务器IO重的事实，SAN人通常是极其无知的。 数据库通常需要为其优化的特定SAN设置，并且可以充分利用它们。 它不是“霸占”它试图尽可能地利用所有的资源。
你的数据库很小 – 认真。 这里我没有看到任何问题。 订单表只有4GB的内存，这是足够有趣的 – 是应该从内存回答的大小。
分区是有用的大规模删除（每年一个表，一年的订单是一个表截断，而不是一个删除），但与您的大小这是一个没有问题（我有一个表价格有大约15亿条目，这是小）。 它不会加速查询很多 – 要么查询可以select只有一个分区（和不，整数PK没有帮助，除非你selectPK范围作为filter） – 或它不能。 但即使可以，指数也几乎一样快。
什么types的查询是坏的？ 执行计划如何？ 可能是你：
内存太less（8GB或以上？）
有一个不理想的/不匹配的索引布局，以便查询基本变成表扫描？ 在这种情况下，我会开始修理那边。
你加载的数据比你需要的多吗？
没有你的查询执行计划，这是无法回答的。
顺便说一下，一个文件中的60GB是严重的忽视。 任何大小的数据库应该有尽可能多的文件，因为有可能的并行操作（即SQL Server可用的服务器核心）;）我相信你的IO是组织严重 – 不alignment的分区，不好的格式化，放慢你很多 – 糟糕的光盘设置可能会让你的性能高达40％）。
放松IO压力：
确保你的数据库服务器安装正确（我很less看到一个 – pipe理员似乎喜欢忽略她的文档）
首先确保你有适当的资源。 光盘子系统上的IOPS预算有多高？ 你是否衡量它，或？
确保数据库设置正确（再次，大多数pipe理员喜欢在这种情况下是无知的）
确保你有一个好的表格结构和良好的主键（几乎是唯一的东西你有权利）。
然后 – 进入分析器，找出应用程序，并确保这个查询是优化的。