There're more stats than Created_tmp_tables and Created_tmp_disk_tables:

MariaDB [test]> show status like '%_tmp_%';

+-------------------------+-------+

| Variable_name           | Value |

+-------------------------+-------+

| Created_tmp_disk_tables | 0     |

| Created_tmp_files       | 4     |

| Created_tmp_tables      | 2     |

| Handler_tmp_delete      | 0     |

| Handler_tmp_update      | 0     |

| Handler_tmp_write       | 4     |

| Rows_tmp_read           | 4     |

+-------------------------+-------+

7 rows in set (0.002 sec)

would that be sufficient?

to monitor the space we need to take into account both temp tables and temp files.

Tables are easier, they're files on disk, one can see file sizes, one can see what query created what tables (as every #sql table name as a connection id as part of the file name). A sum of all writes into a temp table is wrong, there can be updates and deletes, no every write adds to the disk use.

Files are somewhat difficult as they don't have directory entries, only an open file descriptor. And they can be big and eat up a lot of disk space

What should be monitored are:

• Temporary files created by filesort and replication buffers and
  sorting in engines as part of alter table, repair table, optimize table.
  As (almost?) all server temporary files are using the IO_CACHE interface,
  the 2 first are relatively easy to do, the engine temporary files a bit harder.

• On disk internal temporary tables (MyISAM or Aria). These are relatively
  easy to handle.
• Explicitly created temporary tables (CREATE TEMPORARY TABLE).
  These are hard to do as this require a change in the storage engine
  interface to store status information into the corresponding THD.
  We could 'as a temporary solution' get this information from the file
  system. As the temporary tables includes the session id, it is easy to
  attach these to each user.