In some cases, the server creates internal temporary tables while processing statements. Users have no direct control over when this occurs.
The server creates temporary tables under conditions such as these:
Evaluation of UNION
statements.
Evaluation of some views, such those that use the
TEMPTABLE algorithm,
UNION, or aggregation.
Evaluation of derived tables (subqueries in the
FROM clause).
Tables created for subquery or semi-join materialization (see Section 8.2.1.18, “Subquery Optimization”).
Evaluation of statements that contain an ORDER
BY clause and a different GROUP
BY clause, or for which the ORDER
BY or GROUP BY contains columns
from tables other than the first table in the join queue.
Evaluation of DISTINCT combined with
ORDER BY may require a temporary table.
For queries that use the SQL_SMALL_RESULT
option, MySQL uses an in-memory temporary table, unless the
query also contains elements (described later) that require
on-disk storage.
Evaluation of multiple-table
UPDATE statements.
Evaluation of GROUP_CONCAT()
or COUNT(DISTINCT)
expressions.
To determine whether a statement requires a temporary table, use
EXPLAIN and check the
Extra column to see whether it says
Using temporary (see
Section 8.8.1, “Optimizing Queries with EXPLAIN”). EXPLAIN
will not necessarily say Using temporary for
derived or materialized temporary tables.
When the server creates an internal temporary table (either in
memory or on disk), it increments the
Created_tmp_tables status
variable. If the server creates the table on disk (either
initially or by converting an in-memory table) it increments the
Created_tmp_disk_tables status
variable.
Some query conditions prevent the use of an in-memory temporary table, in which case the server uses an on-disk table instead:
Presence of any string column in a GROUP
BY or DISTINCT clause larger
than 512 bytes for binary strings or 512 characters for
nonbinary strings. (Before MySQL 5.6.15, the limit is 512
bytes regardless of string type.)
Presence of any string column with a maximum length larger
than 512 (bytes for binary strings, characters for nonbinary
strings) in the SELECT list,
if UNION or
UNION ALL
is used
The SHOW COLUMNS and
DESCRIBE statements use
BLOB as the type for some columns, thus
the temporary table used for the results is an on-disk
table.
An internal temporary table can be held in memory and
processed by the MEMORY storage engine, or
stored on disk and processed by the MyISAM
storage engine.
If an internal temporary table is created as an in-memory
table but becomes too large, MySQL automatically converts it
to an on-disk table. The maximum size for in-memory temporary
tables is determined from whichever of the values of
tmp_table_size and
max_heap_table_size is
smaller. This differs from MEMORY tables
explicitly created with CREATE
TABLE: For such tables, only the
max_heap_table_size system
variable determines how large the table is permitted to grow
and there is no conversion to on-disk format.
In-memory temporary tables are managed by the
MEMORY storage engine, which uses
fixed-length row format. VARCHAR and
VARBINARY column values are padded to the
maximum column length, in effect storing them as
CHAR and BINARY columns.
On-disk temporary tables are managed by the
MyISAM storage engine using dynamic-width
row format. Columns take only as much storage as needed, which
reduces disk I/O and space requirements, and processing time
compared to on-disk tables that use fixed-length rows.
Prior to MySQL 5.6.5, on-disk temporary table storage uses fixed-length rows.
For statements that initially create an internal temporary
table in memory, then convert it to an on-disk table, better
performance might be achieved by skipping the conversion step
and creating the table on disk to begin with. The
big_tables system variable
can be used to force disk storage of internal temporary
tables.