Configuring Spin Lock Polling innodb_io_capacity_max  cannot be set to a value lower than the  innodb_io_capacity  value. Setting  innodb_io_capacity_max  to  DEFAULT  using a  SET  statement ( SET GLOBAL innodb_io_capacity_max=DEFAULT ) sets  innodb_io_capacity_max  to the maximum value. The  innodb_io_capacity_max  limit applies to all buffer pool instances. It is not a per buffer pool instance setting. InnoDB  mutexes and rw-locks are typically reserved for short intervals. On a multi-core system, it can be more efficient for a thread to continuously check if it can acquire a mutex or rw-lock for a period of time before it sleeps. If the mutex or rw-lock becomes available during this period, the thread can continue immediately, in the same time slice. However, too-frequent polling of a shared object such as a mutex or rw-lock by multiple threads can cause “cache ping pong” , which results in processors invalidating portions of each other’s cache.  InnoDB  minimizes this issue by forcing a random delay between polls to desychronize polling activity. The random delay is implemented as a spin-wait loop. The duration of a spin-wait loop is determined by the number of PAUSE instructions that occur in the loop. That number is generated by randomly selecting an integer ranging from 0 up to but not including the  innodb_spin_wait_delay  value, and multiplying that value by 50. (The multiplier value, 50, is hardcoded before MySQL 8.0.16, and configurable thereafter.) For example, an integer is randomly selected from the following range for an  innodb_spin_wait_delay  setting of 6: The selected integer is multiplied by 50, resulting in one of six possible PAUSE instruction values: For that set of values, 250 is the maximum number of PAUSE instructions that can occur in a spin- wait loop. An  innodb_spin_wait_delay  setting of 5 results in a set of five possible values {0,50,100,150,200} , where 200 is the maximum number of PAUSE instructions, and so on. In this way, the  innodb_spin_wait_delay  setting controls the maximum delay between spin lock polls. On a system where all processor cores share a fast cache memory, you might reduce the maximum delay or disable the busy loop altogether by setting  innodb_spin_wait_delay=0 . On a system with multiple processor chips, the effect of cache invalidation can be more significant and you might increase the maximum delay. In the 100MHz Pentium era, an  innodb_spin_wait_delay  unit was calibrated to be equivalent to one microsecond. That time equivalence did not hold, but PAUSE instruction duration remained fairly constant in terms of processor cycles relative to other CPU instructions until the introduction of the Skylake generation of processors, which have a comparatively longer PAUSE instruction. The innodb_spin_wait_pause_multiplier  variable was introduced in MySQL 8.0.16 to provide a way to account for differences in PAUSE instruction duration. The  innodb_spin_wait_pause_multiplier  variable controls the size of PAUSE instruction values. For example, assuming an  innodb_spin_wait_delay  setting of 6, decreasing the innodb_spin_wait_pause_multiplier  value from 50 (the default and previously hardcoded value) to 5 generates a set of smaller PAUSE instruction values: The ability to increase or decrease PAUSE instruction values permits fine tuning  InnoDB  for different processor architectures. Smaller PAUSE instruction values would be appropriate for processor architectures with a comparatively longer PAUSE instruction, for example. 3128 {0,5,10,15,20,25} {0,50,100,150,200,250} {0,1,2,3,4,5} 15.8.8 Configuring Spin Lock Polling