Оптимизатор запросов оценивает, что результаты объединения будут иметь только одну строку, когда фактическое число строк равно 2000. Это приводит к тому, что последующие объединения в наборе данных будут иметь ожидаемый результат одной строки, когда некоторые из них подняться до 30000.
При числе 1 QO выбирает стратегию циклического соединения / поиска индекса для многих из соединений, которая слишком медленная. Я обошел эту проблему, ограничив возможные стратегии объединения с WITH OPTION (HASH JOIN, MERGE JOIN), что увеличило общее время выполнения с 60+ минут до 12 секунд. Тем не менее, я думаю, что QO все еще генерирует неоптимальный план из-за плохого количества строк. Я не хочу указывать порядок соединения и детали вручную - слишком много запросов затронуты, чтобы это стоило.
Это в Microsoft SQL Server 2000, средний запрос с несколькими выборками таблицы, соединенными с основным выбором.
Я думаю, что QO может переоценить мощность множества сторон в соединении, ожидая, что объединяющие столбцы между таблицами будут иметь меньше общих строк.
Расчетное число строк при сканировании индексов перед объединением является точным, только приблизительное число строк после определенных объединений слишком мало.
Статистика для всех таблиц в БД обновлена и обновляется автоматически.
Одно из ранних неудачных объединений - это между общей таблицей «Персона» для информации, общей для всех людей, и таблицей специализированных персон, к которой принадлежит около 5% всех этих людей. Кластеризованный PK в обеих таблицах (и столбец соединения) является INT. База данных сильно нормализована.
Я считаю, что коренная проблема - это неправильная оценка количества строк после определенных объединений, поэтому мои основные вопросы:
- Как я могу исправить оценку количества строк после присоединения QO?
- Можно ли намекнуть, что в соединении будет много строк без указания всего порядка соединения вручную?