SQL上的聚集索引更改使得传感器数据表的插入速度非常慢(从~30 to到2000 to)

Question

我打算改进我的多租户SaaS系统上的一个大表的性能，以使报告更快。当我在聚集索引上添加一列时，在系统上进行插入操作的时间从~30 to增加到1500~2500 to！在这种情况下，应用于本表的最佳聚集索引选项和非聚集索引是什么：

• 数据库: SQL
• 我只在这个表上执行插入和选择，数据永远不会更新(更新)
• 并发插入的高负载(不同的工作人员和线程使用队列中的数据)
• 100.000行/天(生长)
• 实际上有6毫安行(生长)
• 每个租户只读取他的身份证数据。
• 1租户将拥有100-3000 DeviceId。

表结构：

• TenantID ( bigint ) (我可以使用smallint，但如果将来需要使用Azure联邦，我就改为bigint)。
• DeviceID (int)
• ReadID (bigint) (身份)
• UIDRead (GUID)
• ReadDate (日期时间)
• SensorState1 (丁质)
• SensorState2 (丁质)
• SensorState3 (丁质) ..。
• SensorState10 (丁质)

通常用来读取数据的地方：

-WHERE DeviceId = @X和ReadDate介于@XDate和@YDate之间

-WHERE DeviceId IN (X，Y，Z)和ReadDate在@XDate和@YDate之间

-WHERE TenantId = @Y和ReadDate介于@XDate和@YDate之间

-WHERE TenantId = @X和DeviceID IN (X，Y，Z)和ReadDate介于@XDate和@YDate之间

-WHERE TenantId = @X和DeviceID =@Y和ReadDate介于@XDate和@YDate之间

Answer 1

主钥匙是什么？我假设ReadDate、TenantId和DeviceId是唯一的标识符？如果是这样的话，通过在表定义中声明主键，按照这个顺序对它们进行集群。始终将日期放在时间序列数据聚集索引的前面，因为范围将是连续的。(是的，据我所知，每个租户只读自己的资料。服务器不知道这一点，而且缓存将倾向于保存所有租户的所有数据，因为(我敢打赌)大多数租户都对相同的日期感兴趣。

使用尽可能窄的列。现在不要使用BIGINT，以防您以后想要联合；当这一天到来时，如果它到来了，ALTER TABLE将等待您。使用smalldatetime，除非您需要秒。删除ReadId，因为您已经有了一个自然键，这既浪费了空间，也是资源争用的来源。将UIDRead更改为正常整数，并希望您有超过20亿的读者。

如果结果表接受插入的速度仍然很慢，那么这不是表的错误。看服务器。