MySQL एक ट्रिक का उपयोग करता है जो हमेशा के लिए POSIX सिस्टम का हिस्सा रहा है। यह अस्थायी फ़ाइल खोलता है, और तुरंत इसे अनलिंक करता है। इसलिए यह किसी भी निर्देशिका सूची में देखने योग्य नहीं है। लेकिन POSIX सिस्टम जैसे UNIX और Linux को वास्तव में एक अनलिंक की गई फ़ाइल को नहीं निकालना चाहिए, जबकि एक प्रक्रिया में एक खुली फ़ाइल हैंडल होती है। तो एक बार जब अस्थायी तालिका का उपयोग करने वाली क्वेरी समाप्त हो जाती है, तो यह फ़ाइल हैंडल को बंद कर देगी, और फिर OS स्वचालित रूप से फ़ाइल को हटा देगा और उस संग्रहण को मुक्त कर देगा जिसका वह उपयोग कर रहा था।
यह आम तौर पर सर्वर कोड की आवश्यकता से बेहतर होता है जब इसके साथ किया जाता है तो tempfile को हटाने के लिए याद रखें। यह थ्रेड टर्मिनेटिंग, या mysqld क्रैशिंग की तरह भी खाता है। कम से कम यह आपके फाइल सिस्टम को खराब करने वाली पुरानी अस्थायी फ़ाइलों को नहीं छोड़ेगा।
आप अनलिंक की गई फ़ाइलों का आकार lsof -s . के साथ देख सकते हैं . उस आदेश का उपयोग करने के उदाहरण देखने के लिए मैं इसे आप पर छोड़ता हूं (यहां Google आपका मित्र है)।
यह बहुत कम संभव है कि कोई अस्थायी फ़ाइल आपके 167GB खाली स्थान का उपयोग करे।
या यह हो सकता है कि अस्थायी फ़ाइल केवल 8GB का उपयोग करती है, लेकिन आपके पास एक ही समय में एक ही क्वेरी करने वाले 20 धागे हो सकते हैं। मैंने एक बार ऐसा होते देखा है।
लेकिन इसकी अधिक संभावना है कि आपके पास tmp_table_size . का मान हो यह अस्थायी तालिका के आकार को सीमित कर रहा है।
यदि आप सीमा से टकराते हैं, तो आप उस कॉन्फ़िगरेशन विकल्प को बढ़ा सकते हैं, या तो सत्र चर के रूप में जब आपको इसकी आवश्यकता हो, या विश्व स्तर पर my.cnf में ।
लेकिन मैं पहले क्वेरी को अनुकूलित करने का प्रयास करूंगा। इतनी बड़ी अस्थायी तालिकाएँ बनाने की आवश्यकता क्यों है? क्या इसे कम पंक्तियों की जांच करने के लिए अनुकूलित किया जा सकता है, या शायद पूरी तरह से एक अस्थायी तालिका बनाने से बचें?
