MySQL bruger et trick, der har været en del af POSIX-systemer for evigt. Den åbner den midlertidige fil og fjerner den straks. Derfor kan den ikke ses i nogen mappeliste. Men POSIX-systemer som UNIX og Linux bør faktisk ikke fjerne en ulinket fil, mens en proces har et åbent filhåndtag. Så når forespørgslen ved hjælp af den midlertidige tabel er færdig, vil den lukke filhåndtaget, og derefter vil OS automatisk fjerne filen og frigøre den lagerplads, den brugte.
Dette er generelt bedre end at kræve, at serverkoden skal huske at fjerne tempfilen, når den er færdig med den. Det står også for, at tråden afsluttes, eller mysqld går ned. Det vil i det mindste ikke efterlade forældede midlertidige filer i dit filsystem.
Du kan se størrelsen af ikke-linkede filer med lsof -s . Jeg vil overlade det til dig at finde eksempler på, hvordan du bruger denne kommando (Google er din ven her).
Det er yderst muligt, at en midlertidig fil bruger dine 167 GB ledig plads.
Eller det kan være, at den midlertidige fil kun bruger 8 GB, men du kan have 20 tråde, der laver den samme forespørgsel på samme tid. Jeg har set det ske én gang.
Men det er nok mere sandsynligt, at du har en værdi på tmp_table_size det begrænser størrelsen af temp-tabellen.
Hvis du rammer grænsen, kan du hæve denne konfigurationsmulighed, enten som en sessionsvariabel, når du har brug for den, eller globalt i my.cnf .
Men jeg ville først prøve at optimere forespørgslen. Hvorfor er det nødvendigt at lave så store vikarborde? Kan det optimeres til at undersøge færre rækker, eller måske helt undgå at oprette en midlertidig tabel?