SQL डंप से केवल स्कीमा (संरचना) एक्सपोर्ट करें

तीन स्थितियाँ बार-बार सामने आती हैं:

• स्टेजिंग या CI के लिए स्कीमा खड़ा करें — आप खाली टेबल संरचना चाहते हैं ताकि टेस्ट वास्तविक कॉलम, इंडेक्स और कंस्ट्रेंट के विरुद्ध चल सकें, लेकिन आप बिल्कुल नहीं चाहते कि गीगाबाइट प्रोडक्शन रो एक अस्थायी वातावरण में जाएँ।
• केवल सीड डेटा — स्कीमा लक्ष्य डेटाबेस में पहले से मौजूद है, और आपको इसे भरने के लिए बस INSERT रो चाहिए, बिना उन CREATE स्टेटमेंट के जो वहाँ मौजूद के साथ टकराएँगे।
• शोर से छुटकारा पाएँ — डंप logs, sessions, audit_trail या cache टेबलों से फूला हुआ है जिनमें करोड़ों रो हैं जिन्हें आप कभी इम्पोर्ट नहीं करना चाहते।

mysqldump --no-data क्यों पर्याप्त नहीं है

क्लासिक सलाह है mysqldump --no-data (केवल संरचना) या mysqldump --no-create-info (केवल डेटा)। दोनों एक्सपोर्ट फ़्लैग हैं: वे बदलते हैं कि किसी चालू डेटाबेस से एक नया डंप क्या समाहित करता है। जो डंप आपके पास पहले से ही डिस्क पर एक .sql फ़ाइल के रूप में पड़ा है, उसके लिए वे कुछ नहीं करते।

व्यवहार में फ़ाइल अक्सर किसी और से आती है, या किसी बैकअप जॉब से, या किसी ऐसे सर्वर से जिस तक अब आपकी लाइव पहुँच नहीं है। आप किसी ऐसे डेटाबेस के विरुद्ध mysqldump दोबारा नहीं चला सकते जो पहुँच में ही नहीं है — क्रेडेंशियल जा चुके हैं, सर्वर बंद हो चुका है, या फ़ाइल ही वह सब कुछ है जो आपको सौंपा गया था। उस बिंदु पर फ़्लैग बेकार हैं, और आप फ़ाइल को खुद संपादित करने पर मजबूर हो जाते हैं।

मैन्युअल तरीका

स्पष्ट कदम है grep या sed से लाइनें हटाना। संरचना रखने और डेटा हटाने के लिए:

# INSERT रो को छोड़कर सब कुछ रखें
grep -v '^INSERT INTO' dump.sql > schema.sql

# या केवल-डेटा फ़ाइल के लिए सिर्फ़ INSERT रो रखें
grep '^INSERT INTO' dump.sql > data.sql

यह एक छोटे, साफ़-सुथरे डंप पर ठीक दिखता है — और फिर एक वास्तविक डंप पर टूट जाता है:

• मल्टी-लाइन INSERT। एक अकेला INSERT INTO … VALUES हज़ारों लाइनों तक फैल सकता है। grep पहली लाइन से मेल खाता है और बाकी मानों को अनाथ छोड़ देता है, जिससे एक टूटी हुई फ़ाइल बनती है।
• एक्सटेंडेड इन्सर्ट। mysqldump कई रो को एक विशाल स्टेटमेंट में बैच कर देता है। लाइन-आधारित फ़िल्टर यह नहीं बता सकते कि ऐसा स्टेटमेंट कहाँ समाप्त होता है।
• कमेंट और ब्लॉक। कंडीशनल /*! … */ ब्लॉक, LOCK TABLES, और -- कमेंट डेटा के बीच घुले-मिले होते हैं, इसलिए एक भोला फ़िल्टर या तो कचरा रख लेता है या कुछ ऐसा काट देता है जिसकी इम्पोर्ट को ज़रूरत होती है।
• केवल-डेटा और भी बदतर है। एक शुद्ध grep '^INSERT' उन SET और LOCK स्टेटमेंट को फेंक देता है जिन पर रो निर्भर करती हैं, और कोई भी INSERT जो कॉलम शून्य से ठीक शुरू नहीं होता, चुपचाप गायब हो जाता है।

आप अपना स्कीमा पाने के बजाय अपने ही फ़िल्टर को डीबग करने में लग जाते हैं।

DumpCleaner के साथ केवल-संरचना या केवल-डेटा

DumpCleaner लाइनों से मिलान करने के बजाय SQL स्टेटमेंट को समझता है, इसलिए यह संरचना को डेटा से भरोसेमंद तरीके से अलग करता है — किसी भी आकार की फ़ाइलों पर:

1. अपना .sql डंप DumpCleaner में खींचें (MySQL, MariaDB या PostgreSQL)। यह फ़ाइल को स्ट्रीमिंग करके पार्स करता है, इसलिए एक मल्टी-गीगाबाइट डंप स्थिर मेमोरी के साथ लोड होता है।
2. जो स्टेटमेंट प्रकार आप चाहते हैं उन्हें टॉगल करें: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET। INSERT INTO को अनचेक करें और आपको केवल संरचना मिलती है; CREATE TABLE / CREATE INDEX को अनचेक करें और आपको केवल डेटा मिलता है।
3. या एक प्रीसेट चुनें — केवल संरचना या केवल डेटा — ताकि हर टॉगल एक ही चरण में सेट हो जाए, फिर चाहें तो प्रति टेबल परिष्कृत करें।
4. एक्सपोर्ट करें। आपको स्टेजिंग या CI के लिए एक हल्की स्कीमा फ़ाइल मिलती है, या सीडिंग के लिए एक साफ़ केवल-डेटा डंप।

चूँकि फ़िल्टर स्टेटमेंट-अवगत है, एक मल्टी-लाइन एक्सटेंडेड INSERT को पूरे के रूप में रखा या हटाया जाता है — कभी बीच से नहीं काटा जाता।

असली ताकत यह है कि फ़िल्टरिंग प्रति स्टेटमेंट प्रकार और प्रति टेबल काम करती है, और दोनों मिलकर काम करते हैं। आप हर टेबल की संरचना रख सकते हैं लेकिन INSERT डेटा केवल उन्हीं तीन टेबलों के लिए शामिल कर सकते हैं जिनकी आपको वास्तव में ज़रूरत है — 8.9 करोड़ रो वाली logs टेबल को एक खाली खोल के रूप में छोड़ते हुए। यह ऐसी चीज़ है जिसे कोई भी --no-data फ़्लैग व्यक्त नहीं कर सकता।

अक्सर पूछे जाने वाले प्रश्न