优化(表分区、索引分区)优化粗略进行表分区，优化是严密的数据分区)。
为什么要把分区列成表？
当一个表的数据量太大时，我们最想做的事情是什么？ 将此表分为两个或多个表，但表仍然是此表，只需分别保存其内容，读取速度就会加快n倍
原理：表数据不能放在文件中，但文件组可以放在文件中，表可以放在文件组中。 这将间接将表数据存储在不同的文件中。 分区可以存储表、索引和大型对象数据。
SQL SERVER 2005引入了表分区的概念。 表中的数据量增加会减慢查询的数据速度，从而降低APP应用程序的性能。 在这种情况下，必须考虑对表进行分区。 如果一个表中的数据较多，则可以将其划分为多个表。 由于扫描的数据较少，因此可以更快地执行查询，从而大大提高性能。 对表进行分区后，逻辑表仍然是完整的表，但只需将表中的数据物理存储在多个表空间(物理文件)中，而不用每次查询数据时都扫描整个表
2.1使用分区表的时间：
1、表格大小超过2GB。
2、表中包含历史数据，新数据将添加到新分区中。
2.2表分区的优缺点
表分区具有以下优点：
1、改善查询性能：查询分区对象只能搜索自己感兴趣的分区，提高了搜索速度。
2、提高可用性：表中某个分区发生故障时，表中其他分区的数据仍然可用；
3、维护方便：有表分区发生故障，需要修复数据，只修复该分区即可；
4、平衡I/O :可以将不同的分区映射到磁盘以平衡I/O，从而提高系统的整体性能。
缺点：
分区表关联：无法将已存在的表直接转换为分区表。 但是，Oracle提供了在线重新定义表的功能。
2.3表格分区操作三步
2.31创建分区函数
createpartitionfunctionxx1(int ) )。
Asrangeleftforvalues (10000，20000 )；
注释：创建分区函数： myRangePF2，按INT类型分区，分为三部分
个区间，10000以内在A 区，1W-2W在B区，2W以上在C区.2.3.2创建分区架构
CREATE PARTITION SCHEME myRangePS2
AS PARTITION xx1
TO (a, b, c);
注释：在分区函数XX1上创建分区架构：myRangePS2，分别为A,B,C三个区间
A,B,C分别为三个文件组的名称，而且必须三个NDF隶属于这三个组，文件所属文件组一旦创建就不能修改
2.3.3 对表进行分区
常用数据规范--数据空间类型修改为：分区方案，然后选择分区方案名称和分区列列表，结果如图所示：
也可以用sql语句生成
CREATE TABLE [dbo].[AvCache]( [AVNote] [varchar](300) NULL, [bb] [int] IDENTITY(1,1) ) ON [myRangePS2](bb);
--注意这里使用[myRangePS2]架构，根据bb分区
2.3.4查询表分区
SELECT *, $PARTITION.[myRangePF2](bb) FROM dbo.AVCache
这样就可以清楚的看到表数据是如何分区的了
2.3.5创建索引分区
优化③：分布式数据库设计
分布式数据库系统是在集中式数据库系统的基础上发展起来的，理解起来也很简单，就是将整体的数据库分开，分布到各个地方，就其本质而言，分布式数据库系统分为两种：1.数据在逻辑上是统一的，而在物理上却是分散的，一个分布式数据库在逻辑上是一个统一的整体，在物理上则是分别存储在不同的物理节点上，我们通常说的分布式数据库都是这种2.逻辑是分布的，物理上也是分布的，这种也成联邦式分布数据库，由于组成联邦的各个子数据库系统是相对“自治”的，这种系统可以容纳多种不同用途的、差异较大的数据库，比较适宜于大范围内数据库的集成。
分布式数据库较为复杂，在此不作详细的使用和说明，只是举例说明一下，现在分布式数据库多用于用户分区性较强的系统中，如果一个全国连锁店，一般设计为每个分店都有自己的销售和库存等信息，总部则需要有员工，供应商，分店信息等数据库，这类型的分店数据库可以完全一致，很多系统也可能导致不一致，这样，各个连锁店数据存储在本地，从而提高了影响速度，降低了通信费用，而且数据分布在不同场地，且存有多个副本，即使个别场地发生故障，不致引起整个系统的瘫痪。 但是他也带来很多问题，如：数据一致性问题、数据远程传递的实现、通信开销的降低等，这使得分布式数据库系统的开发变得较为复杂，只是让大家明白其原理，具体的使用方式就不做详细的介绍了。
优化④：整理数据库碎片
如果你的表已经创建好了索引，但性能却仍然不好，那很可能是产生了索引碎片，你需要进行索引碎片整理。
什么是索引碎片?
由于表上有过度地插入、修改和删除操作，索引页被分成多块就形成了索引碎片，如果索引碎片严重，那扫描索引的时间就会变长，甚至导致索引不可用，因此数据检索操作就慢下来了。
如何知道是否发生了索引碎片?
在SQLServer数据库，通过DBCC ShowContig或DBCC ShowContig(表名)检查索引碎片情况，指导我们对其进行定时重建整理。
通过对扫描密度(过低)，扫描碎片(过高)的结果分析，判定是否需要索引重建，主要看如下两个：
Scan Density [Best Count:Actual Count]-扫描密度[最佳值:实际值]：DBCC SHOWCONTIG返回最有用的一个百分比。这是扩展盘区的最佳值和实际值的比率。该百分比应该尽可能靠近100%。低了则说明有外部碎片。
Logical Scan Fragmentation-逻辑扫描碎片：无序页的百分比。该百分比应该在0%到10%之间，高了则说明有外部碎片。
解决方式：
一是利用DBCC INDEXDEFRAG整理索引碎片
二是利用DBCC DBREINDEX重建索引。
两者区别调用微软的原话如下：
DBCC INDEXDEFRAG 命令是联机操作，所以索引只有在该命令正在运行时才可用，而且可以在不丢失已完成工作的情况下中断该操作。这种方法的缺点是在重新组织数据方面没有聚集索引的除去/重新创建操作有效。
重新创建聚集索引将对数据进行重新组织，其结果是使数据页填满。填满程度可以使用 FILLFACTOR 选项进行配置。这种方法的缺点是索引在除去/重新创建周期内为脱机状态，并且操作属原子级。如果中断索引创建，则不会重新创建该索引。也就是说，要想获得好的效果，还是得用重建索引，所以决定重建索引。
转载于:https://blog.51cto.com/11085795/1744295