请修复您的搜索和导航（查找）索引工作

曾几何时，一位同事要求我调查一个客户数据库，该数据库的数据库日志使用量出现了奇怪的峰值。 （你可能会开始想知道为什么我总是那个研究奇怪事物的人，这里有一个模式吗）

在检查查询存储时，我注意到与 tblScheduledItem 相关的逻辑读取非常高。 根据过去的经验，这可能是因为该表中的索引碎片（只有一个聚集）。 我快速查看了该表，并确认该索引确实具有很高的碎片。 我建议重建该索引，看看会发生什么。 好吧，这可能是日常简单的快速问题之一，但我几乎忘记了。

过了几天，同事又给我打电话。 显然他们重建了它，但这并没有真正帮助。 这让我的眉毛有点扬起，所以我挖得更深。

令我惊讶的是，问题并不是真正的碎片化（它肯定有所贡献）。 问题是该列有一个类型的列 nvarchar(max) ，它用于记录最后的文本 Execute 预定作业的方法。 它的意思是“作业成功失败”或“从 1337 个内容中删除了 12345 个版本”之类的简短内容。 但因为它是 nvarchar(max) 它可能会非常非常长。 理论上，您可以将几个非常大的图书馆的全部图书内容存储在那里。

当然，因为你可以，并不意味着你应该。 当你的列很长时，每次从表中读取都会对SQL Server造成负担。 而令人讨厌的工作正是我们的 S&N 索引工作。

理论上，任何作业都可能导致此问题，但 S&N 索引作业更有可能发生此问题，原因是它会跟踪索引过程中抛出的每个异常，并且因为它会索引网站的每个内容（除了如果您特别明确地告诉它不要这样做），那么它遇到影响多个（读取，大量）内容的重复出现问题的机会比任何内置作业要高得多。

这次我要求修剪列，最重要的是，修复索引期间可能引发的任何异常。 当我休息的时候，我的同事注意到我的作业运行了 10 个小时，没有出现任何错误，并修复了它。 出于好奇，我查了一些统计数据。 好吧，让这些屏幕截图说明一切：

查询本身从 16.000 毫秒缩短到了 2.27 毫秒。 更好的是，每次调用之前获取计划作业列表都会产生 3.5GB 逻辑读取。 现在？ 100KB。 节省大量资源！

因此，请确保您的工作不会抛出很多错误。 并修复您的 S&N 索引工作。

P/S：我确实认为 S&N 索引作业应该有更简单的返回结果。 也许“索引了 100.000 个内容，有 1234 个错误”，并且可以记录异常。 但这是有争议的。 现在，你可以做你的部分了！