我们使用SQLServer的2008年,并有很多表“插入专用”模式。
该排序表中,我们有一个例子是(这只是一个例子):
create table spotquotes
(
Id numeric(19,0) identity(1,1) not null primary key clustered,
feeditem_id numeric(19,0) not null,
value_ask float not null,
value_bid float not null,
effectiveDateUTC datetime not null default getutcdate()
)
然后,我们查询该表与此查询
select * from spotquotes q
inner join
(select feeditem_id, max(id) as latest from spotquotes group by feeditem_id) q2
on q.id = q2.latest and q.feeditem_id = q2.feeditem_id
事实上,这是有道理的,以创建上述查询的观点:
create view latestspotquotes as
select * from spotquotes q
inner join
(select feeditem_id, max(id) as latest from spotquotes group by feeditem_id) q2
on q.id = q2.latest and q.feeditem_id = q2.feeditem_id
即我们想要的“最新”插入到表中的每个feeditem_id - 但我们也必须查询表的状态,因为它是在以往任何时候(这是审计方面的考虑很不错)的能力。
一个更简单的方式把它。 我希望优化以下查询:
select feeditem_id, max(id) as latest from spotquotes group by feeditem_id
此表通常有数亿行的 - 但少数feeditem_id情况下,这很可能是在表的末尾的。
随着该表中现有的主键和大约100万行,SQLServer的2008年花费6秒来执行这个查询 - 这是非常缓慢的。
所以,我想知道 - 如果我们创建这个表,以加快该查询的索引,我们应该创造什么指标?
可悲的是,管理工作室并不表明我们的索引。
编辑:还有问题,但我会提出作为一个单独的问题。
UPDATE
更快的查询(<10毫秒),可以通过使用“交叉应用”连同选择顶部* ... ORDER BY编号降序被哄骗了SQL服务器。 见令人信服的SQL服务器上聚集索引向后搜索插入纯架构的详细信息。