ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Constantin Stefanov                  2:5020/400     04 Dec 2006  15:26:50
 To : Eugene Grosbein
 Subject : Re: awk vs sql: предварительные результаты
 -------------------------------------------------------------------------------- 
 

 Eugene Grosbein wrote:
 
 >  EG>> Возвращаясь к нашим баранам - а как поступает MySQL, когда индекс
 >  EG>> не помещается в памяти? И как у него регулируется понятие
 >  EG>> "помещается"?
 >  AC> Как в mysql не знаю, но вообще для индексов обычно используется
 >  AC> b-tree, и вопросами типа влезет или не влезет никто не задается.
 
 > В каком смысле "никто не задается"? Индекс читается в своп
 > и сервер по нему шарашится потом?
 
 Hесколько не так. Сразу не предполагается, что индекс влезет в память.
 Поэтому вся работа изначально строится на том, что он не поместится, и
 его там не хранят. Тот же PostgreSQL, например, при построении плана
 запроса явно вычисляет, сколько ему страниц придется поднять с диска при
 поиске по индексу и при полном поиске по таблице, сравнивает и от этого
 уже решает, а имеет ли смысл применять индекс. Для такого вычисления он
 хранит некоторую статистику по распределению данных. Как он при этом
 учитывает, что сейчас лежит в кэше - я не совсем представляю, по крайней
 мере в explain он про это не рассказывает.
 Что в такой ситуации делает MySQL - не знаю.
 
 >  AC> В postgresql есть альтернативный режим для хранения индекса - hash,
 >  AC> но b-tree по умолчанию.
 >  AC> Hичто не мешает и в ЯП реализовывать ассоциативные массивы так же, но
 >  AC> насколько мне известно никто так не делает.
 
 BTree-то может и есть реализованная, но вот btree с хранением на диске -
 это уже кусок СУБД, да и маловероятно, чтобы оно понадобилось без всего
 остального, что есть в СУБД - в смысле, маловероятно, что данные в
 память влезают, а индекс нет.
 
 -- 
 Константин Стефанов
 
 Тридцать семь - температура, тридцать восемь - из мультфильма.
 --- ifmail v.2.15dev5.3
  * Origin: Demos online service (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор