क्या आप SHOW TABLE STATUS कर रहे हैं? आपके ड्रॉप के पहले और बाद में + पुनर्निर्माण? क्या Index_length बहुत बदलता है? शायद दो के एक फ़ैक्टर से भी नहीं।
मैं लगभग कभी भी InnoDB में कुछ भी पुनर्निर्माण करने की अनुशंसा नहीं करता हूं। यह इसके लायक नहीं है। एक स्पष्ट अपवाद FULLTEXT . से संबंधित है अनुक्रमणिका।
हाँ डमी ALTER अनुक्रमणिका का पुनर्निर्माण करेगा। तो OPTIMIZE TABLE . होगा . दोनों सेकेंडरी इंडेक्स बीट्री और मुख्य बीट्री (जिसमें डेटा और PRIMARY KEY शामिल हैं) को "डीफ़्रैग्मेन्ट" (कुछ हद तक) करेंगे। )।
आंकड़े बहुत हो सकते हैं केवल ANALYZE TABLE . का उपयोग करके अधिक सस्ते में अपडेट किया गया . यहां तक कि अक्सर इसकी जरूरत नहीं होती है। 5.6 में आँकड़ों को बनाए रखने का एक बेहतर तरीका है।
यदि आप पहले से innodb_file_per_table=ON . का उपयोग नहीं कर रहे हैं , मेरा सुझाव है कि आप इसे सेट करें (SET GLOBAL ... ) और ALTER TABLE tbl ENGINE=InnoDB; . करें एक आखिरी बार।
ऑनलाइन परिवर्तन
ft_* बदलने के लिए , आपको अनुक्रमणिका का पुनर्निर्माण करने की आवश्यकता है। इसका मतलब है एक ALTER (या OPTIMIZE , जिसे ALTER . के रूप में लागू किया गया है ) MySQL के नए संस्करणों में ALGORITHM=INPLACE है जो ALTER . बनाता है रनिंग सिस्टम पर बहुत कम या कोई प्रभाव नहीं पड़ता है। लेकिन, सीमाएं हैं। मैनुअल की जाँच करें।
गैर-INPLACE का एक विकल्प ALTER है pt-query-digest या gh-ost . देखें कि उनमें से कोई आपके मामले में काम करेगा या नहीं।
"तालिका के पुनर्निर्माण" से छोटा, आप DROP INDEX ... . कर सकते हैं और ADD INDEX ... . दोबारा, मुझे नहीं पता कि ये एफटी इंडेक्स "इनप्लेस" के लिए काम करते हैं या नहीं। वैसे भी, आप इस प्रक्रिया के दौरान उस अनुक्रमणिका का उपयोग खो देंगे।
