Question

我有这个问题：

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。我真的更需要这个查询。有什么帮助吗？

Answer 1

指定的索引是打开的（[TelemetryId]，[TimestampTicks]），而不是[[TimestampTicks]），[TelemetryId]上没有过滤器标准。
如果测试数据库没有完整的工作数据，则测试中的执行计划可能无法反映生产中的执行计划。
在选择使用索引之前，数据库引擎会尝试建模索引使用比表扫描更有效。如果预期数据量> 1，则通常可以忽略看起来有用的索引。约占表的10％。（虽然在这种情况下不太可能。）
追逐想象中的性能问题是浪费时间的好时机。在这种情况下是否存在真正的性能问题？

为什么Sqlite不使用此ORDER BY的索引？

1 个答案: