小编Dir*_*oer的帖子

我刚刚想到默认的 Identity Seed 是 1。我知道有些表在某个时候会增长到数十亿。int.Min对于这些表，从(-2,147,483,648)开始不是更有意义吗？

这可能只是bigint在 4 年或 8 年内将您的密钥迁移到不同。可以足够相关。

这是常见的吗？感觉很奇怪。有什么我想念的吗？

我有一个相对较大的表（对我来说）有 4000 万行，预计在两周内（在活动期间）会增长到 80 到 1.2 亿行。

Tip
--------------
Id          int (clustered index)
UserId      int
TipIndex    smallint
Value       binary(8)
LastChanged datetime2(3)

• 每个用户都有 1 到 400 个提示，这些提示将在此期间随机插入
• UserId + TipIndex 是唯一的
• 我从不直接在身份密钥 (Id) 上查询 Tips
• 我查询 UserId 的次数有 99%
• 我需要所有列
• 我经常查询 1 个 UserId（每个页面视图），有时查询 10.000 个批次的统计信息
• 这是在此期间的高流量站点，它应该能够每分钟处理 30.000 次 UserId 查询
• Id 目前是我的聚集索引，因为我读到它导致最少的碎片化。

所以我托管在 SQL Azure 上，Azure 已经建议添加一个包含列的索引。我总是犹豫是否使用 UserId,TipIndex 作为聚集索引，因为 Tips 会随机添加。这意味着我害怕巨大的碎片问题等。

我的问题：

• 包含列的索引没有完全相同的问题吗？
• 包含列的表是否与具有相同碎片问题的“影子表”相同？
• 我应该迁移以使用 UserId、TipIndex 作为 ClusteredIndex 而不是 Id？
• 如何防止碎片化？

我知道最终答案总是“取决于”或者我应该衡量它。但由于我是一名单独的开发人员并且没有很多资源，我希望有更多经验的人对此有直觉，所以我的第一次尝试有更高的机会朝着正确的方向前进。

该表确实有一个身份密钥（当前 CI），但它几乎不用于查询。因为自然键不会不断增加，所以我担心插入性能、碎片或其他我现在无法预见的问题。

桌子并不宽，只有几列。它有大约 800 万行，并且在高峰时段使我们的网站停止运行。（+1000s 并发用户）。数据不容易缓存，因为它非常不稳定并且必须保持最新状态。

自然键的一列有很多读取，但插入和更新也相当活跃。说 8 次读取，1 次更新 vs 1 次插入。

Id (PK)         int
UserId*         int
Key1*           varchar(25)
Key2*           varchar(25)
Key3*           int
LastChanged     datetime2(7)
Value           varchar(25)
Invalid         bit

* this combination is the natural primary key

我大部分时间都需要查询：

• 一个 UserId 的所有行（查询最多）
• UserIds 列表的所有行（很多行）
• Key1 = X 的 UserIds 列表的所有行
• Key2 = X 的 UserIds 列表的所有行
• Key1 = X 和 Key2 = X 的 UserId 列表的所有行

我知道最终的答案总是“描述它”，但我们在这里的时间非常有限，因此我们非常感谢您提前提供任何指导或有经验的意见。

提前致谢，

Points
------------------
PK  QuestionId  int (+30.000.000 distinct values)
PK  EventId     int (large batches where 80.000 rows have the same EventId)
    Value       smallint

该表大约有 4000 万行并且存在性能问题。

有两个主要查询：

关于QuestionId：

• 大约 3000 万个不同的QuestionId值（很多变化）
• 繁忙时段的大量查询（每分钟数千次）

在EventId 上：

• 将有 +150.000 行的批量更新where EventId=X来设置Value=NULL非常繁忙的时刻。

所以我第一个想获得最佳性能的想法是我制作EventId,QuestionIdClusteredIndex 以便批量更新可以轻松找到彼此接近的所有 EventId 并直接更新值。

我的第二个想法是添加一个包含QuestionId和包含列 的索引，Value以便它可以直接从索引中读取值（EventId在这种情况下无关紧要）。

但后来我想：聚集索引会重要吗？由于索引中包含的列值也需要在批量更新期间更新。

• 虽然不牺牲查询性能 - 是否可以快速获得批量更新（几秒钟），或者我必须接受这个过程在不升级硬件的情况下总是很慢。
• 还有其他想法什么是设置 ClusteredIndex / Indexes 的最佳方法？

我知道理论上我应该测试所有内容并对其进行测量，但是该站点是实时的并且被大量使用。

我是一名独立开发人员，我没有资源聘请某人。对此的任何估计猜测和想法都将非常有帮助，因为这已经为我提供了正确的方向！

在 SQL Server 中，可以设置标识列的增量不是 1。

在什么情况下你会这样做？