Xpoint
   [напомнить пароль]

Оптимизация запросов с помощью индексов: История

Внимание! Данный интерфейс находится в стадии глубокой переделки. Наберитесь терпения.

Последнее изменение

8 лет назад Антон Клесс[досье] изменил текст:
Текст:
Индекс -- отдельно хранимая информация о значениях в колонке(ах) таблицы с целью ускорения поиска записей по указанным значениям.¶

Допустим, в таблице нет индексов, тогда для того, чтобы найти все строки, где определенное поле равняется заданомузаданному значению, серверу придется перебрать все записи в таблице и для каждой записи сравнить значение в колонке с указанным. При наличии же индекса сервер может получить расположение искомых строк, используя информацию, хранящуюся в индексе, на порядок быстрее.¶

Существуют различные алгоритмы формирования индексов(типы инедксов): BTREE, HASH, FULLTEXT и другие.¶


== Выборки из одной таблицы¶

Возьмем таблицу пользователей с набором личной информации, проиндексировануюпроиндексированную по адресу электронной почты. Вот пара простых условий, которые могут получить преимущества от индексов:¶
* =#EmailAddress = 'vasya.pupkin@mail.ru'#= !!написал равно вместо LIKE так как сам удивился результатам EXPLAIN'а, нужны дополнителныедополнительные исследования!! - точно определенное значение всегда имеет возможность использовать индекс, сервер пройдется по дереву и получит точное указание на запись или несколько записей в таблице. Сразу нужно отметить, что, определяя колонку уникальной, автоматическийавтоматически создается индекс по ней. Зачем? Иначе было бы накладно перед каждой вставкой или изменением в таблице проверять все значения поля на соответствие условию уникальности, а так можно быстро проверить существование записи. ¶
* =#EmailAddress LIKE 'vacya.pupkin@%'#= - частичное использование индекса. Повторю, что должна быть опредленнаопределена крайняя левая часть и только она может быть использована для поиска по индексам. Например, для условия =#EmailAddress LIKE 'vasya.%@mail.ru'#= тоже будет использован индекс, но в поиске в структуре индекса будет участвовать только =#vasya.#=, а остальная часть будет проверена последовательным сканированием строк, найденыхнайденных с помощью индекса. К этому примеру мы вернемся при рассмотрении особенностей составных индексов.¶

Те же условия распространяются на операции с числами: равенство, больше, меньше и другие. Нетрудно догадаться, что некоторые условия можно привести к альтернативным выражениям с использованием элементарных операций, например, BETWEEN, который тоже оптимизируется.¶


Примеры: http://xpoint.ru/forums/computers/dbms/mysql/thread/23524.xhtml, http://xpoint.ru/forums/computers/dbms/mysql/thread/30686.xhtml¶

В итоге выигрывают индексы, которые более уникальны и, соответственно, используя индекс в таблице, придется просматривать меньше строк. ~MySQL использует два параметра при приеме решений. Cardinality -- свойство индекса, которое высчитывается, исходя из уникальности значений индексируемых данных. Используя cardinality при построении плана, высчитывается предполагаемое количество строк, выбраныхвыбранных с помощью индекса. Обе оценки приближённыеприближенные и иногда могут быть далеки от реальности.¶

Рассмотрим это на примере с полем Disabled. Оказалось, что в таблице нет деактивированых записей:¶


Возвращаясь к примеру с адресами электронной почты, можно рассмотреть ситуацию, когда название домена не менее важно для работы системы. В таких ситуациях можно предположить следующую схему: адрес разбивается по двум полям имя и домен, и создается простой индекс по домену и составной по имени и домену. Составной индекс может быть использован сервером для поиска по полному адресу, а отдельный индекс по домену при поисках (группировках) пользователей по этому полю.¶

Основное преимущество составного индекса -- это увеличение его уникальности, что повышает эффективность его использования, но не стоит забывать про увеличиниеувеличение объема индекса и снижение универсальности.¶

== Выборки из нескольких таблиц¶

Вы, возможно, заметили, что на одну таблицу при выборе может быть использован только один индекс. Это связано с тем, что после получения временных результатов по одному индексу данные остальных индексов становятся бесполезны, так как актуальны только для всей таблицы. Другие СУБД могут использовать более одного индекса. Например, чтобы выбрать людей по городу и фамилии, можно отдельно выбрать по индексу города и отдельно по индексу фамилии, а потом найти пересечение записей двух множеств, но в случае MySQL такое невозможно и поэтому на передний план выходят [[#СоставныеИндексы]]. Это же правило распространяется и на запросы из нескольких таблиц, а именно одно объединение - один индекс. Тут нужно понять, что mysql изначально пустое множество поледовательно дополняет результатами из таблиц, фильтруя их "константными критериями" поиска и критериями объединения таблиц, получив первый набор только по "константным критериям" сервер для каждой полученойполученной записи ищет соответствие в следующей таблице по условию объединения и критериям поиска для нее. Поясню на примере(версия mysql 4.1):¶

<<<¶

История предыдущих изменений

изменения дата автор
текст 2009-03-25 12:26:32 (8 лет назад) Антон Клесс[досье]
текст 2007-06-18 12:46:58 (10 лет назад) Закиров Руслан[досье]
текст 2006-09-07 21:24:03 (11 лет назад) Закиров Руслан[досье]
текст 2006-09-07 20:58:13 (11 лет назад) Закиров Руслан[досье]
текст 2006-05-31 13:25:31 (11 лет назад) Старынин Валерий[досье]
текст 2006-05-30 11:47:09 (11 лет назад) Владимир Палант[досье]
текст 2006-05-30 02:50:00 (11 лет назад) Закиров Руслан[досье]
текст 2006-03-07 05:43:04 (11 лет назад) Закиров Руслан[досье]
текст 2005-12-15 10:14:06 (11 лет назад) Закиров Руслан[досье]
текст 2005-12-15 05:12:43 (11 лет назад) Закиров Руслан[досье]
текст 2005-12-14 16:17:03 (11 лет назад) Сергей Круглов[досье]
текст 2005-12-14 09:38:31 (11 лет назад) Дмитрий Кучкин[досье]
текст 2005-12-14 02:03:15 (11 лет назад) Закиров Руслан[досье]
текст 2005-12-12 01:50:43 (11 лет назад) Сергей Круглов[досье]
текст 2005-12-10 14:55:51 (11 лет назад) Владимир Палант[досье]
текст 2005-12-09 23:03:17 (11 лет назад) Закиров Руслан[досье]
текст 2005-12-08 19:08:08 (11 лет назад) Закиров Руслан[досье]
текст 2005-11-06 00:39:35 (11 лет назад) Владимир Палант[досье]
текст 2005-10-21 06:06:26 (11 лет назад) Закиров Руслан[досье]
текст 2005-10-20 04:43:44 (11 лет назад) Закиров Руслан[досье]
текст 2005-10-19 16:37:08 (11 лет назад) Александр Галкин[досье]
текст 2005-10-19 13:24:18 (11 лет назад) Андрей Новиков[досье]
текст, заголовок 2005-10-19 10:14:16 (11 лет назад) Закиров Руслан[досье]
RSS
Powered by POEM™ Engine Copyright © 2002-2005