解决由于参数嗅探引起的间歇性性能问题

Question

我有一个程序由于参数嗅探而出现性能问题。该过程是昂贵的，但是通常在典型的负载下在可接受的时间内执行。但是，它将定期表现不佳。发生这种情况时，我们看到执行该过程的会话会并行进行。我们将看到执行例程的会话数开始增加。我们通过从缓存中拉出该过程的计划，取消活动会话并监视是否立即发生（例如，当一个坏计划最终返回到缓存中时）来解决该问题。

该过程在典型的OLTP数据库中（许多小型DML查询）。当主题查询执行不佳时，它将导致CPU峰值并降低相关服务的性能。在工作时间内，该过程每分钟执行5次以上（没有确切的计数）。该过程的计划在这里：

https://www.brentozar.com/pastetheplan/?id=S1aEVQJBN

查询中的所有列（联接列和投影列）都被索引覆盖。

以下是我正在权衡的选项：

1. 我们可以将Option Recompile应用于例程中有问题的select语句。
2. 我们可以进行一些研究，找到一个参数值，该参数值会生成一个通常对“一切”都有利的计划。然后，将以下OPTIMIZE FOR添加到函数中。这将招致一些技术债务，因为我们可能需要加班调整此值。
3. 我们可以在过程中引入分支逻辑。如果参数值为X或范围-X，则将执行sproc，否则，将运行sproc。同样，会产生一些技术债务。
4. 我们可以将有问题的语句更改为动态SQL。这将导致为每个唯一的SQL语句生成一个计划。如果我们收到此过程的大量唯一调用，则可能会使计划缓存膨胀。
5. 在有问题的选择语句上拍一个MAXDOP为“ 1”。

我排除的选项：

1. 我们可以针对未知进行优化。这将更改记录估计的密度矢量，并为此优化操作。

我错过了任何明智的选择吗？哪些选项最有意义？