事件日志日期上的DB非聚集索引说明了一个坏主意?

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

不知道你的数据库系统,我真的不知道为什么你的数据库管理员会认为这是个坏主意。即便如此,即使是当天的升序索引也会非常有益(至少在SQL Server中是这样)。

在这种情况下,如果您经常按日期进行查询,并且通常会检索最新的日期,这对我来说似乎是一个完美的索引!也许您可以通过添加第二个最有可能的选择条件(日志应用程序)使其变得更好。日志类型?)这样,如果您同时指定日期和第二个条件,搜索范围在索引中会受到更大的限制。

如果我是您,我将尝试对没有此索引的表进行一些示例查询,然后在日志日期上添加非聚集索引-首先使用asc并测试查询的执行情况(查看它们的执行计划!),然后使用desc尝试索引,也可能使用logdate和其他条件字段尝试索引。看看表现如何。

马克

索引加速了一些查询,但减慢了所有加载。索引是否提供整体性能改进取决于它如何加速实际查询工作负载,以及它如何减慢实际加载工作负载(以及删除和更新修改索引列)。

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

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