MySQL utilise une astuce qui fait partie des systèmes POSIX depuis toujours. Il ouvre le fichier temporaire et le dissocie immédiatement. Par conséquent, il n'est visible dans aucune liste de répertoires. Mais les systèmes POSIX comme UNIX et Linux ne devraient pas réellement supprimer un fichier non lié alors qu'un processus a un descripteur de fichier ouvert. Ainsi, une fois la requête utilisant la table temporaire terminée, elle fermera le descripteur de fichier, puis le système d'exploitation supprimera automatiquement le fichier et libérera le stockage qu'il utilisait.
C'est généralement mieux que d'exiger que le code du serveur n'oublie pas de supprimer le fichier temporaire quand il en a fini avec lui. Cela tient également compte de la fin du thread ou du plantage de mysqld. Au moins, il ne laissera pas de fichiers temporaires obsolètes sur votre système de fichiers.
Vous pouvez afficher la taille des fichiers non liés avec lsof -s . Je vous laisse chercher des exemples d'utilisation de cette commande (Google est votre ami ici).
Il est peu probable qu'un fichier temporaire utilise vos 167 Go d'espace libre.
Ou il se peut que le fichier temporaire n'utilise que 8 Go, mais vous pouvez avoir 20 threads effectuant la même requête en même temps. J'ai vu cela se produire une fois.
Mais il est probablement plus probable que vous ayez une valeur de tmp_table_size qui limite la taille de la table temporaire.
Si vous atteignez la limite, vous pouvez augmenter cette option de configuration, soit en tant que variable de session lorsque vous en avez besoin, soit globalement dans le my.cnf .
Mais je voudrais d'abord essayer d'optimiser la requête. Pourquoi a-t-il besoin de créer des tables temporaires aussi volumineuses ? Pourrait-il être optimisé pour examiner moins de lignes, ou peut-être éviter de créer complètement une table temporaire ?
