Database 事件日志日期上的DB非聚集索引描述一个坏主意？

我们有一个SQL表，其中填充了来自我们网站的事件（主要是错误记录等）。该表有几个文本字段，其中包含有关事件类型的所有信息，还有一个日期/时间字段，显示记录事件的时间。该表相当大，每天增长约10-100条记录

显然，在浏览此日志时，我们通常会查找最新的项目，因此我认为改进搜索时间的一个明显方法是在日期字段中添加索引。我觉得ASC和DESC都很好，DESC会更好，因为这是我们大部分时间搜索的方式。我们的DB人员说“不可能”…这将非常糟糕，因为索引表将迅速变得支离破碎

我可以理解为什么你不想在date DESC上有一个聚集索引，因为你总是在开始时尝试插入…但我认为使用非聚集索引是可以的，因为记录不需要移动。但他所说的也有道理……仍然需要移动索引

---

但是多少钱？它会有多大的成功？即使它不是很受欢迎，也许它仍然不值得，因为偶尔选择的性能无法提高那么多？想法？

我不认为这是个坏主意——恰恰相反

由于不了解您的数据库系统，我真的无法确定为什么您的DB人员会认为这是个坏主意。即便如此，即使是在日期上增加一个索引也已经非常有益了（至少在SQL Server的情况下是这样）

在这种情况下，如果您经常按日期进行查询，并且通常会检索最新的，那么对我来说，这似乎是一个完美的索引！也许您可以通过添加第二个最可能的选择条件（日志应用程序？日志类型？）使其更好，这样，如果您同时指定日期和第二个条件，则索引中的搜索范围将更加有限

如果我是你，我会尝试对不带此索引的表执行一些示例查询，然后在日志日期上添加非聚集索引-首先使用ASC并测试查询的执行情况（检查它们的执行计划！），然后使用DESC尝试索引，还可能尝试使用logdate和其他条件字段的索引。看看性能如何

---

Marc

索引会加快某些查询，但会降低所有加载速度。索引是否能提高整体性能取决于它在多大程度上加快了实际查询工作负载，在多大程度上降低了实际加载工作负载（以及修改索引列的删除和更新）

在许多（可能是大多数）涉及存储事件数据的应用程序中，正在进行的加载量很大，而查询相对较少，主要是摘要类型的查询，这些查询不会从索引中受益。在这类应用程序中，索引往往弊大于利

---

在许多这样的应用程序中，可以在非工作时间进行加载，因此即使索引导致总体速度减慢，也值得提高查询速度，因为有人正在等待查询输出，但没有人等待加载完成。但是，索引可能会变得太大，以至于文件缓存溢出，每个插入都必须从磁盘读取和写入不同的叶页。此时，加载开始需要线性数量的随机访问磁盘读写，这可能导致加载需要一整天。

您所说的“SQL表”是什么？这是一项新发明吗？@cagcowboy：我没有明确地说，因为我希望这无关紧要……我假设，也许是天真的，索引在各个系统中会相当相似。如果不是这样的话，我很想知道。（对于我们来说，我们使用的是SQL Server，但是对于其他搜索并找到这个答案的人来说，我希望看到其他系统的可能答案，如果它们不同的话。）@skaffman：嗯，如果这是你的意思的话，它不是内置的。但这并不重要……对于这个问题，它只是数据库中至少有两个字段的表……一个字段中包含开发人员想要读取的文本数据，另一个字段中包含日期/时间。但一个潜在的重要方面是记录总是按时间顺序输入…这就是为什么在日期递减上进行聚集索引似乎是一个坏主意。这是有意义的…我们在某种程度上做到了这一点，而且（毫不奇怪）你说得很对：任何一个索引都大大提高了速度。但（对我来说）不明显的是，索引是否会因为不断尝试按时间顺序添加记录而变得支离破碎，而索引却试图做完全相反的事情。以一种非常摇摆的方式，我想说“好吧，天哪，这就是指数擅长的……即使这是最坏的情况，也没那么糟糕。”但我想知道一些方法。当然，我会努力找到一个明确的答案。目前，我建议在这种情况下至少创建并使用LogDate ASC索引。