Индексация базы

← →
blazerad (2008-06-30 22:35) [0]

Вопрос, что такое индексация базы и зачем она нужна. И как создать индексацию и нужна ли она вообще?

← →
Ega23 © (2008-06-30 22:50) [1]

Забей.

← →
tesseract © (2008-06-30 22:56) [2]

Математика, зачем она нужна ? И вообще зачем учиться, если всё можно в гугле найти ?

← →
MsGuns © (2008-06-30 23:34) [3]

У индексов одно единственное назначение - повышение скорости выборок. Однако при неправильном их использовании можно получить эффект наоборот. Например, если есть таблица, состоящая из одного ключа и 10 длинных символьных полей, то создание индексов хотя бы по половине полей может не ускорить, а существенно замедлить выборку.

← →
Игорь Шевченко © (2008-06-30 23:36) [4]

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

пример в студию, когда замедляется именно выборка из-за наличия индексов.

← →
MsGuns © (2008-06-30 23:38) [5]

Вот делать мне нефих, как тебе примеры приводить. Возьми сам в том же аксесе нарисуй табличку, залей в нее тыс.50 записей и повыбирай

← →
Игорь Шевченко © (2008-06-30 23:40) [6]

> Вот делать мне нефих, как тебе примеры приводить

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

← →
MsGuns © (2008-06-30 23:42) [7]

На здоровье

← →
sniknik © (2008-07-01 00:20) [8]

> пример в студию, когда замедляется именно выборка из-за наличия индексов.
вообщето, по классике замедляется скорость вставки изза индексов (исключение кластерный, да и то не всегда) но если хотите пример замедления выборки, пожалуйста -
аксесс, таблица с 22 полями (неважно, просто под руку такая попалась), общее количество записей 327680
индексов нет, выборка
SELECT * FROM Table1 WHERE IndexField=1
результат 327680 записей за 3,094 сек.
делаем индекс
CREATE INDEX IndexField ON Table1 (IndexField)
повторяем запрос
SELECT * FROM Table1 WHERE IndexField=1
результат 327680 записей за 6,532 сек.

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

> и нужна ли она вообще?
"вообще" вопрос бессмысленен (как и любой другой "глобальный" вопрос), смысл есть только в частностях, конкретике, для чего предполагается использовать, с какими данными в каких случаях... более точный ответ, на "нужна ли" для конкретного случая, можно например узнать из плану реального запроса на реальных данных, с индексом/-ами и без. (или просто время сравнить, если данных много и время заметно различается)

← →
Игорь Шевченко © (2008-07-01 00:43) [9]

> догадаться почему нетрудно конечно (все данные перед глазами,
> слепой только не увидит), но это факт, выборка по индексу
> медленнее "прямой", и выигрывают индексы не изза ускорения
> выборки по ним, а изза более быстрого отбора нужного...
> есть разница.

Это только Access является таким счастливым исключением ?

← →
Petr V. Abramov © (2008-07-01 01:26) [10]

> и зачем она нужна.

нужна, чтоб база быстрей работала. Если у тебя не тормозит, но нифих не нужна, т.к. место жрет на диске

← →
Petr V. Abramov © (2008-07-01 01:29) [11]

> sniknik © (01.07.08 00:20) [8]

вопрос не к
WHERE IndexField=1
а к оптимизатору и sql`еписателю

← →
Тимохов (2008-07-01 01:46) [12]

Не читая пред. авторов скажу словами, которыми я обычно пытаюсь объяснить кому-то силу алгоритмов.

Вот представь, автор, что у тебя есть список из 8 элементов. Допустим ты ничего не знаешь про эти элементы. Тебе нужно найти элемент А. Что ты будешь делать? Видимо перебирать 8 элементов в поисках желаемого. Так? Итого в среднем ты потратишь 4 стравнения для поиска желаемого (т.е. 8 / 2 = 4).

Другой случай. Ты предварительно изучил состав 8 этих элеменов и принял решение о том, что у этих восьми элементов есть что-то, что в народе называется порядком. В итоге ты потратил свое драгоценное время на то, чтобы разложить эти 8 элементов в определенном порядке.

И вот приходит к тебе злой запрос. Найди, нафиг, мне элемент А! Шо делать? Может опять перебирать все 8 элементов и потратить те же 4 в среднем шагов на поиск? Ну уж нет.

Делаем так!
1. Берем у искомого А есть метрику.
2. Берем у диапазона тех самых восьми элементов минимум и максимум их метрик.
3. Берем среднее между минимумом и максимумом из метрик из п. 2.
4. Сравниваем п. 1 и п. 3. Если п. 1 больше п. 3, то ничинаем искать уже среди 5..8 элементов.

Если хорошо подумать (я надеюсь, что это допустимо предполагать в данном случае),то можно понять, что элемент будет найден за 3 сравнения. Что есть явно меньше, нежели 4 при тотальном сравнении.

Вот теперь предположите, что элементов не 8, а 1024. В итоге вы получите,что найти элеменент можно за 10 сравнений, нежели за 512.

А если элементов 2^2323232323. Какова будет разница?

Решение в студию!

ЗЫ. Если рассмотреть педагогический эффект моего поста, то его можно охарактеризовать так: ничего не бывате задарма, но бывате, что накладные расходы покрывают убытки. Надо только думать...

← →
McSimm © (2008-07-01 01:50) [13]

> создание индексов хотя бы по половине полей может не ускорить,
> а существенно замедлить выборку.

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

> когда замедляется именно выборка из-за наличия индексов.

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

← →
Тимохов (2008-07-01 01:59) [14]

можно скажу для продвинутых в индексах?

индексы и вообще запросы в КОНКРЕНТОЙ СУБД штука очень тонкая.

Нужно обазательно анализировать планы запросов (ведь эта скотина, СУБД, считает нас всех идиотами и решает что с чем ей сливать сама).

Нужно очень внимательно относиться к связаке БИЗНЕ-ЛОГИКА х ИНДЕКСЫ.

Вот история оптимизации (здесь без знания предметки никуда):
1. У нас в БД есть детайл таблица с элементами: ТИП, НОМЕР, ДАТА.
2. Частно нужно эти три признака вытигавать.
3. БД - MSSQL.
4. Вот поставь себя на место СУБД - есть 2 таблицы: Мастер-таблица, и детаил таблица. Причем на ТИП, НОМЕР и ДАТА могут быть условия. Вот хрен поймешь как сливать данные!
5. И вот я вижу, что эта ... хорошая СУБД... сливать начинает с ДАТЫ!!! Блин ну дней всего в году 365, а документов 7017409147 (не меньше!).
6. А вот типов документов всего 234.
7. И тут я (Тимохов Д.) меня запрос так, чтобы эта ... хорошая СУБД... сначала отсексла нужный мне набор документов по типу, а ужо потом колупалась среди них в их номерах и датаж.

В итоге оптимизация 30 процентов. А если еще покопаться? Можно и еще нарыть...

> 7. И тут я (Тимохов Д.)
> нужный мне набор документов по типу,
> 6. А вот типов документов всего 234.

наифиговейший запрос, на любой СУБД
> В итоге оптимизация 30 процентов.
либо документов мало, либо кластер-фактор (документы одного типа инсертиттся подряд)

> Тимохов (01.07.08 01:59) [14]

с другой стороны, если документов до лимона - сработает :)

> 7017409147
> Тимохов
соврал или цифра лишняя где-то :)

> Это только Access является таким счастливым исключением ?
просто оптимизатор аксесса легче всего "обмануть" потому и проверки на нем более "чистые" когда он не вмешивается, а "физика процессов" везде одинаковая -> добавили лишнее действие = добавили времени исполнения.

другие еще надо проверить, возможно будет то же самое. кому интересно может заняться.

> Игорь Шевченко (01.07.2008 0:43:09) [9]

Это относится к любым базам, но нужны определенные условия, не всегда эксперимент повторяется.

С индексами было ещё что-то, где плюнули на стол.

Индексация базы Найти похожие ветки