MySQL 8.0 FAQ: InnoDB Change Buffer There are a few rules of thumb to consider for optimal Thread Pool use cases: The MySQL  Threads_running  variable keeps track of the number of concurrent statements currently executing in the MySQL Server. If this variable consistently exceeds a region where the server won’t operate optimally (usually going beyond 40 for InnoDB workloads), the Thread Pool should be beneficial, especially in extreme parallel overload situations. If you are using the  innodb_thread_concurrency  to limit the number of concurrently executing statements, you should find that the Thread Pool solves the same problem, only better, by assigning connections to thread groups, then queuing executions based on transactional content, user defined designations, and so forth. Lastly, if your workload comprises mainly short queries, the Thread Pool should be beneficial. To learn more, see Section 5.6.3.4, “Thread Pool Tuning” . The Thread Pool has a number of user case driven configuration parameters that affect its performance. To learn about these and tips on tuning, see Section 5.6.3.4, “Thread Pool Tuning” . A.15.5. Are there recommended Thread Pool configurations? A.16.1 What types of operations modify secondary indexes and result in change buffering? .............. 5275 A.16.2 What is the benefit of the  InnoDB  change buffer? ............................................................... 5275 A.16.3 Does the change buffer support other types of indexes? ...................................................... 5275 A.16.4 How much space does  InnoDB  use for the change buffer? ................................................. 5275 A.16.5 How do I determine the current size of the change buffer? ................................................... 5276 A.16.6 When does change buffer merging occur? .......................................................................... 5276 A.16.7 When is the change buffer flushed? ................................................................................... 5276 A.16.8 When should the change buffer be used? ........................................................................... 5276 A.16.9 When should the change buffer not be used? ..................................................................... 5277 A.16.10 Where can I find additional information about the change buffer? ........................................ 5277 A.16.1. What types of operations modify secondary indexes and result in change buffering? A.16.2. What is the benefit of the  InnoDB  change buffer? A.16.3. Does the change buffer support other types of indexes? A.16.4. How much space does  InnoDB  use for the change buffer? 5275 Prior to the introduction of the  innodb_change_buffer_max_size  configuration option in MySQL 5.6, the maximum size of the on-disk change buffer in the system tablespace was 1/3 of the InnoDB  buffer pool size. No. The change buffer only supports secondary indexes. Clustered indexes, full-text indexes, and spatial indexes are not supported. Full-text indexes have their own caching mechanism. Buffering secondary index changes when secondary index pages are not in the buffer pool avoids expensive random access I/O operations that would be required to immediately read in affected index pages from disk. Buffered changes can be applied later, in batches, as pages are read into the buffer pool by other read operations. INSERT ,  UPDATE , and  DELETE  operations can modify secondary indexes. If an affected index page is not in the buffer pool, the changes can be buffered in the change buffer. A.16 MySQL 8.0 FAQ: InnoDB Change Buffer