我们正在对具有大量数据的 SQL Server 数据库运行密集的应用程序负载（数千次操作/秒）。有些表有数十亿行，其中一些有大量插入和更新。
DB 性能一般都还可以，但我们会时不时地遇到查询性能问题；以前运行良好的相当简单的查询可能会突然花费 10-100 倍的时间。
这似乎与表/索引统计信息和查询优化器有关 - 大多数情况下，统计信息更新将解决问题，然后再次更新统计信息会使情况变得更糟（然后重新运行统计信息更新通常会解决问题最终）。
似乎正在发生的事情是优化器决定对某些查询使用客观错误的索引；突然之间，在使用了正确的方法数天和数周之后。
我的问题是：为什么会发生这种情况，我们能做些什么？
这个数据库已经运行了多年，负载基本相同，查询几乎相同，更新量也相同。对于 99.995% 的查询，应该没有理由随着时间的推移决定不同的索引策略，无论输入如何（而且 - 实际上 - 这样做会明显地完全破坏查询性能）。
如上所述，按计划自动更新统计数据通常会产生可怕的问题——如果统计样本出现偏差（这似乎至少有 5% 的情况发生），我们最终会陷入痛苦的世界。
有没有办法告诉SQL Server（在某些表上）统计直方图和密度不会随时间变化，所以请继续对涉及该表的查询使用相同的查询计划？如果不是，我们如何确保随着时间的推移统计更新的可预测结果（避免上述的偏斜统计问题）？
没有存储过程。我们确实可以控制 SQL，因此它可能会被更改，但它有很多代码，因此如果我们必须更改每个查询（例如添加附加子句），那将是不幸的。
一个后续问题：参数嗅探似乎只与存储过程相关，对吗？