Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Mysql tmp_table_size max_heap_table_size

Tags:

mysql

People also ask

What is max_heap_table_size in MySQL?

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.

How do I set system variables in MySQL?

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.

How do I change global variables in MySQL?

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.

What is Net_read_timeout in MySQL?

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:

  1. Query processing must stop
  2. Create a temp table on disk
  3. Transfer the contents of the memory-based temp table into the disk-based temp table
  4. Drop in the memory-based temp table
  5. Query processing continue using the disk-based temp table

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.

RECOMMENDATION

In light of these things, here is what could be adjusted:

  • join_buffer_size
  • sort_buffer_size
  • Create indexes that would be used
    • in joins via eq_ref
    • in sorts via index scans in order

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.