如何创建效率高sql建立索引

我们做开发的人员，虽说自己不是专业从事数据库方面研究的（如DBA），但很多时候，公司没有专门的DBA，所以拿到具体的项目中，整体的数据库设计都是开发人员自己写的，随着时间的推移，加上开发经验的增长，越来越关心如何设计好的数据库，如何写出高效的sql语句。之所以非常关心数据库及sql语句的写法，主要是在程序逻辑代码上大家都有可能写出一样的效率的功能方法来，而sql语句呢，对于同样的结果集，一个初级的开发人员与一个资深的开发人员或者DBA写出的sql语句执行效率有着很大的差距。这里对数据库设计略过，主要说说正确建立索引，带来的性能提高。（还好，我们公司有DBA，自己写好的sql语句可以让他帮忙看看）

看sql 的性能，主要看执行计划，还有cpu成本，io成本等。这里就以一个简的表为例。

首先，创建一个简单的表，一般会先建个主键，系统自动以主键建聚集索引。语句如下：

 

 1CREATE TABLE [dbo].[Article](
 2    [Id] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
 3    [MsId] [int] NOT NULL,
 4    [Title] [nvarchar](96) NOT NULL,
 5    [TitleBak] [nvarchar](96) NOT NULL,
 6    [Summary] [nvarchar](512) NOT NULL,
 7    [SummaryImageUrl] [nvarchar](256) NOT NULL,
 8    [Tag] [nvarchar](50) NOT NULL,
 9    [ArticleChannel_Id] [int] NOT NULL,
10    [ArticleCategory_Id] [int] NOT NULL,
11    [IsApproved] [bit] NOT NULL,
12    [Creator_Id] [int] NOT NULL,
13    [CreatedDateTime] [datetime] NOT NULL,
14    [ModifiedDateTime] [datetime] NOT NULL,
15    [ViewCount] [int] NOT NULL,
16    [ReplyCount] [int] NOT NULL,
17    [DiggCount] [int] NOT NULL,
18    [FavoriteCount] [int] NOT NULL,
19    [LastReplyUser_Id] [int] NOT NULL,
20    [LastReplyDateTime] [datetime] NOT NULL,
21    [RightType] [int] NOT NULL,
22    [IsDisplayContent] [bit] NOT NULL,
23    [IsSensitive] [bit] NOT NULL,
24    [Source] [int] NOT NULL,
25 CONSTRAINT [PK_Articles] PRIMARY KEY CLUSTERED 
26(
27    [Id] ASC
28)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
29) ON [PRIMARY]
30

 

填充200000测试数据，

 

 1DECLARE @number INT
 2SET @number = 200000
 3
 4WHILE @number > 0
 5BEGIN
 6    INSERT dbo.Article
 7      (
 8        MsId,
 9        Title,
10        TitleBak,
11        Summary,
12        SummaryImageUrl,
13        
14        Tag,
15        ArticleChannel_Id,
16        ArticleCategory_Id,
17        IsApproved,
18        Creator_Id,
19        
20        CreatedDateTime,
21        ModifiedDateTime,
22        ViewCount,
23        ReplyCount,
24        DiggCount,
25        
26        FavoriteCount,
27        LastReplyUser_Id,
28        LastReplyDateTime,
29        RightType,
30        IsDisplayContent,
31        
32        IsSensitive,
33        Source
34      )
35    VALUES
36      (
37          @number,
38        'Title'+cast(@number AS VARCHAR(20)),
39        'TitleBak'+cast(@number AS VARCHAR(20)),
40        'Summary'+cast(@number AS VARCHAR(20)),
41        'SummaryImageUrl'+cast(@number AS VARCHAR(20)),
42        
43        'Tag'+cast(@number AS VARCHAR(20)),
44        1,
45        2,
46        0,
47        @number,
48        
49        GETDATE(),
50       GETDATE(),
51        100,
52        29,
53        123,
54        
55        12,
56        @number,
57        GETDATE(),
58        1,
59        0,
60        
61        0,
62        2
63          
64      )
65      SET @number=@number-1
66END
67

 

创建索引，什么时候创建，为哪个字段创建等等一系列的问题在这里统统的撂下，在这里进行一步步的带有试探的创建非聚集索引，看看建立索引前后以及不同的索引会有什么样的不同。

先说明一下，通过执行计划，判断是否需要优化sql的一个简单规则是：看执行计划中的操作是seek(搜索)还是scan（扫描）

长话短说，马上开始，

 

WITH TEMP AS
(
SELECT ROW_NUMBER() OVER (ORDER BY CreatedDateTime) AS ROW,CreatedDateTime,ViewCount
FROM Article
WHERE Creator_Id=199996 
)
SELECT *
FROM TEMP
WHERE ROW BETWEEN 1 AND 5

 

通过执行计划，看到是操作是聚集索引扫描。我们刚才说了，seek操作性能更好一些，那如何优化这条语句呢，对Creator_Id建非聚集索引。

 

 创建Ix_article_creatorid 索引，

CREATE INDEX Ix_article_creatorid ON Article(Creator_Id)

再看下执行计划，

哦，加了Ix_article_creatorid索引后，聚集索引扫描操作改为索引查找和聚集索引查找，对于我们开发人员来说，一般的认为可以了。如果所开发的系统在正常运行一段时间后，需要优化，可以对此语句继续进行优化。

看完执行计划，想到了应该再看看cpu占用时间，IO资源等情况，主要用到命令

set statistics io 和 set statistics，这是性能调优时查看相关cpu占用时间，IO资源数据的两个比较重要的命令。

        今天就先到了，下篇再介绍这两个命令吧。

 

备注：

         其实没有详细介绍如何创建高效性能的索引，主要原因是根据不同的环境对待系统的要求不同，而优化也有所不同，当一个系统查询比较频繁，而新建，修改等操作比较少时，可以创建覆盖索引，将查询字段和where子句里的字段全部包含在内，这样查询的速度会比以前快很多，同时也带来弊端，就是新建或修改等操作时，比没有索引或没有建立覆盖索引时的要慢。总结一句话就是，具体问题具体分析。

         数据库里的知识也是博大精深，并不是当初认为会写几条sq         l语句就以为非常精通了数据库什么的，真正要写出好的语句，得下功夫，了解数据库的底层，再经常问问DB牛人，慢慢积累后，也许你也能成为DB牛人呢。总结一句话就是，只要功夫深，铁杵磨成针。