A. 如何检查sql数据库索引填充因子是否产生碎片以及如何处理
这是收藏的一些资料：
SQLServer提供了一个数据库命令――DBCC SHOWCONTIG――来确定一个指定的表或索引是否有碎片。
示例：
显示数据库里所有索引的碎片信息
DBCC SHOWCONTIG WITH ALL_INDEXES
显示指定表的所有索引的碎片信息
DBCC SHOWCONTIG (authors) WITH ALL_INDEXES
显示指定索引的碎片信息
DBCC SHOWCONTIG (authors,aunmind)
DBCC 执行结果：
扫描页数：如果你知道行的近似尺寸和表或索引里的行数，那么你可以估计出索引里的页数。看看扫描页数，如果明显比你估计的页数要高，说明存在内部碎片。
扫描扩展盘区数：用扫描页数除以8,四舍五入到下一个最高值。该值应该和DBCC SHOWCONTIG返回的扫描扩展盘区数一致。如果DBCC SHOWCONTIG返回的数高，说明存在外部碎片。碎片的严重程度依赖于刚才显示的值比估计值高多少。
扩展盘区开关数：该数应该等于扫描扩展盘区数减1。高了则说明有外部碎片。
每个扩展盘区上的平均页数：该数是扫描页数除以扫描扩展盘区数，一般是8。小于8说明有外部碎片。
扫描密度［最佳值:实际值］：DBCC SHOWCONTIG返回最有用的一个百分比。这是扩展盘区的最佳值和实际值的比率。该百分比应该尽可能靠近100％。低了则说明有外部碎片。
逻辑扫描碎片：无序页的百分比。该百分比应该在0％到10％之间，高了则说明有外部碎片。
扩展盘区扫描碎片：无序扩展盘区在扫描索引叶级页中所占的百分比。该百分比应该是0％，高了则说明有外部碎片。
每页上的平均可用字节数：所扫描的页上的平均可用字节数。越高说明有内部碎片，不过在你用这个数字决定是否有内部碎片之前，应该考虑fill factor（填充因子）。
平均页密度（完整）：每页上的平均可用字节数的百分比的相反数。低的百分比说明有内部碎片。
解决碎片问题 ：
1. 删除并重建索引
2. 使用DROP_EXISTING子句重建索引
3. 执行DBCC DBREINDEX
4. 执行DBCC INDEXDEFRAG
删除并重建索引 ：
用DROP INDEX和CREATE INDEX或ALTER TABLE来删除并重建索引有些缺陷包括在删除重建期间索引会消失。在索引删除重建时，对于查询它不在可用，查询性能也许会受到明显的影响，直到重建索引为止。另一个潜在的缺陷是当都请求索引的时候会引起阻塞，直到重建索引为止。通过其他的处理也能解决阻塞，就是索引被使用的时候不删除索引。另一个主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引时会引起非聚集索引重建两次。删除聚集索引时非聚集索引的行指针会指向数据堆，聚集索引重建时非聚集索引的行指针又会指回聚集索引的行位置。
删除并重建索引的确有一个好处就是通过重新排序索引页，使索引页紧凑并删除不需要的索引页来完全重建索引。你也许需要考虑那些内部和外部碎片都很高的情况下才使用，以使那些索引回到它们应该在的位置。
使用DROP_EXISTING子句重建索引 ：
为了避免在重建聚集索引时表上的非聚集索引重建两次，可以使用带DROP_EXISTING子句的CREATE INDEX语句。这个子句会保留聚集索引键值，以避免非聚集索引重建两次。和删除并重建索引一样，该方法也可能会引起阻塞和索引消失的问题。该方法的另一个缺陷是也强迫你去分别发现和修复表上的每一个索引。
除了和上一个方法一样的好处之外，该方法的好处是不必重建非聚集索引两次。这样可以对那些带约束的索引提供正确的索引定义以符合约束的要求。
执行DBCC DBREINDEX ：
DBCC DBREINDEX类似于第二种方法，但它物理地重建索引，允许SQLServer给索引分配新页来减少内部和外部碎片。DBCC DBREINDEX也能动态的重建带约束的索引，不象第二种方法。
DBCC DBREINDEX的缺陷是会遇到或引起阻塞问题。DBCC DBREINDEX是作为一个事务来运行的，所以如果在完成之前中断了，那么你会丢失所有已经执行过的碎片。
执行DBCC INDEXDEFRAG ：
DBCC INDEXDEFRAG（在SQLServer2000中可用）按照索引键的逻辑顺序，通过重新整理索引里存在的叶页来减少外部碎片，通过压缩索引页里的行然后删除那些由此产生的不需要的页来减少内部碎片。它不会遇到阻塞问题但它的结果没有其他几个方法彻底。这是因为DBCC INDEXDEFRAG跳过了锁定的页且不使用任何新页来重新排序索引。如果索引的碎片数量大的话你也许会发现DBCC INDEXDEFRAG比重建索引花费的时间更长。DBCC INDEXDEFRAG比其他方法的确有好处的是在其他过程访问索引时也能进行碎片整理，不会引起其他方法的阻塞问题。
B. 如何用sql语句在列上建立聚集索引
可以用如下语句
create clustered index 索引名 on 表名(字段名)
C. sql 自动创建的主键索引 可以删除吗
1. 首先删除主键, 然后重新创建主键,
重新创建主键的时候, 需要说明本主键是使用 非聚集索引
PRIMARY KEY NONCLUSTERED ( sno )
D. SQL中怎么删除由creat table命令创建的primary key 约束索引
1.在聚集索引中，表中各行的物理顺序和键值的逻辑（索引）顺序相同。非聚集索引则不相同。因此聚集索引比非聚集索引有更快的数据访问速度。因为其键值的逻辑（索引）顺序即为物理顺序。
2.同一张表里只能有一个聚集索引，而可以有多个非聚集索引
3.当你没有设置聚集索引的时候，就设置主键的话，会默认把主键所在的列设置为聚集索引
反之则不会设置为聚集索引
E. 删除索引的sql语句
删除索引可以使用ALTER TABLE或DROP INDEX语句来实现。DROP INDEX可以在ALTER TABLE内部作为一条语句处理，其格式如下：
drop index index_name on table_name ;
alter table table_name drop index index_name ;
alter table table_name drop primary key ;
其中，在前面的两条语句中，都删除了
F. SQL2008中索引类型为聚集,非聚集,主XML,空间各是什么意思
聚集索引：表中存储的数据按照索引的顺序存储，检索效率比普通索引高，但对数据新增/修改/删除的影响比较大。
非聚集索引：不影响表中的数据存储顺序，检索效率比聚集索引低，对数据新增/修改/删除的影响很小。
一张表只有一个聚簇索引，可有多个非聚簇索引。
G. 删除索引的sql语句是(
先选择该索引。右键看看哪些表对该索引有依赖。解除依赖。再用Drop Index 索引名 删除
alter table tableName drop index indexName
用delete 语句可以删去，但是在栓去之前的解除表之间的关系。
H. 用SQL sever时，出现”无法对 表 'C23' 创建多个聚集索引。“怎么解决
SQL server 里面， 一个表 最多只能有一个 聚集索引。
默认情况下， 主键是 聚集索引。
因此，2条路。
1. 修改你创建索引的语句， 把那个 聚集 的关键字删除掉。 这样就默认创建一个 非聚集索引。
2. 删除主键，并重建之， 创建主键的时候， 加上 “非聚集”的关键字。 然后就可以创建你的聚集索引了。
I. sql server执行计划 怎么看消耗资源
扫描：逐行遍历数据。
先建立一张表，并给大家看看大概是什么样子的。
CREATE TABLE Person(
Id int IDENTITY(1,1) NOT NULL,
Name nvarchar(50) NULL,
Age int NULL,
Height int NULL,
Area nvarchar(50) NULL,
MarryHistory nvarchar(10) NULL,
EcationalBackground nvarchar(10) NULL,
Address nvarchar(50) NULL,
InSiteId int NULL
) ON [PRIMARY]
表中的数据14万左右，大概类似下面这样：
此表，暂时没有任何索引。
一、数据访问操作
1、表扫描
表扫描:发生于堆表，并且没有可用的索引可用时，会发生表扫描,表示整个表扫描一次。
现在，我们来对此表执行一条简单的查询语句：
SELECT * From Person WHERE Name = '公子'
查看执行计划如下：
表扫描，顾名思义就是整张表扫描，找到你所需要的数据了。
2、聚集索引扫描
聚集索引扫描：发生于聚集表，也相当于全表扫描操作，但在针对聚集列的条件如(WHERE Id > 10)等操作时，效率会较好。
下面我们在Id列来对此表加上一个聚集索引
CREATE CLUSTERED INDEX IX_Id ON Person(Id)
再次执行同样的查询语句：
SELECT * From Person WHERE Name = '公子'
执行计划如下：
为什么建的聚集索引在Id列，会对扫描有影响呢？更何况与Name条件也没关系啊？
其实，你加了聚集索引之后，表就由堆表变成了聚集表。我们知道聚集表的数据存在于聚集索引的叶级节点。因此，聚集扫描与表扫描其实差别不大，要说差别大，也得看where条件里是什么，以后返回的数据。就本条SQL语句而言，效率差别并不大。
可以看看I/O统计信息：
表扫描：
聚集索引扫描：
此处超出本文范畴了，效率不在本文考虑范围内，本文只考虑的是，各种扫描的区别，以及为何会产生。
3、聚集索引查找
聚集索引查找：扫描聚集索引中特定范围的行。
看执行以下SQL语句：
SELECT * FROM Person WHERE Id = '73164'
执行计划如下:
4、索引扫描
索引扫描：整体扫描非聚集索引。
下面我们来添加一个聚集索引，并执行一条查询语句：
CREATE NONCLUSTERED INDEX IX_Name ON Person(Name) --创建非聚集索引
SELECT Name FROM Person
查看执行计划如下：
为什么此处会选择索引扫描(非聚集索引)呢？
因为此非聚集索引能够覆盖所需要的数据。如果非聚集索引不能覆盖呢?例如，我们将SELECT改为SELECT *再来看看。
好明显，返回结果所包括的记录太多，用非聚集索引反而不合算。因此使用了聚集索引。
如果此时我们删除聚集索引，再执行SELECT *看看。
DROP INDEX Person.IX_Id
而此时没有聚集索引，所以只有使用表扫描。
5、书签查找
前面关于索引的学习我们已经知道，当在非聚集索引中并非覆盖和包含所需全部的列时，SQL Server会选择，直接进行聚集索引扫描获得数据，还是先去非聚集索引找到聚集索引键，然后利用聚集索引找到数据。
下面来看一个书签查找的示例：
SELECT * FROM Person WHERE Name = '胖胖'--Name列有非聚集索引
执行计划如下：
上面的过程可以理解为：首先通过非聚集索引找到所求的行，但这个索引并不包含所有的列，因此还要额外去基本表中找到这些列，因此要进行键查找，如果基本表是以堆进行组织的，那么这个键查找(Key Lookup)就会变成RID查找(RID Lookup),键查找和RID查找统称为书签查找。不过有时当非聚集索引返回的行数过多时，SQL Server可能会选择直接进行聚集索引扫描了。
二、流聚合操作
1、流聚合
流聚合：在相应排序的流中，计算多组行的汇总值。
所有的聚合函数(如COUNT(),MAX())都会有流聚合的出现，但是其不会消耗IO，只有消耗CPU。
例如执行以下语句：
SELECT MAX(Age) FROM Person
查看执行计划如下：
2、计算标量
计算标量：根据行中的现有值计算新值。比如COUNT()函数，多一行，行数就加1咯。
除MIN和MAX函数之外的聚合函数都要求流聚合操作后面跟一个计算标量。
SELECT COUNT(*) FROM Person
查看执行计划如下：
3、散列聚合(哈希匹配)
对于加了Group by的子句，因为需要数据按照group by 后面的列有序，就需要Sort来保证排序。注意,Sort操作是占用内存的操作，当内存不足时还会去占用tempdb。SQL Server总是会在Sort操作和散列匹配中选择成本最低的。
SELECT Height,COUNT(Id) FROM Person --查出各身高的认输
GROUP BY Height
执行计划如下：
对于数据量比较大时，SQL Server选择的是哈希匹配。
在内存中建立好散列表后，会按照group by后面的值作为键，然后依次处理集合中的每条数据，当键在散列表中不存在时，向散列表添加条目，当键已经在散列表中存在时，按照规则（规则是聚合函数，比如Sum,avg什么的）计算散列表中的值（Value）。
4、排序
当数据量比价少时，例如执行以下语句，新建一个只有数十条记录的与Person一样的表。
SELECT * INTO Person2 FROM Person2
WHERE Id < 100
再来执行同样的查询语句：
SELECT Height,COUNT(Id) FROM Person2 --只是表换成了数据量比较少的表
GROUP BY Height
执行计划如下：
三、连接
当多表连接时(包括书签查找，索引之间的连接)，SQL Server会采用三类不同的连接方式：循环嵌套连接，合并连接，散列连接。这几种连接格式有适合自己的场景，不存在哪个更好的说法。
新建两张表如下
这是一个简单的新闻，栏目结构。
1、嵌套循环
先来看一个简单的Inner Join查询语句
SELECT * FROM Nx_Column AS C
INNER JOIN Nx_Article AS A
ON A.ColumnId = C.ColumnId
执行计划如下：
循环嵌套连接的图标同样十分形象，处在上面的外部输入(Outer input)，这里也就是聚集索引扫描。和处在下面的内部输入(Inner Input),这里也就是聚集索引查找。外部输入仅仅执行一次，根据外部输入满足Join条件的每一行，对内部输入进行查找。这里由于是7行，对于内部输入执行7次。
根据嵌套循环的原理不难看出，由于外部输入是扫描，内部输入是查找，当两个Join的表外部输入结果集比较小，而内部输入所查找的表非常大时，查询优化器更倾向于选择循环嵌套方式。
2、合并连接
不同于循环嵌套的是，合并连接是从每个表仅仅执行一次访问。从这个原理来看，合并连接要比循环嵌套要快了不少。
从合并连接的原理不难想象，首先合并连接需要双方有序.并且要求Join的条件为等于号。因为两个输入条件已经有序，所以从每一个输入集合中取一行进行比较，相等的返回，不相等的舍弃，从这里也不难看出Merge join为什么只允许Join后面是等于号。从图11的图标中我们可以看出这个原理。
SELECT * FROM Nx_Column AS C
INNER JOIN Nx_Article AS A
ON A.ColumnId = C.ColumnId
OPTION(MERGE join)
执行计划如下：
如果输入数据的双方无序，则查询分析器不会选择合并连接，我们也可以通过索引提示强制使用合并连接，为了达到这一目的，执行计划必须加上一个排序步骤来实现有序。这也是上述SQL语句为什么要加OPTION(MERGE join)的原因。上述对Article表的ColumnId列进行了排序。
3、哈希连接
散列连接同样仅仅只需要只访问1次双方的数据。散列连接通过在内存中建立散列表实现。这比较消耗内存，如果内存不足还会占用tempdb。但并不像合并连接那样需要双方有序。
要进行下面这两个实现，得把两个列的聚集索引不要建在ColumnId列，否则不会采用哈希连接。
ALTER TABLE PK_Nx_Column DROP CONSTRAINT PK_Nx_Column --删除主键
DROP INDEX Nx_Column.PK_Nx_Column --删除聚集索引
CREATE CLUSTERED INDEX IX_ColumnName ON Nx_Column(ColumnName) --创建聚集索引
--这里再设置回主键就可以了，有了聚集索引，就不能随主键默认建啦
还要删除另外一个表Article的聚集索引哦。
然后执行以下查询：
SELECT * FROM Nx_Column AS C
INNER JOIN Nx_Article AS A
ON A.ColumnId = C.ColumnId
执行计划如下：
要删除掉聚集索引，否则两个有序输入SQL Server会选择代价更低的合并连接。SQL Server利用两个上面的输入生成哈希表，下面的输入来探测，可以在属性窗口看到这些信息，如图15所示。
J. 怎么在数据库中删除已经添加的某个索引
删除索引可以使用ALTER TABLE或DROP INDEX语句来实现，DROP INDEX可以在ALTER TABLE内部作为一条语句处理，其格式如下：
DROP INDEX index_nameONtalbe_name
ALTER TABLE table_name DROP INDEX index_name
ALTER TABLE table_name DROP PRIMARY KEY
注：其中，前两条语句是等价的，删除掉table_name中的索引index_name。
(10)sql删除聚集索引扩展阅读：
索引的使用及注意事项
EXPLAIN可以帮助开发人员分析SQL问题,explain显示了mysql如何使用索引来处理select语句以及连接表,可以帮助选择更好的索引和写出更优化的查询语句。
使用方法,在select语句前加上Explain就可以了：Explain select * from user where id=1;
尽量避免这些不走索引的sql：
SELECT `sname` FROM `stu` WHERE `age`+10=30;-- 不会使用索引,因为所有索引列参与了计算
SELECT `sname` FROM `stu` WHERE LEFT(`date`,4) <1990; -- 不会使用索引,因为使用了函数运算,原理与上面相同
SELECT * FROM `hounwang` WHERE `uname` LIKE'后盾%' 走索引
SELECT * FROM `hounwang` WHERE `uname` LIKE "%后盾%" 不走索引
正则表达式不使用索引,这应该很好理解,所以为什么在SQL中很难看到regexp关键字的原因。
字符串与数字比较不使用索引;
CREATE TABLE `a` (`a` char(10));
EXPLAIN SELECT * FROM `a` WHERE `a`="1" 走索引
EXPLAIN SELECT * FROM `a` WHERE `a`=1 不走索引