InnoDB आयात प्रदर्शन

Question

मैं एक बहुत बड़ी InnoDB-तालिका आयात करने के साथ थोक में संघर्ष कर रहा हूँ जिसमें लगभग 10 मिलियन पंक्तियाँ (या 7GB) हैं (जो मेरे लिए मेरे द्वारा अब तक काम की गई सबसे बड़ी तालिका है)।

मैंने कुछ शोध किया कि इनो की आयात गति में सुधार कैसे किया जाए और फिलहाल मेरा सेटअप इस तरह दिखता है:

/etc/mysql/my.cnf/
[...]
innodb_buffer_pool_size = 7446915072 # ~90% of memory
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_io_capacity = 5000
innodb_thread_concurrency=0
innodb_doublewrite = 0
innodb_log_file_size = 1G
log-bin = ""
innodb_autoinc_lock_mode = 2
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit=2
innodb_buffer_pool_instances=8


import is done via bash script, here is the mysql code:
SET GLOBAL sync_binlog = 1;
SET sql_log_bin = 0;
SET FOREIGN_KEY_CHECKS = 0;
SET UNIQUE_CHECKS = 0;
SET AUTOCOMMIT = 0;
SET SESSION tx_isolation='READ-UNCOMMITTED';
LOAD DATA LOCAL INFILE '$filepath' INTO TABLE monster
COMMIT;

डेटा एक CSVफ़ाइल में प्रदान किया गया है।
वर्तमान में मैं 2 मिलियन, 3 मिलियन,… के साथ छोटे 'टेस्ट डंप' के साथ अपनी सेटिंग्स का परीक्षण करता हूं और time import_script.shप्रदर्शन की तुलना करने के लिए उपयोग करता हूं ।

दोष यह है कि मुझे केवल एक समग्र समय मिल रहा है इसलिए मुझे परिणाम प्राप्त करने के लिए पूर्ण आयात की प्रतीक्षा करनी होगी।

अब तक के मेरे परिणाम:

• 10 000 पंक्तियाँ: <1 सेकंड
• 100 000 पंक्तियाँ: 10 सेकंड
• 300 000 पंक्तियाँ: 40 सेकंड
• 2 मिलियन पंक्तियाँ: 18 मिनट
• 3 मिलियन पंक्तियाँ: 26 मिनट
• 4 मिलियन पंक्तियाँ: (2 घंटे के बाद रद्द)

ऐसा लगता है कि कोई 'रसोई की किताब' समाधान नहीं है और किसी को अपने आप ही सेटिंग्स के इष्टतम मिश्रण का पता लगाना होगा।
अपने सेट अप में क्या बदलाव करना है इसके बारे में सुझाव के अलावा, मैं वास्तव में अधिक जानकारी की सराहना करूंगा कि मैं आयात प्रक्रिया को बेहतर कैसे मान सकता हूं / अधिक जानकारी प्राप्त कर सकता हूं कि क्या हो रहा है और कहां अड़चन हो सकती है।
मैंने उन सेटिंग्स के लिए दस्तावेज़ीकरण को पढ़ने की कोशिश की जो मैं बदल रहा हूं, लेकिन फिर मैं किसी भी साइड-इफेक्ट के बारे में नहीं जानता हूं और अगर मैं बुरी तरह से चुने गए मूल्य के साथ प्रदर्शन को कम कर सकता हूं।

फिलहाल मैं MyISAMआयात के दौरान उपयोग करने और बाद में टेबल इंजन बदलने के लिए चैट से एक सुझाव की कोशिश करना चाहूंगा ।
मैं यह कोशिश करना चाहता हूं, लेकिन इस पल के लिए मेरी DROP TABLEक्वेरी को समाप्त होने में भी घंटों लगते हैं। (जो एक और संकेतक लगता है कि मेरी सेटिंग कम है तो इष्टतम है)।

अतिरिक्त जानकारी:
वर्तमान में मैं जिस मशीन का उपयोग कर रहा हूं उसमें 8GB RAM और एक सॉलिड स्टेट हाइब्रिड हार्ड ड्राइव w / 5400RPM है।
हालांकि, हमारा लक्ष्य तालिका के अप्रचलित डेटा को हटाने का लक्ष्य है, जबकि मुझे अभी भी विकासशील और बी) के
परीक्षण के लिए कुछ हद तक तेजी से आयात की आवश्यकता है, automatic data cleanup featureजबकि
हमारे सर्वर के क्रैश होने पर हम अपने 2 सर्वर को प्रतिस्थापन के रूप में उपयोग करना चाहते हैं (जिसकी आवश्यकता है) अंतिम तिथि डेटा, अंतिम आयात 24 घंटे से अधिक समय लगा)

mysql> SHOW CREATE TABLE monster\G
*************************** 1. row ***************************
       Table: monster
Create Table: CREATE TABLE `monster` (
  `monster_id` int(11) NOT NULL AUTO_INCREMENT,
  `ext_monster_id` int(11) NOT NULL DEFAULT '0',
  `some_id` int(11) NOT NULL DEFAULT '0',
  `email` varchar(250) NOT NULL,
  `name` varchar(100) NOT NULL,
  `address` varchar(100) NOT NULL,
  `postcode` varchar(20) NOT NULL,
  `city` varchar(100) NOT NULL,
  `country` int(11) NOT NULL DEFAULT '0',
  `address_hash` varchar(250) NOT NULL,
  `lon` float(10,6) NOT NULL,
  `lat` float(10,6) NOT NULL,
  `ip_address` varchar(40) NOT NULL,
  `cookie` int(11) NOT NULL DEFAULT '0',
  `party_id` int(11) NOT NULL,
  `status` int(11) NOT NULL DEFAULT '2',
  `creation_date` datetime NOT NULL,
  `someflag` tinyint(1) NOT NULL DEFAULT '0',
  `someflag2` tinyint(4) NOT NULL,
  `upload_id` int(11) NOT NULL DEFAULT '0',
  `news1` tinyint(4) NOT NULL DEFAULT '0',
  `news2` tinyint(4) NOT NULL,
  `someother_id` int(11) NOT NULL DEFAULT '0',
  `note` varchar(2500) NOT NULL,
  `referer` text NOT NULL,
  `subscription` int(11) DEFAULT '0',
  `hash` varchar(32) DEFAULT NULL,
  `thumbs1` int(11) NOT NULL DEFAULT '0',
  `thumbs2` int(11) NOT NULL DEFAULT '0',
  `thumbs3` int(11) NOT NULL DEFAULT '0',
  `neighbours` tinyint(4) NOT NULL DEFAULT '0',
  `relevance` int(11) NOT NULL,
  PRIMARY KEY (`monster_id`),
  KEY `party_id` (`party_id`),
  KEY `creation_date` (`creation_date`),
  KEY `email` (`email`(4)),
  KEY `hash` (`hash`(8)),
  KEY `address_hash` (`address_hash`(8)),
  KEY `thumbs3` (`thumbs3`),
  KEY `ext_monster_id` (`ext_monster_id`),
  KEY `status` (`status`),
  KEY `note` (`note`(4)),
  KEY `postcode` (`postcode`),
  KEY `some_id` (`some_id`),
  KEY `cookie` (`cookie`),
  KEY `party_id_2` (`party_id`,`status`)
) ENGINE=InnoDB AUTO_INCREMENT=13763891 DEFAULT CHARSET=utf8

Comments

क्या आपने 10K या 100K पंक्तियों की तरह कम बड़े आयातों के साथ प्रयास किया?

— ypercube y

कृपया SHOW CREATE TABLE yourtable\Gहमें इस 10 मिलियन पंक्ति तालिका की तालिका संरचना दिखाने के लिए चलाएँ ।

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

@ रोलैंडम्यूसीडीडीबीए तो मैंने (अस्पष्ट क्षेत्र के नाम के साथ) किया

— nuala

डबल राइट बफ़र ( innodb_doublewrite = 0) को अक्षम करने से आपका MySQL इंस्टॉलेशन सुरक्षित क्रैश नहीं होता है: यदि आपके पास कोई पावर विफलता (MySQL क्रैश नहीं है), तो आप डेटा को चुपचाप दूषित कर सकते हैं।

— jfg956

Answer 1

सबसे पहले, आपको यह जानने की जरूरत है कि जब आप लाखों पंक्तियों को एक InnoDB तालिका में रखते हैं, तो आप InnoDB के लिए क्या कर रहे हैं। आइए, InnoDB आर्किटेक्चर पर एक नज़र डालें।

ऊपरी बाएँ कोने में, InnoDB बफर पूल का एक चित्रण है। ध्यान दें कि इसका एक भाग इन्सर्ट बफर को समर्पित है। वह क्या करता है? यह प्रणाली तालिकाओं (उर्फ ibdata1) के अंदर बफ़र पूल से सम्मिलित बफ़र के लिए द्वितीयक अनुक्रमिक में परिवर्तन करने के लिए ised है। डिफ़ॉल्ट रूप से, innodb_change_buffer_max_size को 25 पर सेट किया जाता है। इसका मतलब यह है कि सेकेंडरी इंडेक्स को प्रोसेस करने के लिए बफ़र पूल का 25% तक इस्तेमाल किया जा सकता है।

आपके मामले में, आपके पास InnoDB बफर पूल के लिए 6.935 GB है। आपके सेकेंडरी इंडेक्स को प्रोसेस करने के लिए अधिकतम 1.734 जीबी का इस्तेमाल किया जाएगा।

अब, अपनी तालिका देखें। आपके पास 13 माध्यमिक सूचकांक हैं। आपके द्वारा संसाधित की जाने वाली प्रत्येक पंक्ति को द्वितीयक अनुक्रमणिका प्रविष्टि बनानी चाहिए, इसे पंक्ति की प्राथमिक कुंजी के साथ जोड़े, और उन्हें बफ़र पूल में सम्मिलित बफ़र से जोड़े के रूप में ibdata1 में सम्मिलित बफ़र में भेजें। ऐसा प्रत्येक पंक्ति के साथ 13 बार होता है। इसे 10 मिलियन से गुणा करें और आप आने वाली अड़चन को लगभग महसूस कर सकते हैं।

मत भूलो कि एक ही लेन-देन में 10 मिलियन पंक्तियों को आयात करने से सब कुछ एक रोलबैक खंड में ढेर हो जाएगा और ibdata1 में UNDO स्थान को भर देगा।

सुझाव

शुक्रिया # 1

इसके बजाय बड़ी तालिका के आयात के लिए मेरा पहला सुझाव होगा

• सभी गैर-अद्वितीय अनुक्रमितों को छोड़ दें
• डेटा आयात करें
• सभी गैर-अनन्य अनुक्रमित बनाएं

शुक्रिया # 2

डुप्लिकेट इंडेक्स से छुटकारा पाएं। आपके मामले में, आपके पास है

KEY `party_id` (`party_id`),
KEY `party_id_2` (`party_id`,`status`)

दोनों इंडेक्स शुरू होते हैं party_id, आप सेकेंड इंडेक्स प्रोसेसिंग को कम से कम 7.6% तक बढ़ा सकते हैं

ALTER TABLE monster DROP INDEX party_id;

सुझाव # 3

उन इंडेक्स से छुटकारा पाएं जिनका आप उपयोग नहीं करते हैं। अपने एप्लिकेशन कोड को देखें और देखें कि क्या आपके प्रश्न सभी इंडेक्स का उपयोग करते हैं। आप यह बताने के लिए कि इंडेक्स का उपयोग नहीं किया जा रहा है, यह बताने के लिए कि आप pt-index- उपयोग में देखना चाहते हैं।

उत्तर # 4

डिफ़ॉल्ट 8M होने के बाद से आपको innodb_log_buffer_size को 64M तक बढ़ाना चाहिए । एक बड़ा लॉग बफ़र InnoDB I / O प्रदर्शन को बढ़ा सकता है।

उपसंहार

पहले दो सुझावों को जगह में रखते हुए, निम्नलिखित करें:

• 13 गैर-अद्वितीय अनुक्रमितों को छोड़ें
• डेटा आयात करें
• को छोड़कर सभी गैर-अद्वितीय अनुक्रमणिका बनाएँ party_idसूचकांक

शायद निम्नलिखित मदद कर सकते हैं

CREATE TABLE monster_new LIKE monster;
ALTER TABLE monster_new
  DROP INDEX `party_id`,
  DROP INDEX `creation_date`,
  DROP INDEX `email`,
  DROP INDEX `hash`,
  DROP INDEX `address_hash`,
  DROP INDEX `thumbs3`,
  DROP INDEX `ext_monster_id`,
  DROP INDEX `status`,
  DROP INDEX `note`,
  DROP INDEX `postcode`,
  DROP INDEX `some_id`,
  DROP INDEX `cookie`,
  DROP INDEX `party_id_2`;
ALTER TABLE monster RENAME monster_old;
ALTER TABLE monster_new RENAME monster;

में डेटा आयात करें monster। फिर, इसे चलाएं

ALTER TABLE monster
  ADD INDEX `creation_date`,
  ADD INDEX `email` (`email`(4)),
  ADD INDEX `hash` (`hash`(8)),
  ADD INDEX `address_hash` (`address_hash`(8)),
  ADD INDEX `thumbs3` (`thumbs3`),
  ADD INDEX `ext_monster_id` (`ext_monster_id`),
  ADD INDEX `status` (`status`),
  ADD INDEX `note` (`note`(4)),
  ADD INDEX `postcode` (`postcode`),
  ADD INDEX `some_id` (`some_id`),
  ADD INDEX `cookie` (`cookie`),
  ADD INDEX `party_id_2` (`party_id`,`status`);

कोशिश करो !!!

वैकल्पिक

आप एक तालिका बना सकते हैं जिसे monster_csvMyISAM तालिका कहा जाता है जिसमें कोई अनुक्रमणिका नहीं है और यह करें:

CREATE TABLE monster_csv ENGINE=MyISAM AS SELECT * FROM monster WHERE 1=2;
ALTER TABLE monster RENAME monster_old;
CREATE TABLE monster LIKE monster_old;
ALTER TABLE monster DROP INDEX `party_id`;

में अपना डेटा आयात करें monster_csv। फिर, एक और आयात बनाने के लिए mysqldump का उपयोग करें

mysqldump -t -uroot -p mydb monster_csv | sed 's/monster_csv/monster/g' > data.sql

Mysqldump फ़ाइल data.sqlएक बार में 10,000-20,000 पंक्तियों का आयात करने वाली INSERT कमांड को विस्तारित करेगी।

अब, बस mysqldump लोड करें

mysql -uroot -p mydb < data.sql

अंत में, MyISAM तालिका से छुटकारा पाएं

DROP TABLE monster_csv;

Comments

मुझे उन सभी कुंजियों के बारे में पता भी नहीं था (यह मेरा डिज़ाइन नहीं है) लेकिन आपकी व्याख्या बहुत ही ठोस है। आज के लिए एक और कोशिश शुरू करने की देर है लेकिन मुझे कुछ बेहतरीन सलाह मिली हैं कि कल क्या करना है। आपको सूचित करता रहेगा! <3

— 16

मैं monsterकम से कम 20 मिनट में पूर्ण डेटाबेस (न केवल तालिका) आयात करने में कामयाब रहा जब इनोबीडी टेबल पर कोई कुंजी नहीं थी। चाबियाँ जोड़ने लगभग लिया। एक और 20 मिनट। मैं कहूंगा कि इस मामले में यह मेरी समस्या को हल करता है। आपका बहुत बहुत धन्यवाद!

— nuala

Answer 2

मैं एक टिप्पणी लिखना चाहता था (क्योंकि यह निश्चित उत्तर नहीं है), लेकिन यह बहुत लंबा हो गया:

मैं आपको कई सलाह देने जा रहा हूं, और यदि आप चाहें, तो हम हर एक के विवरण में जा सकते हैं:

• स्थायित्व कम करें (आप पहले से ही कुछ कर चुके हैं)। नवीनतम संस्करण इसे और भी करने की अनुमति देते हैं। आप डबल राइट बफर को निष्क्रिय करने के लिए जा सकते हैं, क्योंकि भ्रष्टाचार आयात की समस्या नहीं है।
• बफ़रिंग बढ़ाएँ: लेन-देन लॉग आकार बढ़ाएँ और उपलब्ध बफ़र पूल आकार बढ़ाएँ। लेन-देन लॉग फ़ाइल उपयोग और चौकियों की निगरानी करें। आयात के लिए विशाल लॉग का डर नहीं है।
• भारी लेन-देन से बचें- आपका रोलबैक अनावश्यक डेटा से भरा हो जाएगा। यह शायद आपकी सबसे बड़ी समस्या है।
• एसक्यूएल एक अड़चन होगी, एसक्यूएल ओवरहेड (हैंडलरकेट, मेमकाटेड) से बचें और / या एक ही समय में कई थ्रेड्स के साथ इसे संगामिति में लोड करें। कंसीडर को एक मीठे स्थान पर पहुंचना है, बहुत ज्यादा नहीं, बहुत कम नहीं।
• प्राथमिक कुंजी क्रम विखंडन में लोड डेटा isse हो सकता है
• अगर आपकी अड़चन है सीपीयू और CPU और मेमोरी इसे धीमा नहीं करता है, तो टेस्ट इनबीडीबी संपीड़न
• बाद में (कुछ मामलों में तेजी से) अपनी माध्यमिक कुंजी बनाने का प्रयास करें, अनुक्रमित डेटा को लोड न करें- अक्षम कुंजी इन्सोडी को प्रभावित नहीं करती है । यदि नहीं, तो अपने सम्मिलित बफ़र की निगरानी करें (हो सकता है कि आपके बफ़र पूल के आधे से आगे निकल जाए)।
• चेकसम एल्गोरिथ्म को बदलें या अक्षम करें- शायद आपका मुद्दा नहीं है, लेकिन यह उच्च अंत फ्लैश कार्ड पर एक अड़चन बन जाता है।
• अंतिम उपाय: अपने वर्तमान अड़चन को खोजने के लिए अपने सर्वर की निगरानी करें और शमन करने का प्रयास करें (InnoDB इसके बारे में बहुत लचीला है)।

याद रखें कि इनमें से कुछ गैर-आयात (सामान्य संचालन) के लिए सुरक्षित या उचित नहीं हैं।

Comments

आपका बहुत बहुत धन्यवाद! मैं पहले इंडेक्स के बारे में रोलैंडो के विचार को आज़माना चाहता हूं, लेकिन मुझे लगता है कि यह "लेनदेन-रोलबैक" सामान अभी भी एक मुद्दा होगा। क्या आपक लिए इसे विस्तार से कहना संभव है? मुझे लगता है कि मैं आयात के दौरान इस कार्यक्षमता को अधिक से अधिक अक्षम करना चाहता हूं और उत्पादन में जाने पर बस फिर से सक्षम करता हूं ~ मुझे लगता है ...

— nuala

रोलैंडो का सुझाव मेरी बात # 7 है। रोलबैक ओवरहेड से बचना उतना ही आसान है जितना SET SESSION tx_isolation='READ-UNCOMMITTED';(यदि आप समानांतर में कई थ्रेड्स के साथ आयात करते हैं तो केवल उपयोगी) और बैचों में डालने के बारे में @ypercube कमेंट करता है। आप एक पूरे उदाहरण यहाँ है: mysqlperformanceblog.com/2008/07/03/... सुनिश्चित करें कि आप नवीनतम InnoDB संस्करणों में सभी सुविधाओं का लाभ प्राप्त कर रहे हैं: mysqlperformanceblog.com/2011/01/07/...

— jynus

मुझे सामान्य धारणा थी कि कोई व्यक्ति छोटे चक में आयात करने से बचता है, बल्कि "सभी समावेशी" ऑपरेशन के लिए जाता है, लेकिन मुझे लगता है कि मल्टी-थ्रेडिंग कुछ संभावनाओं को खोल सकता है। लगता है कि बहुत विशिष्ट मामला है। हालाँकि, मैंने रोलांडो के उत्तर को इस ट्वीक (# # 7) के रूप में स्वीकार किया, जिससे मुझे <1 घंटे में पूर्ण आयात प्राप्त करने में मदद मिली, लेकिन आपकी सूची निश्चित रूप से बेकार है और मुझे लगता है कि यह संदर्भ के लिए बहुत जल्द उपयोग करेगा, क्योंकि हमारी DB दर बढ़ रही है मुझे डराता है :)

— nuala

मैं @yoshi से सहमत हूं। समस्या निवारण और प्रदर्शन में सुधार के संदर्भ में आपका उत्तर अधिक व्यापक है। +1

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

Answer 3

अधिकांश अच्छे सुझाव अब तक दिए गए हैं, लेकिन सर्वश्रेष्ठ लोगों के लिए बहुत सारे स्पष्टीकरण के बिना। मैं और जानकारी दूंगा।

सबसे पहले, इंडेक्स निर्माण में देरी करना एक अच्छा है, अन्य प्रतिक्रियाओं में पर्याप्त विवरण के साथ। मैं इस पर वापस नहीं आऊंगा।

एक बड़ी InnoDB लॉग फ़ाइल आपकी बहुत मदद करेगी (यदि आप MySQL 5.6 का उपयोग कर रहे हैं, क्योंकि इसे Myb 5.5 में बढ़ाना संभव नहीं है)। आप 7 जीबी डेटा डाल रहे हैं, मैं कम से कम 8 जीबी के कुल लॉग आकार ( innodb_log_files_in_groupइसके डिफ़ॉल्ट (2) पर रखें और innodb_log_file_size4 जीबी पर टक्कर) की सिफारिश करूंगा । यह 8 जीबी सटीक नहीं है: यह REDO लॉग में कम से कम आयात आकार में होना चाहिए और संभवतः उस आकार को दोगुना या चौगुना कर सकता है। InnoDB लॉग साइज के पीछे तर्क यह बढ़ाता है कि जब लॉग लगभग पूर्ण हो जाएगा, InnoDB भरने के लॉग से बचने के लिए डिस्क को आक्रामक रूप से अपने बफर पूल को फ्लश करना शुरू कर देगा (जब लॉग भरा हो, तो InnoDB कुछ तक कोई डेटाबेस नहीं कर सकता है बफ़र पूल के पृष्ठ डिस्क पर लिखे गए हैं)।

एक बड़ी InnoDB लॉग फ़ाइल आपकी मदद करेगी, लेकिन आपको प्राथमिक कुंजी क्रम में भी सम्मिलित होना चाहिए (डालने से पहले अपनी फ़ाइल को सॉर्ट करें)। यदि आप प्राथमिक कुंजी क्रम में सम्मिलित करते हैं, तो InnoDB एक पृष्ठ भर जाएगा, और फिर एक और एक, और इसी तरह। यदि आप प्राथमिक कुंजी क्रम में नहीं डालते हैं, तो आपका अगला सम्मिलित पृष्ठ पूर्ण हो सकता है और "पेज स्प्लिट" हो जाएगा। यह पृष्ठ विभाजन InnoDB के लिए महंगा होगा और आपके आयात को धीमा कर देगा।

आपके पास पहले से ही एक बफ़र पूल है जितना कि आपकी रैम आपको अनुमति देती है और यदि आपकी तालिका इसमें फिट नहीं होती है, तो बहुत कुछ नहीं है जो आप अधिक रैम खरीदने के अलावा कर सकते हैं। लेकिन यह आप तालिका बफर पूल में फिट बैठता है, लेकिन बड़ा है कि आपके बफर पूल का 75%, आप innodb_max_dirty_pages_pctआयात के दौरान 85 या 95 तक बढ़ने की कोशिश कर सकते हैं (डिफ़ॉल्ट मूल्य 75 है)। यह कॉन्फ़िगरेशन पैरामीटर InnoDB को बताता है कि जब आक्रामक पृष्ठ का प्रतिशत इस सीमा तक पहुँच जाता है, तो बफर पूल को आक्रामक रूप से प्रवाहित करना शुरू कर देता है। इस पैरामीटर को बढ़ाकर (और यदि आप डेटा आकार पर भाग्यशाली हैं), तो आप अपने आयात के दौरान आक्रामक IO से बच सकते हैं और बाद में उन IO को विलंबित कर सकते हैं।

शायद (यह एक अनुमान है) कई छोटे लेनदेन में आपके डेटा को आयात करने से आपको मदद मिलेगी। मुझे नहीं पता कि REDO लॉग कैसे बनाया जाता है, लेकिन अगर यह RAM में बफ़र किया जाता है (और जब बहुत अधिक RAM की आवश्यकता होगी), जबकि लेन-देन प्रगति कर रहा है, तो आप अनावश्यक IO के साथ समाप्त हो सकते हैं। आप इसे आज़मा सकते हैं: एक बार आपकी फ़ाइल को सॉर्ट करने के बाद, इसे कई हिस्सों में विभाजित करें (16 एमबी और अन्य आकारों के साथ प्रयास करें) और उन्हें एक के बाद एक आयात करें। इससे आप अपने आयात की प्रगति को नियंत्रित कर सकते हैं। यदि आप नहीं चाहते कि आपका डेटा आपके आयात करते समय अन्य पाठक को आंशिक रूप से दिखाई दे, तो आप एक अलग तालिका नाम का उपयोग करके आयात कर सकते हैं, बाद में अनुक्रमित बना सकते हैं, और फिर तालिका का नाम बदल सकते हैं।

आपके हाइब्रिड SSD / 5400RPM डिस्क के बारे में, मुझे नहीं पता कि इसके बारे में और इसे कैसे ऑप्टिमाइज़ करना है। 5400RPM डेटाबेस के लिए धीमा दिखता है, लेकिन शायद SSD इससे बच रहा है। हो सकता है कि आप अपनी डिस्क के SSD भाग को अनुक्रमिक राइट्स के साथ REDO लॉग में भर रहे हों और SSD प्रदर्शन को नुकसान पहुंचा रहा हो। मुझे नहीं पता।

एक बुरा सुझाव जिसे आपको कोशिश नहीं करनी चाहिए (या इसके साथ सावधान रहना चाहिए) निम्नलिखित है: कोई बहु-सूत्र का उपयोग न करें: इनोबीडी में पृष्ठ विभाजन से बचने के लिए इसे अनुकूलित करना बहुत कठिन होगा। यदि आप मल्टी-थ्रेड का उपयोग करना चाहते हैं, तो अलग-अलग टेबल (या एक ही टेबल के अलग-अलग विभाजन) में डालें।

यदि आप मल्टी-थ्रेड पर विचार कर रहे हैं, तो शायद आपके पास मल्टी सॉकेट (NUMA) कंप्यूटर हो। इस मामले में, सुनिश्चित करें कि आप MySQL स्वैप पागलपन समस्या से बचते हैं ।

यदि आप MySQL 5.5 का उपयोग कर रहे हैं, तो MySQL 5.6 में अपग्रेड करें: इसमें REDO लॉग साइज बढ़ाने का विकल्प है और बेहतर बफर पूल फ्लशिंग एल्गोरिदम है।

अपने आयात के साथ गुड लक।