2012-03-16 14 views
5

मेरे पास 17 मिलियन पंक्तियों वाली एक तालिका है। मुझे उस तालिका के 1 कॉलम को पकड़ने और इसे सभी को किसी अन्य तालिका में डालने की आवश्यकता है। यहाँ मैं क्या किया है:mysql innodb बनाम myisam प्रविष्टियां

INSERT IGNORE INTO table1(name) SELECT name FROM main WHERE ID < 500001 

InnoDB 3 मिनट और 45 सेकंड

हालांकि, MyISAM 4 बस नीचे सेकंड में कार्यान्वित आसपास में निष्पादित करता है। अंतर क्यों?

मैं हर कोई इनो डीबी की प्रशंसा करता हूं लेकिन ईमानदारी से मैं नहीं देखता कि यह मेरे लिए बेहतर कैसे है। यह बहुत धीमा है। मैं समझता हूं कि यह अखंडता और क्या नहीं है, लेकिन मेरी कई टेबल अपडेट नहीं की जाएंगी (बस पढ़ें)। क्या मुझे इनो डीबी से भी परेशान होना चाहिए?

+0

मैं केवल InnoDB का उपयोग जब मैं संबंधपरक टेबल के साथ काम कर रहा हूँ। अन्यथा, यदि आपके पास कोई विदेशी कुंजी नहीं है, तो MyISAM मुझे पसंद है! –

+0

बस इंगित करने के लिए, दोनों टेबल पर एक सूचकांक है। "मुख्य" तालिका वर्तमान में myisam है। – nick

+0

बेन, मैं रिलेशनल टेबल का उपयोग करना चाहता हूं लेकिन मैं संभवतः सैकड़ों लाखों पंक्तियों से निपट रहा हूं - मुझे दर्जनों कॉलम भी इंडेक्स करने की ज़रूरत है, इसलिए मुझे नहीं पता कि कौन सी दिशा जाना है। अखंडता एक मुद्दा नहीं है। कम से कम इस भाग के लिए नहीं। – nick

उत्तर

12

अंतर innDDB की कॉन्फ़िगरेशन के कारण सबसे अधिक संभावना है, जो MyISAM से थोड़ा अधिक tweaking लेता है। InnoDB का विचार है कि आपका अधिकांश डेटा मेमोरी में रखें, और डिस्क पर फ्लशिंग/रीडिंग केवल तभी हो जब आपके पास कुछ अतिरिक्त सीपीयू चक्र हों।

क्या आपको इनो डीबी के साथ भी परेशान होना चाहिए वास्तव में एक अच्छा सवाल है। यदि आप MySQL का उपयोग जारी रखने जा रहे हैं, तो अत्यधिक अनुशंसा की जाती है कि आपको InnoDB के साथ कुछ अनुभव प्राप्त हो। लेकिन यदि आप किसी डेटाबेस के लिए त्वरित और गंदे नौकरी कर रहे हैं जो बहुत अधिक ट्रैफिक नहीं देखेगा और स्केल के बारे में चिंतित नहीं होगा, तो माईसाम की आसानी सिर्फ आपके लिए जीत हो सकती है। InnoDB कई मामलों में अधिक हो सकता है जहां कोई बस एक साधारण डेटाबेस चाहता है।

लेकिन मेरे टेबल के कई

अपडेट नहीं किया जाएगा अगर आप 99% पढ़ने कर रहे हैं तुम अब भी InnoDB से एक प्रदर्शन लिफ्ट मिल सकती है। यदि आप अपने पूरे डेटाबेस को स्मृति में रखने के लिए अपने बफर पूल आकार को कॉन्फ़िगर करते हैं, तो इनओडीबी को आपके डेटा को प्राप्त करने के लिए डिस्क पर कभी भी जाना होगा, भले ही यह mysql क्वेरी कैश को याद न करे। माईसाम में, डिस्क से पंक्ति को पढ़ने के लिए आपको एक अच्छा मौका है, और आप ऑपरेटिंग सिस्टम को आपके लिए कैशिंग और ऑप्टिमाइज़ेशन करने के लिए छोड़ रहे हैं।

InnoDB-बफर-पूल आकार

मेरा पहला अनुमान बॉक्स 8M करने के लिए सेट से बाहर innodb_buffer_pool_size जो जहाजों की जांच करने के लिए है। यह आपकी कुल स्मृति का लगभग 80% होने की अनुशंसा की जाती है। एक बार जब आप उस सीमा तक नहीं पहुंच, InnoDB प्रदर्शन में काफी क्योंकि यह नए डेटा है, जो महंगा हो सकता है के लिए जगह बनाने के लिए बफर के बाहर कुछ फ्लश करने के लिए की जरूरत है

autocommit = 0
इसके अलावा, सुनिश्चित autocommit है छोड़ देंगे जब आप अपनी मेज लोड करते हैं तो बंद हो जाता है, या हर डालने पर फ्लशिंग होती है। पूरा होने के बाद आप इसे वापस चालू कर सकते हैं, और यह क्लाइंट-साइड सेटिंग है। बहुत सुरक्षित। एक बार
के बारे में यदि आप वास्तव में समायोजित करने के लिए "17million अमरीकी पंक्तियों डालने" अपने डेटाबेस धुन करना चाहते हैं के बारे में सोचो

लोड हो रहा है टेबल आम तौर पर होता है। आप यह कितनी बार करते हैं? MyISAM इस उदाहरण में तेज़ी से हो सकता है, लेकिन जब आपके पास 100 समवर्ती कनेक्शन होते हैं, तो सभी एक ही समय में इस तालिका को पढ़ और संशोधित करते हैं, तो आपको एक अच्छी तरह से ट्यून किया गया innoDB जीत जाएगा और माईसाम टेबल लॉक पर चकित होगा।

कैसे MyISAM इस आपरेशन देखता
MyISAM, किसी भी ट्यूनिंग के बिना इस पर बहुत अच्छा होगा, क्योंकि कवर के तहत, आप बस प्रत्येक पंक्ति एक फाइल करने के लिए जोड़ रहे हैं (और एक सूचकांक को अद्यतन करना)। आपका ओएस और डिस्क कैशिंग उन सभी प्रदर्शन समस्याओं को संभालेगा।

कैसे InnoDB इस आपरेशन
InnoDB तालिका पता चल जाएगा एक लिखने की जरूरत को देखता है, तो यह डालने बफर में पंक्ति फेंकता है। आप इसे अगले सम्मिलन से पहले कोई समय नहीं देते हैं, इसलिए innoDB में बफर से निपटने का कोई समय नहीं है, यह कमरे से बाहर चला जाता है और इसे बफर पूल और अपडेट इंडेक्स को लिखते समय सम्मिलित करने के लिए मजबूर किया जाता है। अगला, आपका बफर पूल भर जाता है, और innoDB को सम्मिलित करने के लिए मजबूर होना पड़ता है और कुछ पेज को बफर पूल से डिस्क पर फ़्लश कर देता है। और आप पागल की तरह इस पर आवेषण फेंकते रहते हैं। ध्यान दें कि जब आप ऐसा करने के बाद आपको एक MySQL> प्रॉम्प्ट देने के लिए इनो डीबी ट्यून करते हैं, तो इनओडीबी अभी भी अपने खाली समय में पकड़ने के लिए कवर के नीचे scrambling होगा, लेकिन आप के लिए एक नया लेनदेन निष्पादित करने के लिए तैयार हो जाएगा।

अवश्य पढ़ें:
http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
http://dev.mysql.com/doc/refman/5.0/en/innodb-tuning.html (थोक डेटा लोड हो रहा है युक्तियाँ देखें)

+0

कृपया, अगर कोई गलत हो गया है या कुछ भी छोड़ दिया गया है, तो कृपया मेरे किसी भी MySQL प्रदर्शन विशेषज्ञों (विशेष रूप से पेर्कोना से) मुझे सही करने के लिए स्वागत है। मैं जवाब अपडेट कर दूंगा। – FlipMcF

+0

"innodb-buffer-pool-size पर एक सीमा को मारने" के साथ थोड़ा सा गलत है फ्लशिंग वास्तव में "innodb_max_dirty_pages_pct" को मारने से संबंधित है। लेकिन यह इस सवाल के लिए अलग-अलग बाल है, मुझे लगता है। – FlipMcF

+0

आपके लिए भी एक अच्छा पठन: http://www.mysqlperformanceblog.com/2007/05/24/predicting-how-long-data-load-would-take/ – FlipMcF

1

आप कह रहे हैं सही तक कुछ का विस्तार। InnoDB MyISAM से धीमा है लेकिन किस मामले में? सबकुछ हर किसी की आवश्यकताओं को पूरा करने के लिए नहीं किया जाता है। आईएनएनओडीबी एक लेनदेन डेटाबेस इंजन है जबकि माईसाम नहीं है। इसलिए इसे एसीआईडी ​​अनुपालन और लेनदेन जागरूक स्टोरेज इंजन बनाने के लिए, हमें प्रतिक्रिया समय के मामले में अपनी लागत का भुगतान करना होगा।

और भी अधिक InnoDB तेज़ी से चलता है अगर यह my.ini या अन्य कॉन्फ़िगरेशन फ़ाइल का उपयोग करके ठीक से ट्यून किया जाता है।

अंत मैं निम्नलिखित कारणों क्यों लोग InnoDB की प्रशंसा कर रहे हैं समझने के लिए कर रहा हूँ में:

  1. यह एसिड अनुरूप और लेन-देन समर्थित इंजन
  2. यह पंक्ति-स्तर लॉकिंग लेने है, जबकि एक मेज, जबकि MyISAM पर काम कर ले तालिका स्तर के ताले
  3. InnoDB अत्यधिक मल्टी कोर/बहु प्रक्रिया मशीनों के लिए tunable संगामिति सुधार करने के लिए

अंतिम लेकिन कम से कम टिप्पणी है मेरी पक्ष; कुछ भी "हर किसी की" जरूरतों को पूरा कर सकता है, इसलिए यह पूरी तरह से निर्भर करता है कि आप किस परिदृश्य में दोनों इंजनों की तुलना कर रहे हैं।