Оптимизатор любой базы данных, основанной на затратах, всегда полон сюрпризов, и этот случай не является чем-то необычным для платформ, с которыми я знаком.
Пара вопросов: - статистику по таблице создали? (иначе вы летите вслепую) - какой тип данных для этого столбца? (я надеюсь, что это какое-то целое число, а не ЧИСЛО (x, y), даже если y = 0)
Кроме того: статистика для столбца в netezza не содержит статистики распределения (он не будет знать, больше ли «решенных», чем «нерешенных» дел в таблице системы поддержки с данными за 5 лет). Вместо этого он опирается на две вещи: 1) для всех таблиц: простая статистика, если вы их создаете (количество различных значений, максимальные + минимальные значения, количество нулей) 2) для больших таблиц (я думаю, что настраиваемое минимальное значение близко до 100 миллионов строк) он создает JIT-статистику (Just In Time), сканируя несколько случайных страниц данных в срезах данных, которые все соответствуют зонально-сопоставляемым предложениям where, и создавая статистику для этого одного запроса.
Последняя функция на самом деле довольно мощная, хотя она добавляет время выполнения на этапе планирования запроса. Это значительно увеличивает вероятность того, что если есть НЕКОТОРАЯ корреляция между двумя операторами where в таблице, это будет принято во внимание. Пример: пункт where на (AGE>60 и Retired=true) в списке всех жителей крупного города. Скорее всего, добавление ограничения AGE более или менее неуместно, и Netezza об этом знает.
В общем, вам не следует беспокоиться о том, что предполагаемое количество строк немного отличается (как в этом случае) от netezza, чаще всего оно будет «достаточно правильным» и задействует аппаратное обеспечение для компенсации любых незначительных ошибок.
До недавнего времени я работал с SQLserver, который печально известен (может быть, лучше в более новой версии) из-за чрезмерного оптимизма в отношении значения предложений where и заканчивая планами доступа с 5 уровнями соединений с вложенными циклами с миллионами строк в каждом, когда объединение 6 столов. Изменение предложений where так же, как вы сделали в вопросе, приведет к тому, что sqlserver будет уделять меньше внимания конкретному ограничению, и это может привести к тому, что 5 объединений станут более эффективным HASH или другим алгоритмом, что приведет к повышению производительности. По моему опыту, это НАМНОГО слишком часто происходит в базах данных, которые СЛИШКОМ сильно зависят от этих оценок - возможно, потому, что оптимизатор не был создан/настроен для рабочей нагрузки, подобной складской.
person
Lars G Olsen
schedule
14.01.2017
