МуМу
Дата: 25.02.2010 13:27:29
Есть SQL 2005 и голый сервис пак 3-и. Есть запрос с определенным количеством вложенных подзапросов. В одном случае работает быстро в другом медленно.
Быстро - 2 сек., входящие параметры с 15-ое по 17-ое.
Медленно - 1 мин , входящие параметры с 17-ое по 19-ое.
Выборки приблизительно одинаковые. Анализ планов запроса показал что в медленном случае идут вложенные циклы а в быстром случае объединение мердж джоином. Понятно что сам по себе запрос оказался не оптимально написанным но это дело второе. Также проблема быстро решилась явным указанием опции merj join. Но интересно другое. Анализ планов показал что в одном случае (15-17) в под запросе вернется 2000 записей а в случае (17-19) оптимизатор думает что в под запросе вернется 1300000 записей(все количество записей в таблице). Соответственно во втором случае оптимизатор делает не верное предположение. Включение опции актуального плана запроса(не предполагаемого) все равно показывает неверное количество возвращаемых строк. Разумеется пересчет статистики делал - не помогает. Что интересно - помогает пересчет индексов, с небольшой долей это может быть не верным утверждением потому как лично я пересчет индексов не делал - со слов другого исполнителя(в рабочей системе не мог).
Кто нибудь сталкивался с подобной проблемой? Помогаеют ли кумулятивные обновления к sp3(пока нет возможности проверить)?