हम अपने डेटाबेस में अद्यतन प्रदर्शन में कभी-कभी धीमी गति से अनुभव कर रहे हैं।MySQL/InnoDB कभी-कभी कुछ अद्यतन 'अद्यतन' स्थिति में बहुत धीमी गति से चलते हैं
उदाहरण के लिए, तालिका FooTable हमारे पास वर्चर्स पीके के साथ लगभग 40 कॉलम हैं, इसके अलावा 10 इंडेक्स हैं। निम्नलिखित क्वेरी में 44 सेकंड लग गए, जबकि दूसरी बार यह लगभग तुरंत चल रहा था। सर्वर पर लोड औसत धीमा होने के दौरान काफी कम है (5 मिनट औसत के लिए 1.5) और आईएमओ vmstat के अनुसार काफी उचित है।
यहाँ एक एक उदाहरण:
mysql> update FooTable set BarColumn=1349981286086 where varcharPK='e4348411-0fbb-460a-80f7-f1de304a9f7c'
Query OK, 1 row affected (44.94 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> show profile for QUERY 1;
+----------------------+-----------+
| Status | Duration |
+----------------------+-----------+
| starting | 0.000030 |
| checking permissions | 0.000004 |
| Opening tables | 0.000007 |
| System lock | 0.000003 |
| Table lock | 0.000003 |
| init | 0.000035 |
| Updating | 44.949727 |
| end | 0.000006 |
| query end | 0.000003 |
| freeing items | 0.000115 |
| logging slow query | 0.000002 |
| logging slow query | 0.000052 |
| cleaning up | 0.000003 |
+----------------------+-----------+
13 rows in set (0.02 sec)
क्या यह लायक है उदाहरण क्वेरी के ऊपर एक InnoDB तालिका था 'पुनर्निर्माण' (ALTER तालिका FooTable इंजन = InnoDB;) पर चलाया गया था के लिए एक सप्ताह पहले से कम। मुझे शुरुआत में संदेह था कि यह इनोर्डबी के वर्चर्स/गैर अनुक्रमिक पीके के साथ ज्ञात प्रदर्शन मुद्दों से संबंधित था, हालांकि हमारे पास अन्य सारणी हैं जो अनुक्रमिक पीके का उपयोग करती हैं और एक ही समस्या को देखते हैं। 2.6.18-238.19.1.el5 x86_64 MySQL/Percona स्मृति के 5.1.57-rel12.8-लॉग इन करें 96GB डेटा की 58.8G साथ 87 टेबल भर में फैले हुए Centos 5:
यह एक उत्पादन सर्वर पर है
प्रासंगिक InnoDB सेटिंग्स इस प्रकार हैं:
innodb_flush_log_at_trx_commit = 2
innodb_buffer_pool_size = 70G
innodb_log_file_size = 512M
innodb_log_buffer_size = 64M
innodb_file_per_table = 1
innodb_thread_concurrency = 0
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 64
innodb_write_io_threads = 64
optimizer_search_depth = 0
innodb_file_format = barracuda
मैं प्रारूप का उपयोग नहीं कर रहा हूँ = इस मेज पर संकुचित लेकिन मैं दूसरों पर कर रहा हूँ।
अद्यतन करने वाले चरण में क्या हो रहा है, इस बारे में कोई सुझाव है कि इतने लंबे समय तक क्या चल रहा है?
'अद्यतन' के साथ 'EXPLAIN' काम करता है? क्या आपको वही प्रदर्शन मिलता है जो 'चुनें बारकॉम से FooTable जहां varCharPK = ...'? मैं सोच रहा हूं कि यह इंडेक्स के साथ अजीब कुछ कर रहा है। –
आप अद्यतन पर एक व्याख्या नहीं चला सकते हैं, हालांकि यदि मैं इसे किसी चयन में रूपांतरित करता हूं, तो ऐसा लगता है कि यह मुख्य प्राथमिकता का उपयोग कर रहा है, पंक्तियां 1. – Jeremy
वह क्वेरी चल रही है, जबकि "शो प्रोसेसलिस्ट" करने का प्रयास करें। यह अन्य प्रश्न दिखा सकता है जिनके पास टेबल पर लॉक है। – bobwienholt