Проблема с производительностью базы данных SQL Server

У меня есть запрос, который случайным образом начинает использовать другой индекс вместо индекса, который он должен использовать, и производительность запроса ухудшается, поскольку он создает плохой план выполнения, и все последующие выполнения плохие. Запрос генерируется из приложения действием пользователя в приложении. Сгенерированный запрос всегда один и тот же с одним и тем же хэшем sql. Раньше, когда возникала эта проблема, я удалял плохой план из кеша и использовал хранилище запросов, я использовал хороший план выполнения, и запрос возвращался к нормальной производительности. Но сейчас это решение больше не работает. Запрос постоянно выбирает неправильный индекс и, следовательно, создает неправильный план выполнения. Индексы не фрагментированы и статистика тоже обновляется. См. приведенный ниже запрос:

SELECT test_.ROWID, 
   test_.* 
FROM ******.test_table test_ 
WHERE test_.STOFCY_0 = @P1 
AND test_.VCRTYP_0 = @P2 
AND test_.VCRNUM_0 = @P3 
AND test_.VCRLIN_0 = @P4 
AND test_.REGFLG_0 <> @P5 
AND test_.QTYSTU_0 < @P6 
ORDER BY test_.STOFCY_0,
   test_.UPDCOD_0,
   test_.ITMREF_0,
   test_.IPTDAT_0 Desc,
   test_.MVTSEQ_0,
   test_.MVTIND_0 Option (FAST 1)

Предполагается, что запрос всегда возвращает 1 строку.

Мне нужна помощь в устранении этой проблемы, так как я пробовал следующее, и, похоже, ничего не работает, чтобы исправить это навсегда:

• Я пытался перестроить индексы и обновить статистику.
• Удалите плохой план выполнения и принудительно установите хороший план выполнения с помощью хранилища запросов. Это работает в течение нескольких минут, но после этого запрос снова выбирает плохой план.
• Кажется, что оптимизатор SQL оценивает неправильное количество строк.
• У меня нет контроля над изменением запроса, так как он генерируется из приложения.
• Пока запрос может использовать индекс, который я хочу использовать, запрос работает нормально.
• Ранее прикрепленный индекс содержал только столбцы предложения OrderBy. Я также добавил столбцы предложения WHERE, но это также не заставляет запрос всегда использовать этот индекс.

Индекс DDL:

    CREATE UNIQUE NONCLUSTERED INDEX [test_table_index] ON [test_table]
    (
        [STOFCY_0] ASC,
        [VCRTYP_0] ASC,
        [VCRNUM_0] ASC,
        [VCRLIN_0] ASC,
        [REGFLG_0] ASC,
        [QTYSTU_0] ASC,
        [UPDCOD_0] ASC,
        [ITMREF_0] ASC,
        [IPTDAT_0] DESC,
        [MVTSEQ_0] ASC,
        [MVTIND_0] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]