Насколько важен порядок столбцов в индексах?
Это ошибка в Eclipse . Похоже, что Eclipse использует отдельные потоки для чтения содержимого потоков out и err без какой-либо синхронизации.
Если вы скомпилируете класс и выполните его в консоли (с классическим java ), , порядок будет таким, как ожидалось.
3 ответа
Посмотрите на индекс, подобный этому:
Cols
1 2 3
-------------
| | 1 | |
| A |---| |
| | 2 | |
|---|---| |
| | | |
| | 1 | 9 |
| B | | |
| |---| |
| | 2 | |
| |---| |
| | 3 | |
|---|---| |
Посмотрите, как ограничение по A first, поскольку ваш первый столбец устраняет больше результатов, чем ограничение по вашему второму столбцу первым? Будет проще, если вы представите себе, как нужно пройти по индексу: столбец 1, затем столбец 2 и т. Д. Вы увидите, что отсечение большей части результатов в первом проходе значительно ускоряет второй шаг.
Другой случай: если вы запросили столбец 3, оптимизатор даже не стал бы использовать индекс, потому что он совершенно бесполезен для сужения наборов результатов. Каждый раз, когда вы выполняете запрос, сокращение количества результатов, которые нужно обработать до следующего шага, означает более высокую производительность.
Поскольку индекс также сохраняется таким образом, нет никакого возврата по индексу, чтобы найти первый столбец, когда вы запрашиваете по нему.
Короче: нет, это не для галочки, есть реальные преимущества в производительности.
Порядок столбцов имеет решающее значение. Теперь какой порядок правильный, это зависит от того, как вы собираетесь его запрашивать. Индекс можно использовать для точного поиска или сканирования диапазона. Точный поиск - это когда значения для всех столбцов в индексе указаны и запрос попадает точно в интересующую строку. Для поиска порядок столбцов не имеет значения. Сканирование диапазона - это когда указаны только некоторые столбцы, и в этом случае порядок становится важным. SQL Server может использовать индекс для сканирования диапазона, только если указан крайний левый столбец, и только если указан следующий крайний левый столбец, и так далее. Если у вас есть индекс для (A, B, C), его можно использовать для сканирования диапазона для A = @ a , для A = @ a AND B = @ b , но , а не для B = @ b , для C = @ c или B = @ b AND C = @ c . Случай A = @ a AND C = @ c является смешанным, так как в части A = @ a будет использоваться индекс, но C = @ c нет (запрос будет сканировать все значения B для A = @ a , не будет «переходить» к C = @ c ). В других системах баз данных есть так называемый оператор «пропуска сканирования», который может использовать некоторые преимущества внутренних столбцов в индексе, когда внешние столбцы не указаны.
Обладая этими знаниями, вы можете снова взглянуть на определения индексов. Индекс для (MostSelective, SecondMost, Least) будет эффективен, только если указан столбец MostSelective . Но это самый избирательный подход, и релевантность внутренних столбцов быстро ухудшится.Очень часто вы обнаружите, что лучший индекс находится на (MostSelective) include (SecondMost, Least) или на (MostSelective, SecondMost) include (Least) . Поскольку внутренние столбцы менее актуальны, размещение столбцов с низкой селективностью в таких правильных позициях в индексе делает их не чем иным, как шумом для поиска, поэтому имеет смысл переместить их с промежуточных страниц и оставить их только на конечных страницах, так как для целей покрываемости запроса. Другими словами, переместите их в ВКЛЮЧИТЬ. Это становится более важным по мере увеличения размера столбца Наименьшее . Идея состоит в том, что этот индекс может принести пользу только запросам, которые указывают MostSelective либо как точное значение, либо как диапазон, и этот столбец является наиболее избирательным, он уже в значительной степени ограничивает строки-кандидаты.
С другой стороны, индекс по (Least, SecondMost, MostSelective) может показаться ошибкой, но на самом деле это довольно мощный индекс. Поскольку он имеет столбец Наименьшее в качестве самого внешнего запроса, его можно использовать для запросов, которые должны агрегировать результаты по столбцам с низкой избирательностью. Такие запросы распространены в OLAP и хранилищах данных анализа, и именно здесь такие индексы имеют очень хороший пример. Такие индексы фактически составляют отличные кластерные индексы именно потому, что они организуют физическую компоновку на больших кусках связанных строк (то же самое Наименьшее значение, которое обычно указывает какую-то категорию или тип), и они облегчить анализ запросов.
Так что, к сожалению, «правильного» порядка не существует.Вам не следует следовать никаким рецептам резака для печенья, а вместо этого проанализировать шаблон запроса, который вы собираетесь использовать для этих таблиц, и решить, какой порядок столбцов индекса правильный.
вы должны поместить столбцы, которые будут наиболее избирательными, в начале объявления индекса.
Верно. Индексы могут быть составными - состоящими из нескольких столбцов - и порядок важен из-за принципа крайнего левого угла. Причина в том, что база данных проверяет список слева направо и должна найти соответствующую ссылку на столбец, соответствующую определенному порядку. Например, наличие индекса в адресной таблице со столбцами:
- Адрес
- Город
- Штат
Любой запрос, использующий столбец адрес , может использовать этот индекс, но только если запрос имеет ссылки город и / или штат - индекс использовать нельзя. Это потому, что на крайний левый столбец нет ссылки. Производительность запроса должна подсказать вам, что является оптимальным - отдельные индексы или несколько составных частей с разным порядком. Хорошее чтение: Переломный момент , Кимберли Трипп