Композитный первичный элемент и мощность

Question

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

Контекст: Большой (50M - 500M строк) OLAP Prep tables, а не NOSQL, а не Columnar. MySQL и DB2

1) Имеет ли порядок ключей в PK?

2) Если мощность колонок сильно изменяется, ее следует использовать в первую очередь. Например, если у меня есть CLIENT/CAMPAIGN/PROGRAM, где КЛИЕНТ очень кардинален, CAMPAIGN умерен, PROGRAM почти похожа на растровый индекс, какой порядок лучше?

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

Спасибо заранее.

Answer 1

1) Имеет ли порядок ключей в PK?

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

2) Если мощность колонок сильно изменяется, ее следует использовать в первую очередь. Например, если у меня есть CLIENT/CAMPAIGN/PROGRAM, где КЛИЕНТ очень кардинален, CAMPAIGN умерен, PROGRAM почти похожа на растровый индекс, какой порядок лучше?

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

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

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

Опять же, это не зависит от пункта WHERE.

Answer 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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