为何IoTDeviceParameter表始终执行Clustered Index Scan而非Seek？

针对IoTDeviceParameter表仅55行但查询始终走聚集索引扫描的问题，核心原因是SQL Server查询优化器认为小表扫描的成本低于非聚集索引查找（小表扫描的IO开销极低，甚至低于索引查找的逻辑开销）。以下是具体解决方案：

• 强制使用非聚集索引：在关联查询中指定使用创建的非聚集索引，直接引导优化器走索引路径。示例：

  SELECT -- 你的查询字段
  FROM inputDatas i
  JOIN IoTDeviceParameter p WITH (INDEX(IX_IoTDeviceParameter_TenantId_DeviceId))
    ON i.TenantId = p.TenantId AND i.DeviceId = p.DeviceId
  -- 其他查询条件
  

  注意：当未来表数据量显著增长时，需取消强制索引，让优化器重新评估最优路径。

• 更新表统计信息：若统计信息过时，优化器可能对表规模判断偏差，导致执行计划选择不当。执行以下语句更新统计信息：

  UPDATE STATISTICS [dbo].[IoTDeviceParameter] WITH FULLSCAN;
  

• 确保查询条件与索引键完全匹配：确认你的关联/过滤条件严格使用索引的键列（TenantId、DeviceId），无额外导致索引失效的隐式转换（如数据类型不匹配）。若有其他过滤条件，检查是否已包含在索引的INCLUDE列中（你的索引已包含所需字段，此点大概率没问题）。

• 预加载小表到内存：由于表仅55行，执行一次全表查询将数据加载到SQL Server缓冲池，后续扫描操作将完全在内存中进行，大幅降低耗时：

  SELECT * FROM [dbo].[IoTDeviceParameter];
  

内容的提问来源于stack exchange，提问作者David Stania