按照本文操作和体会,会对sql优化有个基本最简单的了解,其他深入还需要更多资料和实践的学习: 1. 建表: <div class="codetitle"><a style="CURSOR: pointer" data="68781" class="copybut" id="copybut68781" onclick="doCopy('code68781')"> 代码如下:<div class="codebody" id="code68781"> create table site_user ( id int IDENTITY(1,1) PRIMARY KEY, [name] varchar(20), code varchar(20), date datetime ) 2. 插入8万条数据 <div class="codetitle"><a style="CURSOR: pointer" data="60495" class="copybut" id="copybut60495" onclick="doCopy('code60495')"> 代码如下:<div class="codebody" id="code60495"> declare @m int set @m=1 while @m<80000 begin INSERT INTO [demo].[dbo].[site_user] ( [name] ,[code],date) VALUES ('name'+CAST(@m AS VARCHAR(20)) ,'code'+CAST(@m AS VARCHAR(20)),GETUTCDATE()) select @m=@m+1 END --小技巧:推荐使用类似sqlassist的工具来提高敲写sql语句的速度 3. 设置打开一些参数的设置 <div class="codetitle"><a style="CURSOR: pointer" data="38469" class="copybut" id="copybut38469" onclick="doCopy('code38469')"> 代码如下:<div class="codebody" id="code38469"> SET STATISTICS IO on -- 查看磁盘IO set statistics time on -- 查看sql语句分析编译和执行时间 SELECT * FROM site_user -- 查看效果 4. 查看表索引情况: sp_helpindex site_user
5. 执行sql语句 代码如下:SELECT * FROM site_user su WHERE su.name='name1'表 'site_user'。 扫描计数 1,逻辑读取 446 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次
ctrl+L 快捷键查看执行计划:
6. 优化第一步:聚集索引扫描开销占了100%,可以考虑优化为索引查找,在查询条件name上建立非聚集索引 代码如下:create index name_index on site_user(name) sp_helpindex site_user -- 多出来我们新建立的索引
此时再运行上面的查询语句: 代码如下:SELECT * FROM site_user su WHERE su.name='name1' 表 'site_user'。扫描计数 1,逻辑读取 4 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
磁盘逻辑读取次数明显下降,然后查看执行计划:
新建的索引已经起到了作用,但是还是去扫描了主键的聚集索引,如果能在一个索引上完成查询性能会更高,因为这个查询
所以考虑进一步优化:
7. 代码如下:create index name_index4 on site_user(name,code,[date]) 表 'site_user'。扫描计数 1,逻辑读取 3 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 -- 磁盘逻辑读取次数又下降了 然后查看执行计划:
这样直接走索引查找就快很多了,使用了
8. 代码如下:create index name_index5 on site_user(name)include(id,[date])表 'site_user'。 扫描计数 1,逻辑读取 3 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 -- 磁盘逻辑读取次数没有明显变化然后查看执行计划:
同样走索引查找使用了此时:利用 代码如下:DBCC SHOW_STATISTICS('site_user','name_index4') DBCC SHOW_STATISTICS('site_user','name_index5')
可以看到,同样的数据量,average key length:覆盖索引index5,占用的空间相对少些,所以我们应该优先选择覆盖索引来进行优化 鉴于此文so easy,大家可以多多提点 作者:gaobanana 出处:http://www.cnblogs.com/gaobanana (编辑:李大同)
【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!
|