--创建表
use new_db
create table test_table
(
id int IDENTITY(1,1) PRIMARY KEY,
[name] varchar(20),
code varchar(20),
date datetime
)
---插入表
declare @m int
set @m=1
while @m<80000
begin
INSERT INTO [new_db].[dbo].[test_table]
(
[name]
,[code],date)
VALUES
('name'+CAST(@m AS VARCHAR(20))
,'code'+CAST(@m AS VARCHAR(20)),GETUTCDATE())
select @m=@m+1
END
---设置
SET STATISTICS IO on -- 查看磁盘IO
set statistics time on -- 查看sql语句分析编译和执行时间
SELECT * FROM test_table -- 查看效果
---看主键
sp_helpindex test_table
ctrl+L 看执行计划:
--查询
SELECT * FROM test_table su WHERE su.name='name1'
--看到聚集索引扫描开销占了100%,可以考虑优化为索引查找,在查询条件name上建立非聚集索引
create index name_index on test_table(name) --在name上创建索引,再次查看执行计划和磁盘io等,新建的索引已经起到了作用,但是还是去扫描了主键的聚集索引,如果能在一个索引上完成查询性能会更高
sp_helpindex test_table
create index name_index4 on test_table(name,code,[date])--在表上创建组合索引,再次查看执行计划和磁盘io等,这样直接走索引查找就快很多了
create index name_index5 on test_table(name)include(id,code,[date])--在表上创建索引覆盖,再次查看执行计划和磁盘io等
----最后比较组合索引和索引覆盖哪个更优利用dbcc进行数据分析:
DBCC SHOW_STATISTICS('test_table','name_index4')
DBCC SHOW_STATISTICS('test_table','name_index5')
----可以看到,同样的数据量,average key length:覆盖索引index5,占用的空间相对少些,所以我们应该优先选择覆盖索引来进行优化