Предполагаемые номера строк в SQL Server 2012 сильно отличаются от фактических - PullRequest
Новая
       30

Предполагаемые номера строк в SQL Server 2012 сильно отличаются от фактических

0 голосов
/ 16 октября 2018

У меня есть запрос, который соединяет две таблицы.TABLE_1 имеет 15 000 строк, а TABLE_2 имеет 50 000 строк.Запрос, очень похожий на этот, выполнялся в прошлом примерно за 10 минут.Теперь он работает бесконечно с той же серверной ситуацией (то есть больше ничего не работает), и очень похожий запрос также выполняется бесконечно.

SELECT A.KEY_1
      ,A.FULL_TEXT_1
      ,B.FULL_TEXT_2
      ,B.KEY_2
      ,MDS_DB.MDQ.SIMILARITY(A.FULL_TEXT_1,B.FULL_TEXT_2, 2, 0, 0) AS confidence
FROM #TABLE_1 A
CROSS JOIN #TABLE_2 B
WHERE MDS_DB.MDQ.SIMILARITY(A.FULL_TEXT_1,B.FULL_TEXT_2, 2, 0, 0) >= 0.9

Когда я запускаю примерный план выполнения для этого запроса, узел Nested Loops (Inner Join) оценивается в 96% выполнения.Предполагаемое количество строк составляет 218 миллионов, хотя при перекрестном соединении таблиц должно получиться 15 000 * 50 000 = 750 миллионов строк.Когда я добавляю INSERT INTO #temp_table в начало запроса, предполагаемый план выполнения помещает Insert Into в 97% и оценивает количество строк в 218 миллионов.В действительности должно быть менее 100 совпадений, у которых показатель сходства выше 0,9.

Я читал, что большие различия в оценочном и фактическом количестве строк могут повлиять на производительность.Что я могу сделать, чтобы проверить / исправить это?

Ответы [ 3 ]

0 голосов
/ 16 октября 2018

Ссылка, предоставленная scsimon, поможет вам доказать, статистика это или нет.Значительно ли изменились оценки с того момента, когда он работал быстро?

На ум приходит параллелизм.Если запрос выполнялся параллельно, а сейчас нет (например, изменились настройки сервера или статистика), это может привести к значительному снижению производительности.

0 голосов
/ 16 октября 2018

Для повышения производительности используйте параметр minScoreHint .Это позволяет избежать расчета полного сходства для многих пар и досрочного выхода.

Так что это должно выполняться быстрее: 

SELECT A.KEY_1
      ,A.FULL_TEXT_1
      ,B.FULL_TEXT_2
      ,B.KEY_2
      ,MDS_DB.MDQ.SIMILARITY(A.FULL_TEXT_1,B.FULL_TEXT_2, 2, 0, 0, 0.9) AS confidence
FROM #TABLE_1 A
CROSS JOIN #TABLE_2 B
WHERE MDS_DB.MDQ.SIMILARITY(A.FULL_TEXT_1,B.FULL_TEXT_2, 2, 0, 0, 0.9) >= 0.9

Из документов не ясно, будут ли включены результаты 0,9.Если нет, измените 0,9 на 0,89

0 голосов
/ 16 октября 2018

Я читал, что большие различия в оценочном и фактическом количестве строк могут повлиять на производительность.Что я могу сделать, чтобы проверить / исправить это?

Да, это правда.Особенно это касается оптимизации, включающей алгоритмы объединения, алгоритмы агрегирования и индексы.

Но это не так для вашего запроса.Ваш запрос должен объединить вложенные циклы без индексов.Все пары значений в двух таблицах необходимо сравнить.Существует небольшая алгоритмическая гибкость, и (стандартные) индексы не могут помочь.

...