聚簇、非聚簇索引结构及B树、位图、散列索引

先理解下：聚簇索引和非聚簇索引是一种索引的结构。B树索引、位图索引、散列索引、全文索引等等都是这种索引结构的实现方式。

聚簇索引 (Clustered Index) 和非聚簇索引  (Non- Clustered Index)
最通俗的解释是:聚簇索引的顺序就是 数据 的物理存储顺序，而对非聚簇索引的索引顺序与数据物理排列顺序无关。在一张表上最多只能创建一个聚集索引，因为真实数据的物理顺序只能有一种。举例来说，你翻到新华字典的汉字“爬”那一页就是P开头的部分，这就是物理存储顺序（聚簇索引）；而不用你到目录，找到汉字“爬”所在的页码，然后根据页码找到这个字（非聚簇索引）。

下表给出了何时使用聚簇索引与非聚簇索引:

动作	使用聚簇索引	使用非聚簇索引
列经常被分组排序	应	应
返回某范围内的数据	应	不应
一个或极少不同值	不应	不应
小数目的不同值	应	不应
大数目的不同值	不应	应
频繁更新的列	不应	应
外键列	应	应
主键列	应	应
频繁修改索引列	不应	应

聚簇索引的唯一性
正式聚簇索引的顺序就是数据的物理存储顺序，所以一个表最多只能有一个聚簇索引，因为物理存储只能有一个顺序。正因为一个表最多只能有一个聚簇索引，所以它显得更为珍贵，一个表设置什么为聚簇索引对性能很关键。

初学者最大的误区：把主键自动设为聚簇索引
因为这是 SQL Server 的默认主键行为，你设置了主键，它就把主键设为聚簇索引，而一个表最多只能有一个聚簇索引，所以很多人就把其他索引设置为非聚簇索引。这个是最大的误区。甚至有的主键又是无意义的自动增量字段，那样的话Clustered index对效率的帮助，完全被浪费了。

刚才说到了，聚簇索引性能最好而且具有唯一性，所以非常珍贵，必须慎重设置。一般要根据这个表最常用的SQL查询方式来进行选择，某个字段作为聚簇索引，或组合聚簇索引，这个要看实际情况。

事实上，建表的时候，先需要设置主键，然后添加我们想要的聚簇索引，最后设置主键，SQLServer就会自动把主键设置为非聚簇索引（会自动根据情况选择）。如果你已经设置了主键为聚簇索引，必须先删除主键，然后添加我们想要的聚簇索引，最后恢复设置主键即可。

记住我们的最终目的就是在相同结果集情况下，尽可能减少逻辑IO。
我们先从一个实际使用的简单例子开始。

一个简单的表：

1. CREATE TABLE [dbo].[Table1](
   
2.   [ID] [int] IDENTITY(1,1) NOT NULL,
   
3.   [Data1] [int] NOT NULL DEFAULT ((0)),
   
4.   [Data2] [int] NOT NULL DEFAULT ((0)),
   
5.   [Data3] [int] NOT NULL DEFAULT ((0)),
   
6.   [Name1] [nvarchar](50) NOT NULL DEFAULT (''),
   
7.   [Name2] [nvarchar](50) NOT NULL DEFAULT (''),
   
8.   [Name3] [nvarchar](50) DEFAULT (''),
   
9.   [DTAt] [datetime] NOT NULL DEFAULT (getdate())

复制代码

 

来点测试数据（10w条）：

1. 
   
2. declare @i int
   
3. set @i = 1 
   
4. while @i < 100000 
   
5. begin 
   
6. insert into Table1 ([Data1] ,[Data2] ,[Data3] ,[Name1],[Name2] ,[Name3]) 
   
7. values(@i, 2* @i,3*@i, CAST(@i AS NVARCHAR(50)), CAST(2*@i AS NVARCHAR(50)), CAST(3*@i AS NVARCHAR(50)))
   
8. set @i = @i + 1
   
9. end
   
10. update table1 set dtat= DateAdd (s, data1, dtat)

复制代码

打开查询分析器的IO统计和时间统计：

1. SET STATISTICS IO ON;
   
2. SET STATISTICS TIME ON;

复制代码

显示实际的“执行计划”：


我们最常用的SQL查询是这样的：

1. SELECT * FROM Table1 WHERE Data1 = 2 ORDER BY DTAt DESC;

复制代码

先在Table1设主键ID， 系统 自动为该主键建立了聚簇索引。
然后执行该语句，结果是：

1. Table 'Table1'. Scan count 1, logical reads 911, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
   
2. SQL Server Execution Times:
   
3. CPU time = 16 ms, elapsed time = 7 ms.

复制代码

 

然后我们在Data1和DTat字段分别建立非聚簇索引：

1. CREATE NONCLUSTERED INDEX [N_Data1] ON [dbo].[Table1] 
   
2. (
   
3. [Data1] ASC
   
4. )WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF) ON [PRIMARY]
   
5. CREATE NONCLUSTERED INDEX [N_DTat] ON [dbo].[Table1] 
   
6. (
   
7. [DTAt] ASC
   
8. )WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF) ON [PRIMARY]

复制代码

再次执行该语句，结果是：

1. Table 'Table1'. Scan count 1, logical reads 5, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
   
2. SQL Server Execution Times:
   
3. CPU time = 0 ms, elapsed time = 39 ms.

复制代码

 

可以看到设立了索引反而没有任何性能的提升而且消耗的时间更多了，继续调整。

然后我们删除所有非聚簇索引，并删除主键，这样所有索引都删除了。 建立组合索引Data1和DTAt，最后加上主键 ：

1. CREATE CLUSTERED INDEX [C_Data1_DTat] ON [dbo].[Table1] 
   
2. (
   
3. [Data1] ASC,
   
4. [DTAt] ASC
   
5. )WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF) ON [PRIMARY]

复制代码

再次执行语句：

1. Table 'Table1'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
   
2. SQL Server Execution Times:
   
3. CPU time = 0 ms, elapsed time = 1 ms.

复制代码

 

可以看到只有聚簇索引seek了，消除了index scan和nested loop，而且执行时间也只有1ms，达到了最初优化的目的。

组合索引小结
小结以上的调优实践，要注意聚簇索引的选择。首先我们要找到我们最多用到的SQL查询，像本例就是那句类似的组合条件查询的情况，这种情况最好使用组合聚簇索引，而且最多用到的字段要放在组合聚簇索引的前面，否则的话就索引就不会有好的效果，看下例：

 

查询条件落在组合索引的第二个字段上，引起了index scan，效果很不好，执行时间是：

1. Table 'Table1'. Scan count 1, logical reads 238, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
   
2. SQL Server Execution Times:
   
3. CPU time = 16 ms, elapsed time = 22 ms.

复制代码

而如果仅查询条件是第一个字段也没有问题，因为组合索引最左前缀原则，实践如下：

1. Table 'Table1'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
   
2. SQL Server Execution Times:
   
3. CPU time = 0 ms, elapsed time = 1 ms.

复制代码

从中可以看出，最多用到的字段要放在组合聚簇索引的前面。

Index seek 为什么比 Index scan好？
索引扫描也就是遍历B树，而seek是B树查找直接定位。
Index scan多半是出现在索引列在表达式中。数据库 引擎 无法直接确定你要的列的值，所以只能扫描整个整个索引进行计算。index seek就要好很多.数据库引擎只需要扫描几个分支节点就可以定位到你要的记录。回过来,如果聚集索引的叶子节点就是记录，那么Clustered Index Scan就基本等同于full table scan。

一些优化原则
1、缺省情况下建立的索引是非聚簇索引，但有时它并不是最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引 设计 要建立在对各种查询的分析和预测上。一般来说： 
a.有大量重复值、且经常有范围查询（ > ,< ，> =,< =）和order by、group by发生的列，可考 
虑建立群集索引； 
b.经常同时存取多列，且每列都含有重复值可考虑建立组合索引； 
c.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。索引虽有助于提高性能但不是索引越多越好，恰好相反过多的索引会导致系统低效。 用户 在表中每加进一个索引，维护索引集合就要做相应的更新工作。 

2、ORDER BY和GROPU BY使用ORDER BY和GROUP BY短语，任何一种索引都有助于SELECT的性能提高。 

3、多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接 方案 并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。

4、任何对列的操作都将导致表扫描，它包括数据库 函数 、计算表达式等等，查询时要尽可能将操作移至等号右边。 

5、IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。
Sql的优化原则2： 
1、只要能满足你的需求，应尽可能使用更小的数据类型：例如使用MEDIUMINT代替INT 
2、尽量把所有的列设置为NOT NULL，如果你要保存NULL，手动去设置它，而不是把它设为默认值。 
3、尽量少用VARCHAR、TEXT、BLOB类型 
4、如果你的数据只有你所知的少量的几个。最好使用ENUM类型  

使用SQLServer Profiler找出数据库中性能最差的SQL
首先打开SQLServer Profiler:

 


然后点击 工具 栏“New Trace”，使用默认的模板，点击RUN。

也许会有报错："only TrueType fonts are supported. There id not a TrueType font"。不用怕，点击Tools菜单->Options，重新选择一个字体例如Vendana 即可。（这个是 微软 的一个bug）

运行起来以后，SQLServer Profiler会监控数据库的活动，所以最好在你需要监控的数据库上多做些操作。等觉得差不多了，点击停止。然后保存trace结果到 文件 或者table。
这里保存到Table：在菜单“File”-“Save as ”-“Trace table”，例如输入一个master数据库的新的table名：profileTrace，保存即可。

找到最耗时的SQL：

1. use master
   
2. select * from profiletrace order by duration desc;

复制代码

找到了性能瓶颈，接下来就可以有针对性的一个个进行调优了。

对使用SQLServer Profiler的更多信息可以参考：
http://www.codeproject.com/KB/database/DiagnoseProblemsSQLServer.aspx

使用SQLServer Database Engine Tuning Advisor数据库引擎优化顾问
使用上述的SQLServer Profiler得到了trace还有一个好处就是可以用到这个优化顾问。用它可以偷点懒，得到SQLServer给您的优化顾问，例如这个表需要加个索引什么的…
首先打开数据库引擎优化顾问：
 

然后打开刚才profiler的结果（我们存到了master数据库的profileTrace表）：

 

点击“start analysis”，运行完成后查看优化建议（图中最后是建议建立的索引，性能提升72%）

 

这个方法可以偷点懒，得到SQLServer给您的优化顾问。

索引在数据结构上可以分为三种B树索引、位图索引和散列索引

 

B树索引

 

结构：

 

 
 

 

 

特点：

 

1.索引不存储null值。

 

   更准确的说，单列索引不存储null值，复合索引不存储全为ｎｕｌｌ的值

 

    索引不能存储Null，所以对这列采用is null条件时，因为索引上根本没Null值，不能利用到索引，只

 

能全表扫描。

 

   为什么索引列不能存Null值呢？将索引列值进行建树，其中必然涉及到诸多的比较操作。Null值

 

的特殊性就在于参与的运算大多取值为null。这样的话，null值实际上是不能参与进建索引的

 

过程。也就是说，null值不会像其他取值一样出现在索引树的叶子节点上。

 

B树索引测试1：NULL是否存在索引上。

 

 

create table btree_test(id number,code varchar2(10));

create index idx_btree_test_id on btree_test(id,code);

select object_id from user_objects where object_name='IDX_BTREE_TEST_ID';

alter session set events 'immediate trace name treedump level 59097';

insert into btree_test values(null,null);

alter session set events 'immediate trace name treedump level 59097';

insert into btree_test values(null,'1');

alter session set events 'immediate trace name treedump level 59097';

insert into btree_test values(1,null);

alter session set events 'immediate trace name treedump level 59097';

 

 

然后查看转储文件，admin\数据库名\udump

 

发现这样的信息：

 

*** 2013-07-19 14:56:41.827

----- begin tree dump

leaf: 0x140142c 20976684 (0: nrow: 0 rrow: 0)

----- end tree dump

*** 2013-07-19 14:56:54.480

----- begin tree dump

leaf: 0x140142c 20976684 (0: nrow: 1 rrow: 1)

----- end tree dump

*** 2013-07-19 14:57:08.139

----- begin tree dump

leaf: 0x140142c 20976684 (0: nrow: 2 rrow: 2)

----- end tree dump

 

nrow当前节点所含索引条目的数量（包括delete的条目）

 

rrow有效的索引条目的数量

 

可以发现：

 

插入null,null时，有效的索引条目为0

插入null,1时，   有效的索引条目为1

插入1,null时，   有效的索引条目为2

 

所以，复合索引只有当要插入的值全为Null时才不能放入存入索引中。

 

 也可以这样看：

 

 SELECT num_rows  FROM user_indexes t   WHERE t.index_name ='btree_test';

 

 

2.不适合键值较少的列（重复数据较多的列）。

 

     假如索引列TYPE有5个键值，如果有1万条数据，那么 WHERE TYPE = 1将访问表中的2000个数据块。

 

再加上访问索引块，一共要访问大于200个的数据块。

 

    如果全表扫描，假设10条数据一个数据块，那么只需访问1000个数据块，既然全表扫描访问的数据块

 

少一些，肯定就不会利用索引了。

 

3.前导模糊查询不能利用索引(like '%XX'或者like '%XX%')

 

   假如有这样一列code的值为'AAA','AAB','BAA','BAB' ,如果where code like '%AB'条件，由于前面是

 

模糊的，所以不能利用索引的顺序，必须一个个去找，看是否满足条件。这样会导致全索引扫描或者全表扫

 

描。如果是这样的条件where code like 'A % '，就可以查找CODE中A开头的CODE的位置，当碰到B开头的

 

数据时，就可以停止查找了，因为后面的数据一定不满足要求。这样就可以利用索引了。

 

 

位图索引

 

 

    就是用位图表示的索引，对列的每个键值建立一个位图。

 

    如test表中有state这样一列，数据如下：

 

        10    20    30    20    10    30    10    30    20    30

 

那么会建立三个位图，如下：

 

BLOCK1    KEY=10  1    0    0    0    1    0    1    0    0    0   

BLOCK2    KEY=20  1    0    0    0    1    0    1    0    0    0 

BLOCK3    KEY=30  1    0    0    0    1    0    1    0    0    0 

 

位图索引特点：

 

 

1.相对于B*Tree索引,占用的空间非常小,创建和使用非常快。

 

    位图索引由于只存储键值的起止Rowid和位图,占用的空间非常少。

 

 

2.不适合键值较多的列。

 

3.不适合update、insert、delete频繁的列。

 

4.可以存储null值。

 

    B*Tree索引由于不记录空值,当基于is null的查询时,会使用全表扫描,而对位图索引列进

 

行is null查询时,则可以使用索引。

 

5.当select count(XX) 时,可以直接访问索引中一个位图就快速得出统计数据。

 

6.当根据键值做and,or或 in(x,y,..)查询时,直接用索引的位图进行或运算,快速得出结果行数

 

据。

 

 

位图测试1：位图索引查询效率（省略）。

 

位图测试2：修改数据时锁的范围。

 

create table test_bitmap(id number,state number);

insert into test_bitmap values (1,10);

insert into test_bitmap values (2,10);

insert into test_bitmap values (3,20);

insert into test_bitmap values (4,20);

insert into test_bitmap values (5,10);

insert into test_bitmap values (6,30);

insert into test_bitmap values (7,30);

insert into test_bitmap values (8,20);

insert into test_bitmap values (9,30);

insert into test_bitmap values (10,20);

 

 

CREATE BITMAP INDEX INDEX_TESTBITMAP_STATE ON TEST_BITMAP(STATE);

 

开一个PLSQL窗口（SESSION1），执行

update test_bitmap set state = 20 where id = 1;

 

另开一个PLSQL窗口（SESSION2），执行

update test_bitmap set state = 20 where id = 2;

或者

update test_bitmap set state = 10 where id = 4;

可以发现，状态为20的所有行被锁定。

 

 

 

散列索引

 

散列索引是根据HASH算法来构建的索引，所以检索速度很快，但不能范围查询。

 

散列索引的特点

 

 

1.只适合等值查询（包括= <> 和in），不适合模糊或范围查询