我有一个关于在SQL Azure上使用具有聚集聚集索引的表的Top的问题。
这两个表都有聚类列存储索引,表HeaderTable有300K行,表ValuesTable有6.5M行。
-- with no "Top"
--responce after 2 sec
declare @Date datetime = getdate()
select zp.idCol1, Value1, zp.idcol2 from [HeaderTable] zp
inner join [dbo].[ValuesTable] zpp
on zp.idcol2 = zpp.idcol2
where zp.Date > @Date-30 and zp.Date < @Date-10 and zp.idCol1>0 and zpp.Value2 = 'SZT'
order by idcol2
go
-- with "Top 100"
--responce after 27 sec
declare @Date datetime = getdate()
select top 100 zp.idCol1, Value1, zp.idcol2 from [HeaderTable] zp
inner join [dbo].[ValuesTable] zpp
on zp.idcol2 = zpp.idcol2
where zp.Date > @Date-30 and zp.Date < @Date-10 and zp.idCol1>0 and zpp.Value2 = 'SZT'
order by idcol2
go
-- Result into Temporary Table and Select top 100 from Temporaty Table
-- responce after 2 sec
declare @Date datetime = getdate()
select zp.idCol1, Value1, zp.idcol2 into #d from [HeaderTable] zp
inner join [dbo].[ValuesTable] zpp
on zp.idcol2 = zpp.idcol2
where zp.Date > @Date-30 and zp.Date < @Date-10 and zp.idCol1>0 and zpp.Value2 = 'SZT'
select top 100 * from #d order by #d.idcol2
drop table #d
go如您所见,第二个查询中的top操作非常慢。也许有人对这个问题有一些提示?
发布于 2016-04-22 19:11:15
这在Azure上的新数据库(兼容级别130,兼容级别130目前支持作为预览,还不是一般可用的)数据库的增强中进行了优化。
ALTER DATABASE <dbname> SET COMPATIBILITY_LEVEL = 130
这就不同了。
发布于 2015-12-16 23:38:43
第二个执行计划令人震惊。SQL Server正在通过将列存储缓冲到行存储临时表中来破坏所有列存储优势...这是查询优化器的质量问题,因为这种策略在任何情况下都没有意义。
尝试说服SQL Server顶层什么也不做:
DECLARE @top BIGINT = 100;
SELECT TOP (@top) ...
OPTION (OPTIMIZE FOR (@top = 100000000000000000000000000000000));https://stackoverflow.com/questions/34314516
复制相似问题