数据库有点大， 300GB， 用的Windows Azure 存放在一个磁盘的盘驱，性能比较差。 现在计划多加几个磁盘，Windows Azure 限制1个磁盘只有500 IOPS／秒， 现在是有2核物理cpu，逻辑的8个cpu， 再加3个磁盘应该行了吧？
加了后，如何规划文件组呢？ 方法如下：
1. 不新建文件组，只往主文件组里面添加3个ndf文件分布在其他磁盘，
2. 还是新建1个文件组，然后新建3个ndf分别分布在其他磁盘？
3. 还是新建3个文件组，再每一个有一个ndf 分布在其他磁盘？
另外，平时的读写很频繁，如果整个db 作online rebuild索引， 一般多长时间运行一次呢？ 有了online rebuild索引，是否还需要更新统计信息的job执行？
------解决方案--------------------
一个文件组放3个文件，和3个文件组，分别放1个文件，是有区别的。
前一种，会把数据比较平均的放到三个文件，而后一种，就是只能放到一个文件中。
建议用第一种把。
------解决方案--------------------
建议：
1. ndf, mdf 都是物理数据文件，是没有区别的。filegroup只是逻辑文件区分。物理文件是需要IO 分布，提高paralled IO. 例如 如果是物理服务器，日志文件和数据文件放在独立的drive，drive挂接独立的磁盘。如果是虚拟服务器的话，需要dedeicated LUN /raw disk mapping
2. Microsoft建议对index碎片>30%的索引进行online rebuild. 尤其是对大表。这是SQL内部碎片进行整理。还可以对物理磁盘进行外部的磁盘碎片整理。索引的整理是有维护开销的,相对于开销和性能获得，每晚对索引碎片>30%的大表进行索引整理还是很值得的。
3. 理论上SQL对 >20% underlying table update 进行auto statistic update; index rebuild的时候statistic 也同时进行100% sample更新。如果你查看execution plan发现actual row count 和estimated row count有很大差距，那么statistic太老了。你也可以通过MDV查看hot table的统计更新last date， 数据变化率，设置规则：对1周没有更新或者当日数据变化超过10%的"大表"进行夜间的统计更新。尤其是大表auto statistic update不大会发生，20% threadhold显的太大。
------解决方案--------------------
online rebuild要消耗tempdb的资源，这个如果是瓶颈，把tempdb独立一个盘，并且大小增加一点，也可以分4个tempdb数据文件。
如果你搞多个盘，可以把数据文件平均分到每个盘，加大并行读写特性。日志文件独立丢一个盘，这是理想化的配置。能否实现要看你的现有资源的瓶颈所在
------解决方案--------------------
图简单，就一个文件组，3个文件。图最优效率，就3个文件组。。但要仔细分布表等，比较费事儿
各有优缺点，不同情况，不同选择。
通常，应该从设计及开发代码质量上优化效率，那是正道及重点处