Форум MySQL

Еще есть проблема настройки, особенно продакшен-серверов (боевых), в MyISAM память выделяется под буфер ключей (много), а в InnoDB память выделяется под буфер табличного пространства (много) и если у вас на сервере не 32Гб оперативной памяти настроить его эффективно под оба типа таблиц не реально. Тип MyISAM очень шустрый, так как ему не только транзакции выполнять не нужно, но и построчную блокировку осуществлять (а это тоже ресурсы и время) - поэтому сервера часто под него настраивают. У MyISAM проблемы начинаются на больших таблицах, так как при операциях на запись блокируется вся таблица целиком... вот тут начинает выигрывать InnoDB с механизмом построчной блокировки, когда несколько потоков могут писать в таблицу одновременно.

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

Полистал ща тырнеты... Вот что пишут:

"Прочитал, что InnoDB, в отличие от MyISAM транзакционный движок и соответственно, если вы по привычке тупо скармливаете ему 1 000 запросов вставки, не заключив их в одну транзакцию, и не отключив дефолтный автокоммит, он проводит 1 000 транзакций, что, безусловно, негативно сказывается на скорости операций, причем значительно.."
http://www.drupal.ru/node/75531

А вот тут http://www.mysql.ru/docs/man/InnoDB_start.html
вообще целая эпопея, с какими параметрами запускать этот движок в производство.

Так что похоже, надо всерьез разбираться с ним. Тем более что, как говорят, MyISAM-а не будет в версии 5.6.

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

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

По поводу тормозов. Судя по логам, которые мне бросает Spring, соединение с БД создается однажды, в начале TestCase, и отдельные тесты не занимаются переподключением. Так что проблема, похоже не в этом.

Думал, может исключения тормозят, но судя по только что проведенным тестам, корректные запросы обрабатываются где-то около 0.1 c, а те, что бросают исключения - раза в полтора дольше. Так что непринципиальная разница.

Сегодня, пока искал ответ на форуме наткнулся на сообщение г-на Симдянова (который cheops, как я понимаю), что де InnoDB работает в разы медленнее MyISAM. У вас вообще есть опыт работы с InnoDB? Не было тормозов?

Я вообще решил на них переключиться, чтобы упростить код. Пока что тормоза не особо напрягают. Но вот как себя поведет БД, когда она пойдет в производство и будет ворочать миллионами записей, это конечно вопрос.

> А как можно проверить наличие индекса?

show index from `child`;

> Я так понимаю, если я создам такой ключ явно, лишним он не будет?
вот этого не понял. куда еще явнее?
Попробуйте выполнить из доков по вашей ссылке:

CREATE TABLE parent (id INT NOT NULL,                      PRIMARY KEY (id) ) ENGINE=INNODB; CREATE TABLE child (id INT, parent_id INT,                     INDEX par_ind (parent_id),                     FOREIGN KEY (parent_id) REFERENCES parent(id)                       ON DELETE CASCADE ) ENGINE=INNODB;

и

CREATE TABLE parent (id INT NOT NULL,                      PRIMARY KEY (id) ) ENGINE=INNODB; CREATE TABLE child (id INT, parent_id INT,                     FOREIGN KEY (parent_id) REFERENCES parent(id)                       ON DELETE CASCADE ) ENGINE=INNODB;

результат будет один и тот же. Хоть во втором случае и не было индекса на поле parent_id - он автоматически был создан.

А вот по поводу затрат целых 0,2 секунд для выбора из таблицы с одной записью - это что-то с чем-то. Вы хотите сказать, что если переключить engine этой таблицы на MyISAM, то выборка будет летать?
Вообще, для ОДНОЙ записи различий между InnoDB и MyISAM не должно быть видно

А как можно проверить наличие индекса?

Полистал вот еще ту же страницу в мануале, http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html. Нашел пример, когда индекс создается отдельно:

CREATE TABLE child (id INT, parent_id INT,                     INDEX par_ind (parent_id),                     FOREIGN KEY (parent_id) REFERENCES parent(id)                       ON DELETE CASCADE ) ENGINE=INNODB;

Я так понимаю, если я создам такой ключ явно, лишним он не будет?

Данную базу решил делать в формате InnoDB, чтобы заставить ее саму следить за целостностью. Прежде, когда был ISAM, за это отвечал код, который проверял наличие внешних ключей и пр. ограничений. И наблюдаю просто катастрофическое падение производительности. Не знаю пока из-за чего, то ли это сама InnoDB такая тормознутая, то ли у меня где косяк. Но вот в JUnit-тестах на каждый запрос (из таблицы с одной записью), как SELECT, так и INSERT уходит по 0,2 сек.

Создал явный индекс эксперимента ради. Но вот пока БД в тестовом режиме, без данных, роста производительности не наблюдаю.

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

Создаю в InnoDb в таблице sites внешний ключ для поля locationId на таблицу locations, на первичный ключ, поле id:

CONSTRAINT FK_locationId FOREIGN KEY (locationId) REFERENCES locations (id) ON DELETE RESTRICT ON UPDATE RESTRICT

Нужно ли создавать индекс для поля sites.locationId? Или он автоматически создастся?

В мануале читаем:
[CONSTRAINT [symbol]] FOREIGN KEY
[index_name] (index_col_name, ...)
...

index_name represents a foreign key ID. If given, this is ignored if an index for the foreign key is defined explicitly. Otherwise, if InnoDB creates an index for the foreign key, it uses index_name for the index name.

Но вот не могу понять, то ли это о моем случае и рекомендуется не задавать индекс явно, то ли здесь что-то другое имеется в виду.