Если я могу сказать одну вещь о MySQL, так это то, что InnoDB, его транзакционный (ACID-совместимый) механизм хранения, действительно многопоточный. Тем не менее, он такой же многопоточный, как и вы! Даже прямо "из коробки" InnoDB отлично работает в среде с одним процессором, учитывая его настройки по умолчанию. Чтобы воспользоваться возможностями многопоточности InnoDB, вы должны не забыть активировать множество опций.
innodb_thread_concurrency устанавливает верхнюю границу количества параллельных потоков, которые InnoDB может держать открытыми. Лучшее число раундов для этого - (2 X Количество процессоров) + Количество дисков. ОБНОВЛЕНИЕ : Как я узнал из первых рук на конференции Percona NYC Conference, вы должны установить это значение в 0, чтобы предупредить InnoDB Storage Engine, чтобы найти лучшее число потоков для среды, в которой он работает.
innodb_concurrency_tickets устанавливает количество потоков, которые могут безнаказанно обходить проверку параллелизма. После того, как этот предел достигнут, проверка параллельности потока снова становится нормой.
innodb_commit_concurrency устанавливает количество одновременных транзакций, которые могут быть зафиксированы. Поскольку значение по умолчанию равно 0, не устанавливая его, можно одновременно фиксировать любое количество транзакций.
innodb_thread_sleep_delay устанавливает количество миллисекунд, в течение которых поток InnoDB может бездействовать до повторного входа в очередь InnoDB. По умолчанию 10000 (10 секунд).
innodb_read_io_threads и innodb_write_io_threads (оба начиная с MySQL 5.1.38) выделяют указанное количество потоков для чтения и записи. По умолчанию 4 и максимум 64.
innodb_replication_delay налагает задержку потока на ведомое устройство, когда достигнута innodb_thread_concurrency.
innodb_read_ahead_threshold разрешает линейное чтение заданного количества экстентов (64 страницы [страница = 16K]) перед переключением на асинхронное чтение.
Время ускользнет от меня, если я назову больше вариантов. Вы можете прочитать о них в документации MySQL .
Большинство людей не знают об этих функциях и вполне удовлетворены тем, что InnoDB просто выполняет ACID-совместимые транзакции. Если вы настраиваете любой из этих вариантов, вы делаете это на свой страх и риск.
Я играл с несколькими экземплярами пула буферов MySQL 5.5 (162 ГБ в 9 экземплярах буферных пулов) и пытался таким образом автоматически разбивать данные в памяти. Некоторые эксперты говорят, что это должно дать вам повышение производительности на 50%. То, что я получил, было тонной блокировкой потоков, которая фактически заставила InnoDB сканировать. Я переключился на 1 буфер (162 ГБ), и все снова стало хорошо в мире. Я думаю, вам нужны эксперты Percona, чтобы установить это. Я буду завтра на конференции Percona MySQL в Нью-Йорке и спрошу об этом, если представится возможность.
В заключение, InnoDB теперь хорошо работает на многопроцессорном сервере, учитывая его настройки по умолчанию для многопоточных операций. Для их настройки требуется большая осторожность, терпение, отличная документация и отличный кофе (или Red Bull, Jolt и т. Д.).
Доброе утро, добрый вечер и спокойной ночи !!!
ОБНОВЛЕНИЕ 2011-05-27 20:11
Вернулся с конференции Percona MySQL в Нью-Йорке в четверг. Что за конференция. Многому научился, но получил ответ, который я рассмотрю в отношении InnoDB. Рональд Брэдфорд сообщил мне, что установка innodb_thread_concurrency в 0 позволит InnoDB самостоятельно определить наилучший вариант действий с параллелизмом потоков. Я буду экспериментировать с этим дальше в MySQL 5.5.
ОБНОВЛЕНИЕ 2011-06-01 11:20
Что касается одного длинного запроса, InnoDB совместим с ACID и работает очень хорошо, используя MultiVersion Concurrency Control . Транзакции должны быть в состоянии нести уровни изоляции (по умолчанию повторяемые операции чтения), что предотвращает доступ других пользователей к данным.
Что касается многоядерных систем, InnoDB прошел большой путь. В прошлом InnoDB не мог хорошо работать в многоядерной среде. Я помню, что мне приходилось запускать несколько экземпляров mysql на одном сервере, чтобы заставить несколько ядер распределять несколько процессов mysqld по центральным процессорам. Это больше не нужно, благодаря Percona, а затем и MySQL (например, Oracle, который по-прежнему заставляет меня затыкать рот), поскольку они превратили InnoDB в более зрелый механизм хранения, который может легко получать доступ к ядрам без особой настройки. Текущий экземпляр InnoDB сегодня может хорошо работать в одноядерном сервере.