繁忙的表，索引或不索引

Question

SQL Server，非常繁忙的表，随时为大约 6-10K 用户保存活动，并且每次点击都有插入/更新/删除。

我没有在这个表上使用索引，因为写入的任何数据都不会停留超过 10 分钟。

但在观看活动监视器时，我注意到 SQL Server 建议向该表添加索引。

我知道在表上保留索引是有代价的，你认为我应该添加索引吗？

更新详情： SQL 2008 R2

表格

     [id] [bigint] IDENTITY(1,1) NOT NULL,
     [siteid] [int] NOT NULL,
     [last_seen] [datetime] NOT NULL,
     [ua] [varchar](250) NOT NULL,
     [ip] [varchar](15) NOT NULL,
     [t_id] [int] NOT NULL

建议索引

ON [dbo].[onlines] ([ua],[ip],[t_id])

Answer 1

在写入表期间添加索引成本。 （插入、更新、删除操作）。它可以提高读取性能（SELECT、UPDATE、DELETE 操作）。因此，如果您的读取次数多于写入次数，那么可以，索引可以帮助您。如果你读的比写的少得多，那么索引可以帮助你，因为你不必读那么多（索引基本上是表的一个小子集，如果你的选择只命中那个子集，那么你可以加快读取速度在某些情况下相当）

我会添加索引并监控性能，如果它不适合您然后删除索引。最终，唯一确定的方法是尝试并比较结果。

Answer 2

数据存在的时间并不能告诉您是否需要建立索引。但是更新率与读取率确实如此。没有索引的插入是最快的。更新和删除可能不是，因为在搜索要更改的记录时，它们可能会受益于索引。选择也受益于索引。

所以通常最好有索引，即使一个表有很多更新。一般的例外是用于记录的表，您通常只写入该表，除非您确实需要该日志。

但可以肯定的是，您最好在其中放置一个索引并监控性能提升或提升。

Answer 3

拥有一个良好的集群键实际上可以加速甚至你的插入（阅读 Kimberly Tripp 的优秀博文 The Clustered Index Debate Continues 以获得出色而彻底的解释，为什么会这样）！而且从外观上看，您根本没有聚类键。

因此，我绝对建议在您的 id 列上添加主键/集群键 - 它非常适合良好的集群键：窄、静态、唯一、不断增加：

CREATE UNIQUE CLUSTERED INDEX CIX_YourTableName
  ON dbo.YourTableName(ID)

这应该会加快一切 - 插入、更新、删除和选择。

您是否需要额外的索引（以及要索引的列）取决于您的 SELECT 查询 - 因为您并没有真正告诉我们有关这些的任何信息，我们只能猜测......

基本上，你需要做什么：

• 建立基线 - 衡量您的表现
• 然后应用有意义的索引 - 包括 WHERE 子句和/或 ORDER BY 表达式中使用的列
• 再次测量并比较

真的没有什么神奇的公式可以决定您是否需要索引、它是什么以及它对您的场景有多大帮助（或者它会在多大程度上损害 INSERT 性能）——您需要在您的数据库上衡量自己，您的硬件，您的环境。