SQL的数据库,一个表,120多万条记录,某个字段上建了非聚集索引,然后查询,查看计划,还是表扫描呢
表结构:Useridvarchar(20),UserNamevarchar(20),RegTimedatetime,Telvarchar(20),在Userid上建立的N...
表结构:Userid varchar(20), UserName varchar(20),
RegTime datetime, Tel varchar(20),
在 Userid 上建立的NONclustered 的索引,
查询语句SELECT * FROM T_UserInfo WHERE USERID LIKE 'ABCDE8%'
返回12万多行,但是是表扫描
确定是表扫描,逻辑读加非聚集索引和不加索引差不多一样,还多了一个
表 'T_UserInfo'。扫描计数 3,逻辑读取 13204 次,物理读取 158 次,预读 9928 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次(未加索引)。
表 'T_UserInfo'。扫描计数 3,逻辑读取 13205 次,物理读取 192 次,预读 9959 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次(非聚聚索引)。
需要确认的我都确认了,确实是表扫描,图标查看查询计划,IO差不多,STATISTICS的结果上边已经显示了,
SET SHOWPLAN_ALL ON;比较也差异不多一样,
未加索引前的结果分析
EstimateIO EstimateCPU EstimateRows
NULL NULL 139565.4
0 0.4722133 139565.4
9.783944 0.9565646 139565.4
添加索引以后的分析
EstimateIO EstimateCPU EstimateRows
NULL NULL 122291.7
0 0.4172959 122291.7
9.783944 0.9565646 122291.7 展开
RegTime datetime, Tel varchar(20),
在 Userid 上建立的NONclustered 的索引,
查询语句SELECT * FROM T_UserInfo WHERE USERID LIKE 'ABCDE8%'
返回12万多行,但是是表扫描
确定是表扫描,逻辑读加非聚集索引和不加索引差不多一样,还多了一个
表 'T_UserInfo'。扫描计数 3,逻辑读取 13204 次,物理读取 158 次,预读 9928 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次(未加索引)。
表 'T_UserInfo'。扫描计数 3,逻辑读取 13205 次,物理读取 192 次,预读 9959 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次(非聚聚索引)。
需要确认的我都确认了,确实是表扫描,图标查看查询计划,IO差不多,STATISTICS的结果上边已经显示了,
SET SHOWPLAN_ALL ON;比较也差异不多一样,
未加索引前的结果分析
EstimateIO EstimateCPU EstimateRows
NULL NULL 139565.4
0 0.4722133 139565.4
9.783944 0.9565646 139565.4
添加索引以后的分析
EstimateIO EstimateCPU EstimateRows
NULL NULL 122291.7
0 0.4172959 122291.7
9.783944 0.9565646 122291.7 展开
3个回答
展开全部
O(∩_∩)O哈哈哈~!老弟!不是这么玩的!
你那才区区120万。
索引成不成功要看 IO消耗是否减少,
-----------------------------------------------------
第一,你要使用 SET SHOWPLAN_ALL ON
第二,如果是索引全扫描,那还不如不加呢。
-----------------------------------------------------
看我如下测试:
go
SET SHOWPLAN_ALL ON;
GO
SELECT *
FROM [Product]
--where Product_ID like 'P1014%' --这个就是索引跳跃了
where Product_ID like '%P1014%'--这个就是全索引扫描
GO
SET SHOWPLAN_ALL OFF;
GO
---------------------------------------------------------------------
你比较IO消耗吧!
like %% 这种方式要Index Scan
like % 这种方式是 index seek 这说明索引就生效了
------------------------------------------------------------------------
然后看
EstimateIO
此运算符的预计 I/O 开销*。仅限于 PLAN_ROWS 类型的行。
EstimateCPU
此运算符的预计 CPU 开销*。仅限于 PLAN_ROWS 类型的行。
-----------------------------------------------
还有一些参数 你看官方网站吧!比我说的好!
-----------------------------------------------
还有扫描是否是全表,也要靠索引是否有效分类,原因特多呀。
比如没有你的数据,还是要全表扫一下。
-------------------------------------------------
还是在说一遍吧!
是不是scan 不是看你得的那些数据,第一比较时间
------------------------------------------------------
go
SET STATISTICS PROFILE ON
SET STATISTICS IO ON
SET STATISTICS TIME ON
GO
SELECT *
FROM [Product]
--where Product_ID like '%2%'
where Product_Name like '苹果%'
GO
SET STATISTICS PROFILE OFF
SET STATISTICS IO OFF
SET STATISTICS TIME OFF
GO
-----------------------------------------------------------------------------------------
|--Clustered Index Scan(OBJECT:(dbo].[Product].[PK_Product]), WHERE:(dbo].[Product].[Product_Name] like N'苹果%'))
如果有如上类似的条目就是 表 scan 了
如果有生效索引
必然有
index seek 之类的字眼
------------------------------------------------------------------------------------------
加索引 执行某些查询时间短了,证明你就成功了
------------------------------------------------------------------------------------------
向你说的那个扫描计数--那个至少是1 根本没有参考性。
----------------------------------------------------------------------------------------
时间变短了很容易比较吧?
还有你的是12万数据,占表的10分之一,索引如果是树形,你这也是大块输出。
估计效果也不明显。
你那才区区120万。
索引成不成功要看 IO消耗是否减少,
-----------------------------------------------------
第一,你要使用 SET SHOWPLAN_ALL ON
第二,如果是索引全扫描,那还不如不加呢。
-----------------------------------------------------
看我如下测试:
go
SET SHOWPLAN_ALL ON;
GO
SELECT *
FROM [Product]
--where Product_ID like 'P1014%' --这个就是索引跳跃了
where Product_ID like '%P1014%'--这个就是全索引扫描
GO
SET SHOWPLAN_ALL OFF;
GO
---------------------------------------------------------------------
你比较IO消耗吧!
like %% 这种方式要Index Scan
like % 这种方式是 index seek 这说明索引就生效了
------------------------------------------------------------------------
然后看
EstimateIO
此运算符的预计 I/O 开销*。仅限于 PLAN_ROWS 类型的行。
EstimateCPU
此运算符的预计 CPU 开销*。仅限于 PLAN_ROWS 类型的行。
-----------------------------------------------
还有一些参数 你看官方网站吧!比我说的好!
-----------------------------------------------
还有扫描是否是全表,也要靠索引是否有效分类,原因特多呀。
比如没有你的数据,还是要全表扫一下。
-------------------------------------------------
还是在说一遍吧!
是不是scan 不是看你得的那些数据,第一比较时间
------------------------------------------------------
go
SET STATISTICS PROFILE ON
SET STATISTICS IO ON
SET STATISTICS TIME ON
GO
SELECT *
FROM [Product]
--where Product_ID like '%2%'
where Product_Name like '苹果%'
GO
SET STATISTICS PROFILE OFF
SET STATISTICS IO OFF
SET STATISTICS TIME OFF
GO
-----------------------------------------------------------------------------------------
|--Clustered Index Scan(OBJECT:(dbo].[Product].[PK_Product]), WHERE:(dbo].[Product].[Product_Name] like N'苹果%'))
如果有如上类似的条目就是 表 scan 了
如果有生效索引
必然有
index seek 之类的字眼
------------------------------------------------------------------------------------------
加索引 执行某些查询时间短了,证明你就成功了
------------------------------------------------------------------------------------------
向你说的那个扫描计数--那个至少是1 根本没有参考性。
----------------------------------------------------------------------------------------
时间变短了很容易比较吧?
还有你的是12万数据,占表的10分之一,索引如果是树形,你这也是大块输出。
估计效果也不明显。
展开全部
对比下这个语句:
SELECT USERID FROM T_UserInfo WHERE USERID LIKE 'ABCDE8%'
SELECT USERID FROM T_UserInfo WHERE USERID LIKE 'ABCDE8%'
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
额 不是很熟悉
你再做同样的查询 看还依然是表扫描
你再做同样的查询 看还依然是表扫描
本回答被网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询