关于如何建立索引，及哪些情况适合使用索引，哪些情况不适合使用索引，各种书籍资料有很多。
但是最重要的原则是：实际测试。
实践是检验真理的唯一标准。建立索引的时候，应进行如下测试：
1 explain select语句，看看是否有使用到索引。
2 运行update和insert操作，看看建立索引的负效应是否在可接受范围。
3 务必在接近生产环境的数据规模下进行索引性能的测试。
第三点尤为重要。
因为在最近的项目优化过程中，发现：
在某个字段上建立了索引之后，如果是select返回30条记录，建立索引之后，select时间降到原来的1/6。提高很明显。
而在生产环境下，这个select需要返回的结果通常是上千（甚至上万的），建立索引之后，select的时间反而增加了快一倍。因此建立索引反而适得其反。
分析后觉得可能的原因如下：
1 该字段建立索引之后，基数并不高，也就是该字段的重复率较高，索引对性能的提升不明显。简单说，比如一个字段是：性别，只有男女两种情况，那建立索引完全没必要，反而降低了性能。
2 该select要返回的结果集很大（超过了1000条记录）。在这种情况下，mysql先查询索引，而后根据索引到表中取得记录，这个操作在需要取得的记录非常多的情况下，非常耗时。最终导致了：建立索引之后，select时间反而增加的情况。
这次的主要原因是2. 因为还进行了如下测试：如果该select语句只返回30条记录，建立索引之后，select时间为原来的1/6。
建立索引要注意的地方很多，最重要的原则还是：实际测试。
---------------------------------------------------------------------------------------------------------------------------------------------------------------
我们做开发的人员，虽说自己不是专业从事数据库方面研究的（如DBA），但很多时候，公司没有专门的DBA，所以拿到具体的项目中，整体的数据库设计都是开发人员自己写的，随着时间的推移，加上开发经验的增长，越来越关心如何设计好的数据库，如何写出高效的sql语句。之所以非常关心数据库及sql语句的写法，主要是在程序逻辑代码上大家都有可能写出一样的效率的功能方法来，而sql语句呢，对于同样的结果集，一个初级的开发人员与一个资深的开发人员或者DBA写出的sql语句执行效率有着很大的差距。这里对数据库设计略过，主要说说正确建立索引，带来的性能提高。（还好，我们公司有DBA，自己写好的sql语句可以让他帮忙看看）
看sql 的性能，主要看执行计划，还有cpu成本，io成本等。这里就以一个简的表为例。
首先，创建一个简单的表，一般会先建个主键，系统自动以主键建聚集索引。语句如下：
Code 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测试数据，
Code 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牛人呢。总结一句话就是，只要功夫深，铁杵磨成针。