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

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

Вы можете ограничить количество одновременных потоков, установив параметр конфигурации innodb_thread_concurrency. После того, как количество выполняющихся потоков достигнет этого предела, дополнительные потоки засыпают на количество микросекунд, заданное параметром конфигурации innodb_thread_sleep_delay, перед тем, как попасть в очередь.

Вы можете установить параметр конфигурации innodb_adaptive_max_sleep_delay до наибольшего значения, которое вы допустите для innodb_thread_sleep_delay, и InnoDB автоматически корректирует innodb_thread_sleep_delay вверх или вниз в зависимости от текущей активности планирования потоков. Эта динамическая корректировка помогает механизму планирования потоков работать плавно во время работы системы с низкой нагрузкой и при работе вблизи полной загрузки.

Значение по умолчанию для innodb_thread_concurrency и подразумеваемый предел количества одновременных потоков были изменены в различных выпусках MySQL и InnoDB. Значение по умолчанию для innodb_thread_concurrency составляет 0, так что по умолчанию нет ограничения на количество одновременно выполняющихся потоков.

InnoDB заставляет потоки засыпать только тогда, когда количество одновременных потоков ограничено. Когда нет ограничения на количество потоков, все конкурируют за планирование. То есть, если innodb_thread_concurrency равно 0, значение innodb_thread_sleep_delay игнорируется.

Когда существует ограничение на количество потоков (когда innodb_thread_concurrency больше 0), InnoDB снижает накладные расходы на контекстную смену, позволяя нескольким запросам, сделанным во время выполнения одного SQL-запроса, входить в InnoDB без соблюдения предела, установленного innodb_thread_concurrency. Поскольку SQL-запрос (например, соединение) может включать несколько операций с записью в InnoDB, InnoDB назначает определённое количество “билетов”, которые позволяют потоку многократно планироваться с минимальными накладными расходами.

Когда начинается новый SQL-запрос, у потока нет билетов, и он должен соблюдать innodb_thread_concurrency. После того, как поток имеет право войти в InnoDB, ему назначается определённое количество билетов, которые он может использовать для последующего входа в InnoDB для выполнения операций с записью. Если билеты заканчиваются, поток удаляется, и innodb_thread_concurrency снова соблюдается, что может поместить поток обратно в очередь ожидания потоков «первым пришёл – первым обслужен». Когда поток снова имеет право войти в InnoDB, билеты снова назначаются. Количество назначаемых билетов задаётся глобальным параметром innodb_concurrency_tickets, который по умолчанию равен 5000. Потоку, ожидающему блокировки, выдаётся один билет после освобождения блокировки.

Правильные значения этих переменных зависят от вашей среды и рабочей нагрузки. Попробуйте разные значения, чтобы определить, какое значение подходит для ваших приложений. Прежде чем ограничивать количество одновременно выполняющихся потоков, проверьте параметры конфигурации, которые могут улучшить производительность InnoDB на многоядерных и многопроцессорных компьютерах, например, innodb_adaptive_hash_index.

Дополнительную информацию о обработке потоков в MySQL см. в разделе 7.1.12.1, «Интерфейсы подключения».