参考官方文档：

https://dev.mysql.com/doc/refman/5.7/en/innodb-performance-thread_concurrency.html

InnoDB使用操作系统线程来处理来自用户事务的请求。 （事务在提交或回滚之前可能会向InnoDB发出很多请求。）在具有多核处理器的现代操作系统和服务器上，在上下文切换有效的情况下，大多数工作负载运行良好，对并发线程数没有任何限制。 MySQL 5.5及以上版本的可伸缩性改进降低了对InnoDB内部并发执行线程数量的限制。

在减少线程上下文切换的场景中，InnoDB可以使用许多技术来限制并发执行的操作系统线程的数量（以及任何时候处理的请求的数量）。 当InnoDB收到来自用户会话的新请求时，如果并发执行的线程数量处于预定义的限制，则新请求会在短时间内休眠，然后再次尝试。 睡眠之后无法重新安排的请求被放入先入先出队列中并最终被处理。 等待锁的线程不计入并发执行线程的数量。

您可以通过设置配置参数innodb_thread_concurrency来限制并发线程的数量。 一旦执行线程的数量达到此限制，其他线程在放入队列之前会休眠几微秒，由配置参数innodb_thread_sleep_delay设置。

之前，它需要进行实验才能找到innodb_thread_sleep_delay的最佳值，并且最佳值可能会根据工作负载而改变。 在MySQL 5.6.3及更高版本中，您可以将配置选项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会分配指定数量的“tickets”，以便以最小的开销重复调度线程。

当一个新的SQL语句启动时，一个线程没有tickets，并且它必须遵守innodb_thread_concurrency。 一旦线程被授权进入InnoDB，它将被分配一些tickets，它可以用来随后输入InnoDB来执行行操作。 如果tickets用完，线程被驱逐，并且再次观察到innodb_thread_concurrency，这可能会将线程放回到等待线程的先入先出队列中。 当线程再次被授权进入InnoDB时，tickets再次分配。 分配的tickets数量由全局选项innodb_concurrency_tickets指定，缺省值为5000。 一旦锁定可用，正在等待锁定的线程将被授予一ticket。

这些变量的正确值取决于您的环境和工作负载。 尝试一系列不同的值来确定适用于您的应用程序的值。 在限制并发执行线程的数量之前，请查看可以提高多核和多处理器计算机上的InnoDB性能的配置选项，例如innodb_adaptive_hash_index。

14.6.7 配置 后台InnoDB I/O线程的数量

InnoDB使用后台线程来处理各种类型的I / O请求。 您可以使用innodb_read_io_threads和innodb_write_io_threads配置参数来配置服务在数据页上读写I / O的后台线程数。 这些参数分别表示用于读取和写入请求的后台线程的数量。 它们在所有支持的平台上都很有效。 您可以在MySQL选项文件（my.cnf或my.ini）中设置这些参数的值; 你不能动态改变数值。 这些参数的默认值是4，允许值范围是1-64。

这些配置选项的目的是使InnoDB在高端系统上更具可扩展性。 每个后台线程最多可处理256个待处理的I / O请求。 后台I / O的主要来源是预读请求。 InnoDB试图通过大多数后台线程平均共享工作的方式来平衡传入请求的负载。 InnoDB也会尝试将同一范围内的读请求分配给同一个线程，以增加合并请求的机会。 如果您有高端I / O子系统，并且您在SHOW ENGINE INNODB STATUS输出中看到多于64×innodb_read_io_threads未决读取请求，则可以通过增加innodb_read_io_threads的值来提高性能。

在Linux系统上，InnoDB默认使用异步I / O子系统来执行数据文件页面的预读和写请求，这改变了InnoDB后台线程处理这些类型的I / O请求的方式。

14.6.8 在 Linux 上使用异步 I/O

InnoDB使用Linux上的异步I / O子系统（本地AIO）来执行数据文件页的预读和写请求。 此行为由innodb_use_native_aio配置选项控制，该选项仅适用于Linux系统，默认情况下处于启用状态。 在其他类Unix系统上，InnoDB只使用同步I / O。 历史上，InnoDB只在Windows系统上使用异步I / O。 在Linux上使用异步I / O子系统需要libaio库。

使用同步I / O，查询线程对I / O请求进行排队，InnoDB后台线程一次检索一个排队的请求，为每个请求发出同步I / O请求。 当I / O请求完成并且I / O调用返回时，处理请求的InnoDB后台线程调用I / O完成例程并返回以处理下一个请求。 可以并行处理的请求数为n，其中n是InnoDB后台线程的数量。 InnoDB后台线程的数量由innodb_read_io_threads和innodb_write_io_threads控制。

使用AIO，查询线程直接将I/O请求分派给操作系统，从而消除后台线程数量所带来的限制。 InnoDB后台线程等待I/O事件发出已完成请求的信号。 当请求完成时，后台线程调用I/O完成例程并继续等待I/O事件。

AIO的优势在于I/O受限的系统的可扩展性，这些系统通常在SHOW ENGINE INNODB STATUS\ G输出中显示许多未决的读/写操作。 使用AIO时并行处理的增加意味着I/O调度程序的类型或磁盘阵列控制器的属性对I/O性能有更大的影响。

AIO对于I/O密集型系统的潜在缺点是缺乏对同时分派给操作系统的I/O写入请求数量的控制。 根据I/O活动的数量和系统性能的不同，调度到操作系统进行并行处理的太多I/O写请求可能会导致I/O读取不足。

如果操作系统中异步I/O子系统的问题阻止了InnoDB的启动，则可以使用innodb_use_native_aio = 0启动服务器。 如果InnoDB检测到tmpdir位置，tmpfs文件系统和不支持tmpfs上的异步I/O的Linux内核的组合，则此选项可能会在启动期间自动禁用。

14.6.9 配置InnoDB Master 线程I/O 比率

InnoDB中的主线程是一个在后台执行各种任务的线程。 这些任务中的大多数都与I/O相关，例如从缓冲池中清除脏页或将插入缓冲区中的更改写入适当的二级索引。 主线程尝试以不会对服务器的正常工作产生不利影响的方式执行这些任务。 它试图估计可用的空闲I/O带宽，并调整其活动以利用此空闲容量。 历史上，InnoDB使用了100 IOP（每秒输入/输出操作）的硬编码值作为服务器的总I / O容量。

参数innodb_io_capacity表示InnoDB可用的整体I / O容量。 此参数设置为大约系统每秒可执行的I / O操作的数量。 该值取决于您的系统配置。 当设置innodb_io_capacity时，主线程根据设置值估计可用于后台任务的I / O带宽。 将该值设置为100会恢复到旧的行为。

您可以将innodb_io_capacity的值设置为任何数字100或更大。 默认值是200，反映了典型的现代I / O设备的性能比MySQL早期的高。 通常，以前的默认值100左右的值适用于消费级存储设备，例如高达7200 RPM的硬盘驱动器。 更快的硬盘驱动器，RAID配置和固态硬盘从更高的价值中受益。

--innodb_io_capacity 可以配置到一个经过测试的实际的值

innodb_io_capacity设置是所有缓冲池实例的总限制。 当刷新脏页时，innodb_io_capacity限制会在缓冲池实例中平均分配。

您可以在MySQL选项文件（my.cnf或my.ini）中设置此参数的值，或者使用需要SUPER特权的SET GLOBAL命令动态更改它。

innodb_flush_sync配置选项会导致innodb_io_capacity设置在检查点发生的I / O活动爆发期间被忽略。 innodb_flush_sync默认启用。

以前，InnoDB主线程还执行任何所需的清除操作。 在MySQL 5.6.5及更高版本中，这些I / O操作被移动到其他后台线程，后台线程的数量由innodb_purge_threads配置选项控制。

14.6.10 配置 Spin 锁轮询

很多InnoDB mutexes和rw-locks都是短时间保留的。 在多核系统上，线程可以更有效地检查睡眠前是否可以获取互斥锁或rw锁。 如果在此轮询期间mutexes 或rw-locks可用，则线程可以在同一时间片内立即继续。 然而，由多个共享对象线程轮询太频繁会导致“缓存乒乓”，不同的处理器会使每个其他缓存的部分无效。 InnoDB通过在随后的轮询之间等待随机时间来最小化这个问题。 延迟被实现为繁忙循环。

您可以使用参数innodb_spin_wait_delay来控制测试mutexes 或rw-lock之间的最大延迟时间。 延迟循环的持续时间取决于C编译器和目标处理器。 （在100MHz奔腾时代，延迟单位为1微秒）。在所有处理器内核共享高速缓存内存的系统上，可以通过设置innodb_spin_wait_delay = 0来减少最大延迟或完全禁用繁忙的loop。 在具有多个处理器芯片的系统上，高速缓存失效的影响可能更为显着，您可能会增加最大延迟。

nnodb_spin_wait_delay的默认值为6.spin 等待延迟是一个动态全局参数，您可以在MySQL选项文件（my.cnf或my.ini）中指定该参数，或者在运行时使用SET GLOBAL innodb_spin_wait_delay = delay命令进行更改，其中 delay是所需的最大延迟。 更改设置需要SUPER权限。

14.6.11 配置InnoDB 清理调度

InnoDB自动执行的清除操作（一种垃圾收集）可以由一个或多个单独的线程执行，而不是作为主线程的一部分。 通过允许主数据库操作独立于后台发生的维护工作来运行，使用单独的线程可以提高可伸缩性。

要控制此功能，请增加配置选项innodb_purge_threads的值。 如果DML操作集中在单个表或几个表上，请将设置保持为低，以便线程不会彼此争用以访问繁忙表。 如果DML操作分散在多个表中，请增加设置。 它的最大值是32. innodb_purge_threads是一个非动态配置选项，这意味着它不能在运行时配置。

还有另一个相关配置选项，innodb_purge_batch_size，默认值为300，最大值为5000.此选项主要用于试验和调整清除操作，对典型用户应该不感兴趣