В пакетном файле создается таблица с типом InnoDB и в нее вставляется шесть тысч строк:

Вставка этих срок занимает около 10 минут.
Если делать тоже самое, но у таблицы задать тип MyIsam - то процесс занимает всего секунд пять-шесть...
Если делать через транзакцию (BEGIN/COMMIT) - то и в InnoDB эта процедура занимает мало времени - секунд шесть-семь...
Так и должно быть?
Что можно подкрутить в настройках (кроме autocommit=0), что бы InnoDB без транзакций не тормозили?

Первичного ключа в создаваемой таблице нету.
Установка innodb_buffer_pool_size=180M, innodb_additional_mem_pool_size=45 - тоже не повлияла на результат...
Только вставка BEGIN/COMMIT дает нужную скорость...

Установил четверку - там такая-же картина...
Вот мазафака - приплыли, называется - хочешь транзакции и ключи - в нагрузку тормоза получи !!! Переписывать теперь что-ли - везде втыкать бегин/комит - запара...

2 Stellar.
Тормоза пропрадают, кады ставишь BEGIN/COMMIT.
Просто - для меня это дополнительный гемор - все модули, где идет вставка кучи строк - обрамлять BEGIN/COMMIT. Блин - надо было сразу вставлять - ведь мускуль совершенно спокойно проглатывает эту конструкцию даже на таблах, которые не поддерживают данные операции!!!
Если-б раньше это сделал - то мог бы совершенно спокойно счаз поменять тип таблиц... А насчет скорости - я и счаз скажу - муся быстра, как никто другой!
Воткну бегин/комит - и получу нужный результат. Причем - часть таблиц я могу совершенно спокойно оставить MyIsam - мускулю не обязательно, что бы в БД таблицы были одного типа - это тоже удобно!
По поводу постгря - есть некоторые моменты - во первых - настораживает то, что по дефолту - количество устанавливаемых одновременных подключений у него какое-то маленькое - ресурсы он что-ли жрет, или разработчики в угоду тем, у кого машинки слабые так сделали? Во вторых - с кодировками траблы - виндовая кодировка у него как-то не правильно работает - счаз точно не помню - вроде - большие и малые буквы у него не правильно сортируются, толи какую-то одну букву клинит - в обчем - где-то был облом (а может - руки.sys). Ну и в добавок - под винды - нормальной версии нет, то что есть - какой-то нестабилеж - для изучения и девелопинга - она есчо годиться, но держать рабочую базу на ней мне страшно.

Что-же все-таки с настройками?
Снова сделал тест. Заполняется таблица с 6266 строками.
Без транзакций:
начало - 11:50:33, окончание - 11:59:33, в секунду - 700 записей вставляет.
С транзакциями:
начало - 12:17:14, окончание - 12:17:17, в секунду - вставил все...
Почему такая большая разница?
Машина - PIII-800x512RAM, Win-NT4
MySQL - 4.0.18
Вот настройки:
====================================
skip-locking
skip-name-resolve
skip-grant-tables
skip-bdb

set-variable = key_buffer=256M
set-variable = max_allowed_packet=1M
set-variable = table_cache=256
set-variable = sort_buffer=1M
set-variable = record_buffer=1M
set-variable = myisam_sort_buffer_size=64M
set-variable = thread_cache=8
# Try number of CPU's*2 for thread_concurrency
set-variable = thread_concurrency=8

server-id = 1

log

set-variable = innodb_mirrored_log_groups=1
set-variable = innodb_log_files_in_group=3
set-variable = innodb_log_file_size=5M
set-variable = innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
innodb_log_archive=0
set-variable = innodb_buffer_pool_size=180M
set-variable = innodb_additional_mem_pool_size=40M
set-variable = innodb_file_io_threads=4
set-variable = innodb_lock_wait_timeout=50
======================================

Xpeн ! Поделись мыслями - что у меня не так? Какие у тебя настройки, что всего в шесть раз медленнее получается... Или - у тебя мускуль на юниксах?

То есть по нажатию любимой кнопки Reset можем остаться без результатов успешно законченных транзакций?
Во первых - при нажатии кнопки Reset данные можно потерять не только в хранилище innoDB - но абсолютно в любой другой системе.
Во вторых - если innodb_flush_log_at_trx_commit = 0 - то "InnoDB only writes to the log file and flushes it to disk approximately once per second, or when the log buffer becomes full..." Думаю - что один раз в секунду - вполне секурно, тем более - что УПС стоит...

но не кажется ли вам что пора переходить на что-нибудь более продвинутое
Нет, пока не кажется... База данных не очень велика, возможностей Мускуля пока более чем достаточно.

Вот мы опять вернулись к моему постоу про скорость....

Да нормально все со скоростью - я же писал, что с begin/commit все прекрасно !!!


Быть может, все же, поставить Постгрес...

Да уже давно стоит - тока под фрей... С Виндовой кодировкой проблемы...

Big thanks to Хрен !!!
Выставил следующие опции:
innodb_flush_log_at_trx_commit=0
set-variable = innodb_file_io_threads=9

ЗАЛЕТАЛО !!! Что с транзакциями, что без - все быстро !!!
Понятно - sync после каждой вставки - вот где тормоза были ! А база-то лежит на зеркалючем рейде - и запись на винты более медленна...

если в логе транзакций есть записи, то по ним восстановятся данные. если записей в логе нету --- привет. я достаточно доходчиво?

Сброс на винт делается раз в секунду. Раз в секунду!!! Я достаточно доходчиво написал? Если нажать резет в момент записи лога - то на любой БД будет облом, и откат произойдет на предыдущую завершенную транзакцию.
Я к тому, что innodb_flush_log_at_trx_commit=0 не отключает лог, а только уменьшает интревал времени флушинга. Ничего страшного в этом нету - ведь никто не отключает кэширование винтов из-за гипотетической возможности потери информации при отказе питания?

А давайте протестим и сравним !!!
Сбацаем какую-нить табличку, забъем в нее лимона два строк - и сделаем выборку. В Мускул, Постгрее и есчо где-нить...

Да после пары таких запросов на mysql вы меморию побежите покупать

Не надо ставить заведомо невыполнимых условий. Мускуль вроде не поддерживает вложенных запросов. Интересно, что ты побежишь покупать, что бы сделать выборку с регэкспами или ORDER BY RAND

Так ведь давайте же судить объективно: сложная выборка из кучи связанных таблиц встречается гораздо чаще чем использование регулярных выражений
А ты не допускаешь мысли, что у кого-то может быть обратная ситуация - сложных выборок нету, а с регулярными выражениями - дофига?

Я по-русски немного плохо понимаю, не мог бы ты перефразировать

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

To Хрен
Большое спасибо !!! Как хорошо, что хоть один человек дает конкретные ответы, а не заводит гнилой базар про отстойность MySQL и крутизну других СУБД-ов... Наверно - пора это форум переименовать во что-нибудь типа "Тормоз MySQL" или "Снеси к чертям MySQL" - ибо большинство тутошних ответов более подходят под такую тематику...

skip-grant-tables - это временно, что бы не заморачиваться с паролями...
лучше log-bin - делает то-же самое (только в бинарном формате)
Я почему ставлю log - просто потому, что в логе видно запросы - их при надобности (кады там какая-то ошибка возникает) можно через фар выковырнуть и через копи/пасте впердолить во фронт и там проверить, почему запрос не отрабатывает - фронт в консолке дает понятный ответ сервера.
А чем смотреть этот лог-бин?
По поводу остальных настроек - я просто взял их из сэмпла my-medium.cnf - думал они типа для машин средней мощности...

выделить определенную память под query_cache_size (скажем хотя бы мегабайт 20..30)

Наверно - этого делать не стоит - слишком разнородные запросы в моей базе - хинтов наверно не будет...

To Рыжий Кот
Мне непонятно ваше снисходительно-поучительское отношение к собеседникам - почему вы считаете, что если человек использует MySQL - то он обязательно в танке или фанатик? Или - вам хорошо изветен круг задач, которые я решаю с помощью Мускл? А веб-ориентированные проекты - это что - моветон?