The Rewriter Query Rewrite Plugin Short values are also better for avoiding deadlock situations. Long wait values are useful for workloads that include long-running statements, to avoid starting too many new statements while the current ones execute. Suppose a server executes a workload where 99.9% of the statements complete within 100ms even when the server is loaded, and the remaining statements take between 100ms and 2 hours fairly evenly spread. In this case, it would make sense to set  thread_pool_stall_limit  to 10 (10 × 10ms = 100ms). The default value of 6 (60ms) is suitable for servers that primarily execute very simple statements. The  thread_pool_stall_limit  parameter can be changed at runtime to enable you to strike a balance appropriate for the server work load. Assuming that the  tp_thread_group_stats  table is enabled, you can use the following query to determine the fraction of executed statements that stalled: This number should be as low as possible. To decrease the likelihood of statements stalling, increase the value of  thread_pool_stall_limit . When a statement arrives, what is the maximum time it can be delayed before it actually starts executing? Suppose that the following conditions apply: SELECT SUM(STALLED_QUERIES_EXECUTED) / SUM(QUERIES_EXECUTED) FROM performance_schema.tp_thread_group_stats; In the worst case, the 10 high-priority statements represent 10 transactions that continue executing for a long time. Thus, in the worst case, no statements can be moved to the high-priority queue because it always already contains statements awaiting execution. After 10 seconds, the new statement is eligible to be moved to the high-priority queue. However, before it can be moved, all the statements before it must be moved as well. This could take another 2 seconds because a maximum of 100 statements per second are moved to the high-priority queue. Now when the statement reaches the high-priority queue, there could potentially be many long-running statements ahead of it. In the worst case, every one of those becomes stalled and 1 second is required for each statement before the next statement is retrieved from the high- priority queue. Thus, in this scenario, it takes 222 seconds before the new statement starts executing. This example shows a worst case for an application. How to handle it depends on the application. If the application has high requirements for the response time, it should most likely throttle users at a higher level itself. Otherwise, it can use the thread pool configuration parameters to set some kind of a maximum waiting time. MySQL supports query rewrite plugins that can examine and possibly modify SQL statements received by the server before the server executes them. See Query Rewrite Plugins. MySQL distributions include a postparse query rewrite plugin named  Rewriter  and scripts for installing the plugin and its associated elements. These elements work together to provide statement-rewriting capability: •A server-side plugin named  Rewriter  examines statements and may rewrite them, based on its in- memory cache of rewrite rules. •There are 200 statements queued in the low-priority queue. •There are 10 statements queued in the high-priority queue. • thread_pool_prio_kickup_timer  is set to 10000 (10 seconds). • thread_pool_stall_limit  is set to 100 (1 second). 5.6.4 The Rewriter Query Rewrite Plugin 1086