2016-01-26 10 views
10

से धीमा है मेरे पास एक क्वेरी है जो MySQL 5.1 सर्वर पर लगभग 20 सेकंड में चलती है लेकिन मारियाडीबी 5.5 सर्वर पर लगभग 15 मिनट लगती है। key_buffer_size और tmp_table_size और max_heap_table_size जैसे सामान्य संदिग्ध सभी बराबर (128 एम) हैं।मरियाडब 5.5 माइस्क्लुएल 5.1

SELECT products.id, 
concat(publications.company_name,' [',publications.quote,'] ', products.name) as n, 
products.impressions, 
products.contacts, 
is_channel, 
sl.i, 
count(*) 
FROM products 
LEFT JOIN publications ON products.publications_id = publications.id 
LEFT OUTER JOIN ( 
    SELECT adspace.id AS i, 
    slots.products_id FROM adspace 
    LEFT JOIN slots ON adspace.slots_id = slots.id 
     AND adspace.end > '2016-01-25 10:28:49' 
     WHERE adspace.active = 1) AS sl 
    ON sl.products_id = products.id 
WHERE 1 = 1 
AND publications.active=1 
GROUP BY products.id 
ORDER BY n ASC; 

फर्क सिर्फ इतना समझाने fase में है:

पुराने सर्वर (MySQL 5.1)

अधिकांश सेटिंग जहाँ तक बराबर मैं देख सकता हूँ (query_cache, आदि)

क्वेरी हैं

+----+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 
| id | select_type | table  | type | possible_keys | key  | key_len | ref          | rows | Extra       | 
+----+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 
| 1 | PRIMARY  | products  | ALL | NULL   | NULL | NULL | NULL         | 6568 | Using temporary; Using filesort | 
| 1 | PRIMARY  | publications | eq_ref | PRIMARY  | PRIMARY | 4  | db.products.publications_id |  1 | Using where         | 
| 1 | PRIMARY  | <derived2> | ALL | NULL   | NULL | NULL | NULL         | 94478 |         | 
| 2 | DERIVED  | adspace  | ALL | NULL   | NULL | NULL | NULL         | 101454 | Using where      | 
| 2 | DERIVED  | slots  | eq_ref | PRIMARY  | PRIMARY | 4  | db.adspace.slots_id   |  1 |            | 
+----+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 

नए सर्वर (MariaDB 5,5)

+------+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 
| id | select_type | table  | type | possible_keys | key  | key_len | ref          | rows | Extra       | 
+------+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 
| 1 | SIMPLE  | products  | ALL | test_idx  | NULL | NULL | NULL         | 6557 | Using temporary; Using filesort | 
| 1 | SIMPLE  | publications | eq_ref | PRIMARY  | PRIMARY | 4  | db.products.publications_id |  1 | Using where         | 
| 1 | SIMPLE  | adspace  | ALL | NULL   | NULL | NULL | NULL         | 100938 | Using where      | 
| 1 | SIMPLE  | slots  | eq_ref | PRIMARY  | PRIMARY | 4  | db.adspace.slots_id   |  1 | Using where         | 
+------+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 

चीजों को गति देने के लिए नए सर्वर पर उत्पाद तालिका में एक इंडेक्स जोड़ा गया था, इसका कोई फायदा नहीं हुआ।

इंजन चर:

पुराने सर्वर:

mysql> show variables like '%engine%'; 
+---------------------------+--------+ 
| Variable_name    | Value | 
+---------------------------+--------+ 
| engine_condition_pushdown | ON  | 
| storage_engine   | MyISAM | 
+---------------------------+--------+ 

mysql> show variables like '%buffer_pool%'; 
+-------------------------+---------+ 
| Variable_name   | Value | 
+-------------------------+---------+ 
| innodb_buffer_pool_size | 8388608 | 
+-------------------------+---------+ 

नए सर्वर:

MariaDB [db]> show variables like '%engine%'; 
+---------------------------+--------+ 
| Variable_name    | Value | 
+---------------------------+--------+ 
| default_storage_engine | InnoDB | 
| engine_condition_pushdown | OFF | 
| storage_engine   | InnoDB | 
+---------------------------+--------+ 


MariaDB [db]> show variables like '%buffer_pool%'; 
+---------------------------------------+-----------+ 
| Variable_name       | Value  | 
+---------------------------------------+-----------+ 
| innodb_blocking_buffer_pool_restore | OFF  | 
| innodb_buffer_pool_instances   | 1   | 
| innodb_buffer_pool_populate   | OFF  | 
| innodb_buffer_pool_restore_at_startup | 0   | 
| innodb_buffer_pool_shm_checksum  | ON  | 
| innodb_buffer_pool_shm_key   | 0   | 
| innodb_buffer_pool_size    | 134217728 | 
+---------------------------------------+-----------+ 

सभी क्वेरी में उपयोग टेबल MyISAM (दोनों पुराने और नए सर्वर) कर रहे हैं

प्रोफाइलिंग से पता चला है कि पुरानी क्वेरी 'टीएमपी टेबल की प्रतिलिपि' और नए एस में लगभग 16 सेकंड खर्च करती है इस फेज में 800 सेकंड के आसपास erver।

नए सर्वर में सभी के लिए एसएसडी डिस्क भंडारण के लिए है और पुराने सर्वरों में सामान्य डिस्क हैं।

संपादित करें: मेरे पास एक MySQL 5.5 सर्वर भी है और क्वेरी केवल 10 सेकंड लेती है। जहां तक ​​मैं देख सकता हूं सभी सेटिंग्स के साथ भी।

मैं एक तालिका में संक्षेप में प्रस्तुत करने की कोशिश की:

Location:  Customer     Own      Customer 
MySQL Type:  MySQL      MySQL     MariaDB 
Mysql Version: 5.1.56-community-log  5.5.39-1-log (Debian) 5.5.44-MariaDB-log 
HDD:   Normal      Normal     SSD 
Type:   Virtual      Real     Virtual 
Query time:  ~15s      ~10s     ~15min 
DB engine:  MyISAM      InnoDB     InnoDB 
Table Engine: MyISAM      MyISAM     MyISAM 

मैं क्वेरी पुनर्लेखन के लिए (हालांकि यह कुछ काम इस्तेमाल कर सकते हैं) नहीं करना चाहता, लेकिन मैं 2 मशीनों के बीच अंतर पता लगाना चाहते हैं, मेरे अनुमान एक सेटिंग है जो मारिया डीबी में आदर्श नहीं है लेकिन मुझे यह नहीं मिल रहा है।

+0

क्या आप वाकई दोनों डेटाबेस के लिए एक ही टेबल इंजन का उपयोग करते हैं? – Mjh

+0

शायद यह आपके प्रश्न का उत्तर देता है: पूरी तरह से अलग भंडारण इंजन ... – hendrik

+0

तो यदि मैं आपको सही समझता हूं, तो डेटाबेस स्तर पर इंजन भी अंतर करेगा यदि टेबल स्तर पर इंजन समान है? – darkownage

उत्तर

4

ऊपर दिए गए स्पष्टीकरण से देखा जा सकता है कि Derived Table Merge Optimization का उपयोग किया जाता है। दुर्भाग्यवश आपके मामले में इसका मतलब है कि adspace पर केवल एक पूर्ण तालिका स्कैन के बजाय कुछ ~ 6k किए जाते हैं।

set optimizer_switch='derived_merge=off'; जारी करके क्वेरी से पहले अनुकूलन को अक्षम करना एक संभावित समाधान है।एक पिछड़ा संगत वैकल्पिक रूप से उपशीर्षक में GROUP BY adspace.id, slots.products_id जोड़ देगा (यदि यह परिणाम नहीं बदलता है - सुरक्षित सभी शामिल तालिकाओं के पीके पर समूहित है) जो अलग-अलग अर्थशास्त्र के द्वारा विलय को रोकता है।

इस बारे में एक रिपोर्ट optimizer bug है - आपका मामला इसके साथ मदद कर सकता है।

+0

derived_merge = OFF की सेटिंग ने क्वेरी को ~ 15min से ~ 0.3seconds तक किया है। छोटी गति में वृद्धि :) – darkownage

+0

@darkownage - मैं आपकी टिप्पणी से उलझन में हूं - क्या यह एक महत्वपूर्ण _decrease_ था? या _increase_? –

+0

@ रिकजेम्स - अजीब वाक्य के लिए खेद है :) क्वेरी लगभग 15 मिनट से 0,5 सेकंड तक चली गई। तो गति में वृद्धि बहुत बड़ी थी। हमने इस 'ऑप्टिमाइज़ेशन' को बंद करने का विकल्प चुना क्योंकि यह अवरुद्ध हो रहा था और क्वेरी ने यह काम किया था और सबसे आसान फिक्स था। उम्मीद है कि यह आपके प्रश्न का उत्तर देगा :) – darkownage

1

यह उत्तर नहीं हो सकता है लेकिन मारियाडीबी 5.5 शामिल होने के लिए एक अलग एल्गोरिदम का उपयोग करता है। जहां तक ​​मुझे मारिया डीबी 5.5 Batch Key Access Join में बताया गया था। MySQL या MariaDB के पुराने संस्करण एक अलग का उपयोग करते हैं। हालांकि अधिकांश मामलों में नया संस्करण तेजी से होना चाहिए, हो सकता है कि आपकी विशिष्ट तालिकाएं पुराने का उपयोग करके बेहतर प्रदर्शन करें।

संपादित करें: यह उत्तर अजीब हो सकता है जैसा कि आपने बताया है कि आपने विभिन्न स्टोरेज इंजन का उपयोग किया था।