The max_heap_table_size is a system variable that has both read/write property. Initially, max_heap_table_size has size 16 MB. First, check the value of max_heap_table_size, which is in bytes.
System variables can be set at server startup using options on the command line or in an option file. Most of them can be changed dynamically while the server is running by means of the SET statement, which enables you to modify operation of the server without having to stop and restart it.
To assign a value to a global system variable, precede the variable name by the GLOBAL keyword or the @@GLOBAL. qualifier: SET GLOBAL max_connections = 1000; SET @@GLOBAL.
On MySQL website net_read_timeout is describe as "The number of seconds to wait for more data from a connection before aborting the read" .
Whenever you increase tmp_table_size and max_heap_table_size, keep in mind that setting these does not make queries behave better. It actually make inefficient queries behave worse than before. Under what circumstances?
When a query performs a join or sort (via ORDER BY
) without the benefit of an index, a temp table has to be formed in memory. This would increment Created_tmp_tables.
What if the temp table grows to the number of bytes in tmp_table_size and needs more space? The following sequence of events happens:
This process increments Created_tmp_disk_tables
Knowing these mechanisms, let's explore what happened in each instance
disk tables decreased from 27.37% to 21.70% -> expected much more
This could easily happen if the queries that ran before have cached results remaining in RAM. This would eliminate the need to process the query from the beginning and not recreate the same large temp tables.
temporary files rise form 1.16% to 33.75% -> why ?
This is not surprising. This simply brings out the fact that there are queries that require temp tables. They were created in RAM first. This just indicates the presence of queries that do not join well (maybe join_buffer_size is too small) or ORDER BY
non-indexed columns or columns with a temp table (maybe sort_buffer_size is too small).
memory tables decreased from 71.48% to 44.55% -> strange; expected to rise
This is not surprising either. If there are enough calls for the same query with the same values, sorts and joins may be preempted by the fulfillment of queries from previously cached results.
In light of these things, here is what could be adjusted:
The overall goal should be to prevent temp table creation as much as possible. Simply increasing tmp_table_size and max_heap_table_size lets inefficient queries and tables that lack proper indexing run amok.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With