MySqlDump के डिसेबल कुंजी का आयात पर कोई प्रभाव नहीं है

Question

इन्नो-टेबल्स (आश्चर्य!) के साथ आयात की गति के संबंध में मेरे पिछले प्रश्न का अनुसरण है ।

परिदृश्य
मैं उचित समय में अपने स्थानीय देव मशीन पर कुछ बड़े * डेटाबेस डंप आयात करने की कोशिश करता हूं। हमारे पास बहुत सी KEYसारणियाँ हैं जो एक अड़चन के रूप में सामने आई हैं लेकिन अभी भी हमारी लाइव प्रणाली के लिए महत्वपूर्ण हैं।

ऊपर प्रश्न पूछने के बाद मेरा दृष्टिकोण KEY ...डंप, आयात और फिर से जोड़ने वाली कुंजियों के बयानों को हटाना था ।

हालांकि मैं अक्सर खुद को स्थानीय रूप से आयात करने के लिए एक वर्तमान डंप का संपादन करता हुआ पाता हूं और मैं इन मजेदार "टिप्पणियों" (द disable/enable keys-लाइन्स) को ठोकर मारता हूं

--
-- Dumping data for table `monster`
--

LOCK TABLES `monster` WRITE;
/*!40000 ALTER TABLE `monster` DISABLE KEYS */;
INSERT … INSERT … INSERT
/*!40000 ALTER TABLE `monster` ENABLE KEYS */;
UNLOCK TABLES;

लेकिन वास्तव में ये "टिप्पणियां" सशर्त MySql-Statements हैं

यह मेरे लिए खबर थी, लेकिन ठीक है, आउटपुट फॉर्म को देखते हुए mysql --versionसब कुछ मुझे ठीक लग रहा है: mysql Ver 14.14 Distrib 5.5.38, for debian-linux-gnu (x86_64) using readline 6.3

मुझे लगता है
कि मेज बंद है (ठीक है, यह सिर्फ देव मैशाइन पर है)। तब तालिका स्कीमा में परिभाषित कीज़ को अक्षम किया जाता है, डेटा आयात किया जाता है, कुंजियाँ सक्षम की जाती हैं।
इसलिए "डेटा सम्मिलन" के दौरान-कुंजियों पर कोई समय बर्बाद नहीं करना चाहिए, बल्कि सभी डेटा डालने के बाद जांच की जानी चाहिए।

मैं सोच रहा हूं कि यह वही व्यवहार है जैसे मैं KEY 'foo' (foo)'डंप से सभी- स्टोरी को हटाता हूं , डंप को आयात करता हूं और ADD KEY 'foo' ...बाद में स्क्रिप्ट चलाता हूं ।

मैं जो निरीक्षण करता हूं
वह कुंजियों को मैन्युअल रूप से हटाने, आयात करने और फिर से जोड़ने के लिए तेजी से रास्ता है, फिर सशर्त DISABLE KEYSबयानों पर भरोसा करते हुए मेरी बनाईmysqldump

डंप + mysql आयात + जोड़ चाबियाँ = 15 + 8 + 8 s 30min के
सादे संपादन mysql आयात: दिया, (मैं सिर्फ 8 घंटे / दिन के लिए भुगतान कर रहा हूं :))

मैं मदद नहीं कर सकता, लेकिन यह सोचकर कि मैं यहाँ बहुत मौलिक कुछ याद कर रहा हूँ (या डेटाबेस मुझे ट्रोल कर रहा है)।

Comments

लघु अवधि: उपयोग mysqldump --innodb-optimize-keysPercona से percona.com/doc/percona-server/5.5/management/... दीर्घकालिक: mysqldump और उपयोग mydumper या xtrabackup का उपयोग कर बंद करो।

— ज्युनस

Answer 1

आप InnoDB पर DISABLE KEYS;और उसके ENABLE KEYS;लिए भरोसा नहीं कर सकते क्योंकि यह InnoDB संग्रहण इंजन में लागू नहीं है। रनिंग ALTER TABLE ... DISABLE KEYS;और ALTER TABLE ... ENABLE KEYS;MyISAM के लिए डिज़ाइन किए गए थे। जैसा कि इसके लिए MySQL प्रलेखनALTER TABLE में कहा गया है :

यदि आप किसी MyISAM टेबल पर ALTER TABLE का उपयोग करते हैं, तो सभी nonunique index एक अलग बैच (REPAIR TABLE के लिए) में बनाए जाते हैं। जब आपके पास कई अनुक्रमणिकाएँ हों, तो इसे बहुत तेज़ी से बनाना चाहिए।

MyISAM तालिकाओं के लिए, कुंजी अपडेट को स्पष्ट रूप से नियंत्रित किया जा सकता है। नॉन-इंडेक्स अपडेट करने से रोकने के लिए MySQL को बताने के लिए ALTER TABLE ... DISABLE कुंजी का उपयोग करें। फिर लापता सूचियों को फिर से बनाने के लिए बदलिए ... सक्षम करें का उपयोग करें। MyISAM एक विशेष एल्गोरिथ्म के साथ ऐसा करता है जो एक-एक करके चाबियाँ डालने की तुलना में बहुत तेज़ है, इसलिए थोक सम्मिलित संचालन करने से पहले कुंजियों को अक्षम करने से काफी गति प्राप्त करनी चाहिए। ALTER TABLE ... डिसेबल कुंजी का उपयोग करने के लिए पहले बताए गए विशेषाधिकारों के अलावा INDEX विशेषाधिकार की आवश्यकता होती है।

जबकि गैर-अनुक्रमणिका अक्षम हैं, उन्हें SELECT और EXPLAIN जैसे कथनों के लिए अनदेखा किया जाता है जो अन्यथा उनका उपयोग करेंगे।

कोई उल्लेख कभी भी InnoDB के संदर्भ में नहीं किया गया है ALTER TABLE ... DISABLE/ENABLE KEYS;

यहां तक ​​कि अगर आप ALTER TABLE ... DISABLE KEYS;एक InnoDB तालिका के खिलाफ चलाते हैं , तो यह एक चेतावनी उत्पन्न करता है:

mysql> show create table mytimes\G
*************************** 1. row ***************************
       Table: mytimes
Create Table: CREATE TABLE `mytimes` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `totalTime` int(11) NOT NULL,
  `totalTimeDesc` varchar(128) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> alter table mytimes disable keys;
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> show warnings;
+-------+------+-------------------------------------------------------------+
| Level | Code | Message                                                     |
+-------+------+-------------------------------------------------------------+
| Note  | 1031 | Table storage engine for 'mytimes' doesn't have this option |
+-------+------+-------------------------------------------------------------+
1 row in set (0.00 sec)

mysql>

इसलिए कोई असर नहीं है। कृपया याद रखें कि @jynus ने बुलेटपॉइंट 7 में अपने जवाब में उसी बात का उल्लेख किया था ।

यह भी ध्यान रखें कि MyISAM डेटा और इंडेक्स को दो अलग-अलग फ़ाइलों में रखता है (.MYD डेटा के लिए, .MYI इंडेक्स के लिए), इसलिए यह इंडेक्स को अक्षम और सक्षम करने के लिए तुच्छ होगा। InnoDB PRIMARY KEY और पंक्ति डेटा को समान InnoDB पृष्ठों (क्लस्टर इंडेक्स के माध्यम से) में रखता है। द्वितीयक सूचकांक प्रत्येक प्राथमिक सूचकांक पत्ती प्रविष्टि के लिए अनुलग्नक के रूप में प्राथमिक कुंजी ले जाएगा । चूंकि डेटा और इंडेक्स को क्लस्टर्ड इंडेक्स के माध्यम से इंटरवेट किया जाता है, इसलिए किसी के पास अभी तक लागू करने का प्रयास नहीं किया गया है DISABLE KEYSऔर ENABLE KEYSइनोबीडी में।

Comments

"मैंने तुमसे कहा था" :-)

— jynus

@ जीनस हा हा :-)। आपको उत्तर के रूप में InnoDB ( dba.stackexchange.com/questions/76565/… ) के लिए अपना mysqldump टिप्पणी पोस्ट करना चाहिए ।

— रोलैंडमाइसीडीडीबीए

@ जोशी मैं आपके मूल प्रश्न पर आधारित लेख लिख रहा हूं, देखते रहिए।

— जिन्नस

@yosi जैसा कि वादा किया गया: dbahire.com/…

— jynus

@RolandoMySQLDBA, यदि InnoDB कुंजियाँ अक्षम / अक्षम नहीं कर सकती हैं, तो क्या यह केवल चेतावनी के बजाय एक त्रुटि नहीं है ?

— पचेरियर