Составное первичное и кардинальное

Question

У меня есть несколько вопросов о составных первичных ключах и количестве столбцов. Я искал в Интернете, но не нашел однозначного ответа, поэтому пытаюсь снова. Вопросы:

Контекст: большие (50–500 млн. Строк) таблицы подготовки OLAP, а не NOSQL и не столбцы. MySQL и DB2

1) Имеет ли значение порядок ключей в ПК?

2) Если количество столбцов сильно различается, что следует использовать в первую очередь. Например, если у меня есть CLIENT / CAMPAIGN / PROGRAM, где CLIENT очень кардинальный, CAMPAIGN умеренный, PROGRAM почти как растровый индекс, какой порядок лучше?

3) Какой порядок лучше всего подходит для Join, если есть предложение Where и когда нет условия Where (для представлений)

Заранее спасибо.

Answer 1

У вас есть "MySQL и DB2". Этот ответ для DB2, MySQL не имеет ничего из этого.

Да, конечно, это логично, но оптимизатор учитывает гораздо больше, чем просто это.

Как правило, порядок столбцов в предложении WHERE (объединение) не имеет (и не должен) иметь значение.

Однако есть два пункта, связанных с порядком предикатов, которые могут быть причиной вашего вопроса.

1. Что имеет значение, так это порядок столбцов в индексе , для которого обрабатывается предложение WHERE. Да, там лучше всего указывать столбцы в порядке наивысшей мощности множества к наименьшему. Это позволяет оптимизатору ориентироваться на меньший диапазон строк.

   • И в этом отношении не стоит реализовывать индексы для столбцов с одним столбцом и низкой мощностью (они бесполезны). Если индекс верен, он будет использоваться чаще.
     .

2. Порядок объединения таблиц (не столбцов в объединении) имеет большое значение, это, пожалуй, самое важное соображение. Фактически, переходное закрытие присоединения является автоматическим, и оптимизатор оценивает все возможные порядки соединения и выбирает то, что он считает наилучшим, основываясь на статистике (именно поэтому UPDATE STATS так важно).

   Независимо от количества строк в таблицах, если вы объединяете 100 строк из table_A с плохим индексом с 1 000 000 строк в table_B с хорошим индексом, вам нужен порядок A: B, а не B: A. Если вы получаете меньше IOPS, вы можете что-то с этим сделать.

   Правильная последовательность шагов неудивительна:

   • проверьте правильность индекса согласно (1). Не просто добавьте другой индекс, исправьте те, которые у вас есть.

   • проверка того, что обновление статистики выполняется регулярно

   • всегда сначала пробуйте работу оптимизатора по умолчанию. Установите статистику и измерьте количество операций ввода-вывода. Используйте репрезентативные наборы значений (которые пользователь будет использовать в производстве).

   • Проверьте план Shoow, чтобы убедиться, что код правильный. Конечно, это также определит выбранный порядок соединения.

   • , если производительность недостаточно высока, и вы считаете, что порядок соединения, выбранный оптимизатором для этих наборов значений, является неоптимальным, SET JTC OFF (синтаксис зависит от вашего версия DB2), затем укажите требуемый порядок в предложении WHERE. Измерьте входы / выходы. Используйте репрезентативные наборы

   • сформировать мнение. Выберите тот, который лучше в целом. Никогда не настраивайтесь на одиночные запросы.

Answer 2

1) Имеет ли значение порядок ключей в ПК?

Да, он меняет порядок записи для индекса, который используется для отслеживания PRIMARY KEY.

2) Если количество столбцов сильно различается, что следует использовать в первую очередь. Например, если у меня есть CLIENT / CAMPAIGN / PROGRAM, где CLIENT очень кардинальный, CAMPAIGN умеренный, PROGRAM почти как растровый индекс, какой порядок лучше?

Для запросов на выборку это полностью зависит от запросов, которые вы собираетесь использовать. Если вы ищете все три столбца одновременно, порядок не важен; если вы ищете два или один столбец, он должен быть ведущим в индексе.

Для вставок лучше, чтобы ведущий столбец соответствовал порядку, в котором вставляются записи.

3) Какой порядок лучше всего подходит для Join, если есть предложение Where и когда нет условия Where (для представлений)

Опять же, это зависит от предложения WHERE.