0

我有这个查询：

SELECT * FROM Events e 
  INNER JOIN Telemetry ss ON ss.Id = e.TelemetryId 
  INNER JOIN Services s ON s.Id = ss.ServiceId 
  WHERE s.AssetId = @AssetId AND e.TimestampTicks >= @StartTime 
  ORDER BY e.TimestampTicks LIMIT 1000

我有这个索引：

CREATE INDEX [IX_Events_TelemetryId_TimestampTicks] ON [Events] ([TelemetryId],[TimestampTicks])

但是，索引不用于 ORDER BY 子句。我得到这个查询解释：

0|0|2|SCAN TABLE Services AS s (~44 rows)
0|1|1|SEARCH TABLE Telemetry AS ss USING AUTOMATIC COVERING INDEX (ServiceId=?) (~5 rows)
0|2|0|SEARCH TABLE Events AS e USING INDEX IX_Events_TelemetryId_TimestampTicks (TelemetryId=? AND TimestampTicks>?) (~1816 rows)
0|0|0|USE TEMP B-TREE FOR ORDER BY

为什么是 B-TREE？如果我反转索引，我实际上会得到更差的性能。这是查询计划：

0|0|0|SEARCH TABLE Events AS e USING INDEX IX_Events_TimestampTicks_TelemetryId (TimestampTicks>?) (~4031303 rows)
0|1|1|SEARCH TABLE Telemetry AS ss USING INTEGER PRIMARY KEY (rowid=?) (~1 rows)
0|2|2|SEARCH TABLE Services AS s USING INTEGER PRIMARY KEY (rowid=?) (~1 rows)

我不知道为什么该排序不允许使用 TelemetryId。我真的需要这个查询更快。有什么帮助吗？

4

1 回答 1

0
  • 指定的索引在 ([TelemetryId],[TimestampTicks]) 上，而不是 ([TimestampTicks])，并且 [TelemetryId] 上没有过滤条件。
  • 如果测试数据库没有完整的工作数据卷，则测试中的执行计划可能无法反映生产中的执行计划。
  • 在选择使用索引之前，数据库引擎会尝试对索引使用是否比表扫描更有效进行建模。如果预期数据量 > ~10% 的表，通常可能会忽略看起来有用的索引。（虽然在这种情况下不太可能。）
  • 追查想象中的性能问题是浪费时间。在这种情况下是否存在真正的性能问题？
于 2013-03-07T18:27:47.673 回答