Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Индексы для чайников (MySQL, SQL Server, Access)  [new]
Максим М.
Member

Откуда: Москва
Сообщений: 75
Поработав некоторое время с SQL Server и Access, начал осваивать MySQL и споткнулся буквально на пороге: пытка сделать inner join двух идентичных таблиц по 200 000 записей в каждой, отправляла MySQL в нокаут (результатов ни разу не дождался). Наконец меня осенило сделать им индекс, в точности соответсвующий условиям join'а и дело пошло.
Т.е. получается, что для MySQL желательно создавать специальные индексы для каждого JOIN и WHERE, дабы дать ему инструмент поиска нужных записей отличный от полного перебора?

С другой стороны Access, откуда как раз и приехали в MySQL 2 упомянутые таблицы, справлялся с задачей за 3 секунды, и его, похоже, не напрягало, что условия JOINа не совпадали с основным ключем (join был по части полей основного ключа и нескольким неключевым полям). В SQL Server я тоже никогда не занимался созданием индексов и проблем с производительностью не испытывал (возможно, благодаря мощному серверу на котором он стоит).
Чего такого умеют Access и SQL Server, чего не умеет MySQL? Получается, что первые сами строят всевозможные индексы, а MySQL оставляет это на совести пользователя?
28 май 10, 10:43    [8849873]     Ответить | Цитировать Сообщить модератору
 Re: Индексы для чайников (MySQL, SQL Server, Access)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Максим М.,

например, они могут уметь делать не только loop join, но и hash join и merge join.
28 май 10, 16:36    [8853217]     Ответить | Цитировать Сообщить модератору
 Re: Индексы для чайников (MySQL, SQL Server, Access)  [new]
miksoft
Member

Откуда:
Сообщений: 38921
Еще нужно учитывать, что дефолтовые настройки MySQL подходят далеко не для всех задач. А так же и то, что у MySQL почти отсутствует кэш таблиц MyISAM.
28 май 10, 17:31    [8853611]     Ответить | Цитировать Сообщить модератору
 Re: Индексы для чайников (MySQL, SQL Server, Access)  [new]
Максим М.
Member

Откуда: Москва
Сообщений: 75
locky
Максим М.,
например, они могут уметь делать не только loop join, но и hash join и merge join.


Я имел в виду неочевидные особенности работы с индексами при переходе с Access на MySql.
Сейчас я уже потихоньку привыкаю к тому, что если хочешь ускорить работу joinа - надо сделать ему индекс по соответствующим полям, иначе mysql будет делать декартово произведение с последующим его полным перебором. В этом свете становится совершенно непонятным, как Access справляется с join'ами без явного указания индексов?
29 май 10, 18:04    [8856514]     Ответить | Цитировать Сообщить модератору
 Re: Индексы для чайников (MySQL, SQL Server, Access)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Максим М.
В этом свете становится совершенно непонятным, как Access справляется с join'ами без явного указания индексов?

Например, при помощи merge join, hash join...
Хотя я не уверен, что они в нём есть.
Но, с другой стороны, не вижу причин, почему бы им там не быть.
ну и плюс - другой оптимизатор, что есть тоже немаловажно
29 май 10, 18:07    [8856529]     Ответить | Цитировать Сообщить модератору
 Re: Индексы для чайников (MySQL, SQL Server, Access)  [new]
ЛП
Guest
Максим М.
В этом свете становится совершенно непонятным, как Access справляется с join'ами без явного указания индексов?

Во-первых. То, что нету явно построенных индексов - в случае аксеса вовсе не значит, что индексов нет совсем. Например при построении связи между таблицами (в схеме базы данных) аксес сам создает "вспомогательный" индекс по соответствующим полям.
Во-вторых. Если нет ни явных индексов, ни связей (с неявносозданными индексами), то это всё равно не значит, что индексов нету. Аксес умеет строить временные индексы, если оно выгодно. В файл-серверной архитектуре такое поведение позволительно, т.к. тратятся только ресурсы клиента, остальных пользователей оно не затрагивает.
В-третьих. Какой-никакой, а оптимизатор у аксеса имеется, и для своего класса (класса приложения) - вполне приличный. Если MySQL на каждый чих начинает строить декартово произведение, то это лишь повод удивляться, почему MySQL себя так ведёт, а вовсе не повод удивляться, почему другие ведут себя нормально.
29 май 10, 20:34    [8856850]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить