开篇:
最近遇到了很多性能问题,一直没来的及总结,今天正好周末抽时间总结下:
对于稍微大点的公司或者说用户多一些的公司,说白了就是数据量较大的公司,在查询数据时往往会遇到很多瓶颈。这时就需要性能优化。 性能优化分为代码优化和数据库优化,常见的代码优化有分页查询,with(nolock)使用无锁模式。 数据库优化主要是创建索引。
一个苦逼的事情是我们的老系统没有使用分页查询,而是通过查询出所有的数据然后利用前台控件进行的分页。(PS:一个合格的架构师需要不断学习前沿技术,而不是固步自封,设计出垃圾架构)。所以系统经常提示连接数据库超时。。。 所以要解决这个问题我们只能从数据库优化下手。
因为此文要围绕索引展开,所以在开始之前先了解几个概念,及什么是索引? 什么是聚集索引,什么是非聚集索引?什么是主键? 建立非聚集索引时,索引键列和包含性列分别指的什么?
什么是索引?举个例子你就明白了,索引就相当于字典目录,根据目录查找你想要找的文字。如果没有目录的话,你就得一页一页的翻,看哪个文字是自己想要的。所以我们要建立索引。
什么是聚集索引,什么是非聚集索引?一张表里面可以有多个非聚集索引,但只能有一个聚集索引。数据会按照聚集索引进行物理排序,聚集索引和数据是绑定在一起的。而非聚集索引是数据和索引位置分开的,索引上有个指针指向数据。还是拿字典举例,聚集索引就相当于你通过拼音查找,他是有顺序的,A,B,C...是依次排列的,你可以通过拼音直接找到文字位置。而非聚集索引就相当于通过偏旁查找,你先要找到偏旁,然后根据偏旁查找文字,最后才知道在哪一页。 搞不懂的话,可以看下这个 。
什么是主键? 主键主要是确定资料的唯一性。设置主键的字段(可多个字段一起做主键)。例如人事资料中有一个身份证号的字段。这个就可设为主键(因为身份证号不会重复).但姓名就不可以,因为姓名可以重复,另外设置了主键有利于提高数据的检索速度.也保证数据准确性。 主键和索引没有什么必然联系,主键是确定唯一性的,索引是排序用的。
建立非聚集索引时,索引键列和包含性列分别指的什么? 首先声明下,建立非聚集索引的前提是有where查询条件或者order by时建立才有意义。 索引键列一般选取的就是根据where要查询的字段。包含性列是要查询的字段。包含性列是对查询条件的一种性能补充。 可能说的不是很明白,详细可以参考:https://www.cnblogs.com/sc0791/p/3720249.html
正文:
首先先创建Grade和Member两个数据库表并插入数据来进行模拟,创建数据库脚本如下:
create table Grade( ID int primary key identity, MathGrade int null, ChineseGrade int null, EnglishGrade int null, MemberID int null, CreateTime DateTime ) create table Member( ID int primary key identity, MemberName nvarchar(20) ) --在Grade里面循环插入数据 Declare @I int Set @I=0 Begin Tran InsertData: Insert into Grade values(@I,@I+10,@I+20,@I+30,GETDATE()) Set @I=@I+1 if @I<100000 Goto InsertData Commit Tran --在Member里面循环插入数据 Declare @I int Set @I=0 Begin Tran InsertData: Insert into Member values('姓名'+Convert(nvarchar(20), @I)) Set @I=@I+1 if @I<100000 Goto InsertData Commit Tran
OK,Grade表和Member表都创建好了,并都插入了10W条数据。Grade表中的MemberID和Member表ID是一一对应关系。下面开始测试性能。
执行代码:
declare @begin_date datetime declare @end_date datetime select @begin_date = getdate() select g.ID,g.MathGrade,m.MemberName,g.CreateTime from Grade g left join Member m on g.MemberID=m.ID order by g.CreateTime select @end_date = getdate() select datediff(ms,@begin_date,@end_date) as '用时/毫秒'
OK,下面开始优化,少于1930毫秒则证明优化成功~
选择 工具->数据库引擎优化顾问
或者右键空白处选择 在数据库引擎优化顾问中分析查询
、
应用后再次执行,如下图:
先不用管它,先看下上面执行了什么,如下图:
从上面可以看到,它把我们的查询条件都包含进了非聚集索引里面。 emmm~下面看下有没有命中索引:
SQL Server有几种方式查找数据记录:
[Table Scan]表扫描(最慢),这种情况是没索引的前提下。
[Clustered Index Scan]聚集索引扫描(较慢) ,这种情况是只有主键索引的前提下。
[Index Scan]索引扫描(普通),这种情况是有主键索引,并且要搜索的数据建立了非聚集索引的前提下。
[Index Seek]索引查找(较快),这种情况是where条件里面没有根据主键进行过滤时,把过滤的字段加在索引键列上,其余加在包含列上的前提下。
[Clustered Index Seek]聚集索引查找(最快)。这种情况是根据主键进行where过滤的前提下。
这块具体实例我就不演示了,想看的话参考:https://www.cnblogs.com/taiyonghai/p/5594826.html
----休息一下!!!
来,继续!!!上面主要是通过工具生成优化脚本,我们还可以通过图形化工具自己定义,同时还可以写脚本创建。
如下图:(图形化工具创建两张图完美解释)
脚本创建如下:
CREATE [索引类型] INDEX 索引名称 ON 表名(列名) WITH FILLFACTOR = 填充因子值0~100 GO
索引类型有:
-- 聚集索引(Clustered)
-- 非聚集索引(NonClustered)
填充因子解释:http://blog.csdn.net/silentmuh/article/details/50403228
创建聚集索引时,因为有时要创建包含性列,比较特殊,所以举个例子:
create NonClustered index SuoYiin_Name on ActionInfo(ControllerName,ParID) include (ActionID) WITH FILLFACTOR = 80 --这样就给ActionInfo表中的ControllerName和ParID创建了一个包含ActionID的非聚集索引
好啦,数据库优化就这么多啦,细节比较多,但是学会的话还是感觉挺简单的,快去动手试试吧~