NHibernate 自动使用带有不同参数的 sp_executesql 来执行它的数据。现在我们在生产中注意到的是，我们有时会受到参数嗅探的影响。通过这种方式，查询性能不仅会受到影响，而且实际上会导致超时。
我不是 DBA，所以我有点犹豫，但对我来说，查询似乎正在针对少量数据（10 行）进行优化，然后必须查询大量数据（150000 行），这些数据正在打磨它停止。
现在我发现了 4136 Trace，它完全禁用了 SQL Server 实例的参数嗅探。
现在，由于我们也在升级我们的一些服务器，我想知道 NHibernate 在 SQL Server 2008 上的行为是否与 2005 年有所不同。例如，它是否添加了 OPTIMIZE FOR UNKOWN 点点滴滴。
据我所知，SQL 2008 中添加了一些“工具”，以便更好地处理这些参数嗅探问题。我很好奇 NHibernate 是否采用了这些工具并使用它们，或者如果我们更改为 SQL Server 2008，我们仍然必须使用此跟踪或类似的东西来处理这些问题。
这个问题一直困扰着我一段时间，但我实际上修复了导致问题的查询（在我最终找到它们之后）但我很好奇它是否是一个 SQL 进程，这是我们的raidcontrollers是狗屎的潜在问题还是什么问题真的是。所以这就是一直困扰我们的场景。
@ 11:10~ 和 01:10~ 服务器会给出这些 IO 错误，即使通过远程桌面服务器也会失败，管理工作室会超时，一切都将指向集群即将失败。
（服务器是相同的，我们运行 Windows Server 2012 标准，群集在运行 SQL Server 2012 企业版的 AlwaysOn 中）。
大约 5-15 分钟后，服务器将恢复运行（除了事件 ID 833 是“众所周知的”：SQL Server 已遇到 16870 次 I/O 请求花费的时间更长，事件日志中没有任何内容15 秒内完成数据库 [XXXXX] 中的文件 [E:\XXXXXXXX.mdf] (10). OS 文件句柄为 0x0000000000001284。最新的 long I/O 的偏移量为：0x0000041fb3c000。
现在我正在运行分析器以找出正在运行的查询，并尽我所能找出导致服务器冻结并拒绝正常服务的原因。事件日志针对特定的数据库，我朝那个方向搜索，昨天我发现了一张对我来说看起来很奇怪的表。
特定的表有 11 演出大，有价值 23 演出的索引（还没有研究这些，但对我来说这似乎是错误的）并且有 8000 万条记录。考虑到该表应该容纳大约 200 万个并且增长相对缓慢，这激发了我的兴趣，我发现了三个填充该表的存储过程。
所有三个存储过程都有缺陷，这使得它们每次运行时插入的记录不是几百条而是超过 500.000。（这些现在已修复，因此问题不会出现，但我觉得这里存在潜在问题）。
这些存储过程将在 09:00 和 23:00 运行（恰好在问题发生前 2 小时）。程序本身大约需要 5 分钟才能完成。
现在我想知道为什么在有问题的实际存储过程已经完成后，服务器需要两个小时才能开始死在我身上。那时我没有运行任何索引维护，或者其他任何事情（这是我检查的第一件事）。据我所知，在特定时间没有运行@。可能是 SQL Server 做了一些“自我维护”，并注意到一些索引需要进行碎片整理或其他什么，即使我没有要求任何这样的事情？
是不是我们的raidcontrollers（或者甚至是连接到它们的SSD）有缺陷并且在很多活动决定在2小时后显示降级迹象？
我根本无法解释这种行为，我担心我们的生产服务器可能不可靠（这会很糟糕，因为它们大约有 4 个月大）。现在我昨晚已经解决了这个问题，24 小时以来我们都没有遇到过这个问题（除非它稳定了多天，否则我不会称它为“已解决”）但我仍然很好奇我的到底是什么服务器正在做。