MySQL सिंगल टेबल में 10 मिलियन + पंक्तियों को कैसे अपडेट करें जितनी जल्दी हो सके?

32

अधिकांश तालिका के लिए InnoDB भंडारण इंजन के साथ MySQL 5.6 का उपयोग करना। InnoDB बफर पूल का आकार 15 GB है और Innodb DB + अनुक्रमित लगभग 10 GB हैं। सर्वर में 32GB रैम है और यह Cent OS 7 x64 चला रहा है।

मेरे पास एक बड़ी तालिका है जिसमें लगभग 10 लाखों + रिकॉर्ड हैं।

मुझे हर 24 घंटे में एक रिमोट सर्वर से अपडेट डंप फ़ाइल मिलती है। फ़ाइल सीएसवी प्रारूप में है। मेरा उस प्रारूप पर नियंत्रण नहीं है। फ़ाइल ~ 750 एमबी है। मैंने एक MyISAM तालिका पंक्ति में पंक्ति द्वारा डेटा डालने की कोशिश की और इसमें 35 मिनट लगे।

मुझे फ़ाइल से 10-12 में से प्रति पंक्ति केवल 3 मान लेने और डेटाबेस में इसे अपडेट करने की आवश्यकता है।

इस तरह से कुछ हासिल करने का सबसे अच्छा तरीका क्या है?

मुझे रोजाना ऐसा करने की जरूरत है।

वर्तमान में प्रवाह इस तरह है:

  1. mysqli_begin_transaction
  2. डंप फ़ाइल लाइन लाइन द्वारा पढ़ें
  3. लाइन द्वारा प्रत्येक रिकॉर्ड लाइन को अपडेट करें।
  4. mysqli_commit

ऊपर के संचालन को पूरा होने में लगभग 30-40 मिनट लगते हैं और इसे करते समय, अन्य अपडेट होते रहते हैं जो मुझे देता है

लॉक प्रतीक्षा समय समाप्त हो गया; लेनदेन को पुनः आरंभ करने का प्रयास करें

अपडेट १

उपयोग कर नई तालिका में डेटा लोड हो रहा है LOAD DATA LOCAL INFILE। MyISAM में इसे 38.93 secजबकि InnoDB में 7 मिनट 5.21 सेकंड लगे। फिर मैंने किया:

UPDATE table1 t1, table2 t2
SET 
t1.field1 = t2.field1,
t1.field2 = t2.field2,
t1.field3 = t2.field3
WHERE t1.field10 = t2.field10

Query OK, 434914 rows affected (22 hours 14 min 47.55 sec)

अपडेट २

ज्वाइन क्वेरी के साथ एक ही अपडेट

UPDATE table1 a JOIN table2 b 
ON a.field1 = b.field1 
SET 
a.field2 = b.field2,
a.field3 = b.field3,
a.field4 = b.field4

(14 hours 56 min 46.85 sec)

टिप्पणियों में प्रश्नों से स्पष्टीकरण:

  • तालिका में लगभग 6% पंक्तियों को फ़ाइल द्वारा अपडेट किया जाएगा, लेकिन कभी-कभी यह 25% तक हो सकती है।
  • अद्यतन किए जा रहे क्षेत्रों पर अनुक्रमणिकाएँ हैं। टेबल पर 12 इंडेक्स हैं, और 8 इंडेक्स में अपडेट फ़ील्ड शामिल हैं।
  • एक लेन-देन में अद्यतन करना आवश्यक नहीं है । इसमें समय लग सकता है लेकिन 24 घंटे से अधिक नहीं। मैं इसे पूरी तालिका को लॉक किए बिना 1 घंटे में प्राप्त करना चाहता हूं, क्योंकि बाद में मुझे स्फिंक्स इंडेक्स को अपडेट करना होगा जो इस तालिका पर निर्भर है। इससे कोई फर्क नहीं पड़ता कि चरण तब तक लंबी अवधि लेते हैं जब तक डेटाबेस अन्य कार्यों के लिए उपलब्ध है।
  • मैं प्रीप्रोसेस चरण में सीएसवी प्रारूप को संशोधित कर सकता हूं। केवल एक चीज जो मायने रखती है वह है त्वरित अपडेट और बिना लॉकिंग।
  • तालिका 2 MyISAM है। यह लोड डेटा इन्फाइल का उपयोग करके सीएसवी फ़ाइल से नव निर्मित तालिका है। MYI फ़ाइल का आकार 452 एमबी है। तालिका 2 को फ़ील्ड 1 कॉलम पर अनुक्रमित किया गया है।
  • MyISAM तालिका का MYD 663MB है।

अपडेट 3:

यहाँ दोनों तालिका के बारे में अधिक जानकारी दी गई है।

CREATE TABLE `content` (
  `hash` char(40) CHARACTER SET ascii NOT NULL DEFAULT '',
  `title` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `og_name` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `keywords` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `files_count` smallint(5) unsigned NOT NULL DEFAULT '0',
  `more_files` smallint(5) unsigned NOT NULL DEFAULT '0',
  `files` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
  `category` smallint(3) unsigned NOT NULL DEFAULT '600',
  `size` bigint(19) unsigned NOT NULL DEFAULT '0',
  `downloaders` int(11) NOT NULL DEFAULT '0',
  `completed` int(11) NOT NULL DEFAULT '0',
  `uploaders` int(11) NOT NULL DEFAULT '0',
  `creation_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `upload_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `last_updated` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `vote_up` int(11) unsigned NOT NULL DEFAULT '0',
  `vote_down` int(11) unsigned NOT NULL DEFAULT '0',
  `comments_count` int(11) NOT NULL DEFAULT '0',
  `imdb` int(8) unsigned NOT NULL DEFAULT '0',
  `video_sample` tinyint(1) NOT NULL DEFAULT '0',
  `video_quality` tinyint(2) NOT NULL DEFAULT '0',
  `audio_lang` varchar(127) CHARACTER SET ascii NOT NULL DEFAULT '',
  `subtitle_lang` varchar(127) CHARACTER SET ascii NOT NULL DEFAULT '',
  `verified` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `uploader` int(11) unsigned NOT NULL DEFAULT '0',
  `anonymous` tinyint(1) NOT NULL DEFAULT '0',
  `enabled` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `tfile_size` int(11) unsigned NOT NULL DEFAULT '0',
  `scrape_source` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `record_num` int(11) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`record_num`),
  UNIQUE KEY `hash` (`hash`),
  KEY `uploaders` (`uploaders`),
  KEY `tfile_size` (`tfile_size`),
  KEY `enabled_category_upload_date_verified_` (`enabled`,`category`,`upload_date`,`verified`),
  KEY `enabled_upload_date_verified_` (`enabled`,`upload_date`,`verified`),
  KEY `enabled_category_verified_` (`enabled`,`category`,`verified`),
  KEY `enabled_verified_` (`enabled`,`verified`),
  KEY `enabled_uploader_` (`enabled`,`uploader`),
  KEY `anonymous_uploader_` (`anonymous`,`uploader`),
  KEY `enabled_uploaders_upload_date_` (`enabled`,`uploaders`,`upload_date`),
  KEY `enabled_verified_category` (`enabled`,`verified`,`category`),
  KEY `verified_enabled_category` (`verified`,`enabled`,`category`)
) ENGINE=InnoDB AUTO_INCREMENT=7551163 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ROW_FORMAT=FIXED


CREATE TABLE `content_csv_dump_temp` (
  `hash` char(40) CHARACTER SET ascii NOT NULL DEFAULT '',
  `title` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `category_id` int(11) unsigned NOT NULL DEFAULT '0',
  `uploaders` int(11) unsigned NOT NULL DEFAULT '0',
  `downloaders` int(11) unsigned NOT NULL DEFAULT '0',
  `verified` tinyint(1) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`hash`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

और यहां अपडेट क्वेरी है जो contentडेटा का उपयोग करके तालिका अपडेट करती हैcontent_csv_dump_temp 

UPDATE content a JOIN content_csv_dump_temp b 
ON a.hash = b.hash 
SET 
a.uploaders = b.uploaders,
a.downloaders = b.downloaders,
a.verified = b.verified

अद्यतन 4:

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

mysql> UPDATE content_test a JOIN content_csv_dump_temp b
    -> ON a.hash = b.hash
    -> SET
    -> a.uploaders = b.uploaders,
    -> a.downloaders = b.downloaders,
    -> a.verified = b.verified;
Query OK, 2673528 rows affected (7 min 50.42 sec)
Rows matched: 7044818  Changed: 2673528  Warnings: 0

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

mysql  performance  mysql-5.6  update  myisam 
— AMB
स्रोत
क्या आपके पास एक समग्र INDEX(field2, field3, field4) (किसी भी क्रम में) है? कृपया हमें दिखाओ SHOW CREATE TABLE।
— रिक जेम्स
1
12 और 8 इंडेक्स आपकी समस्या का एक गंभीर हिस्सा है। MyISAM एक और गंभीर हिस्सा है। InnoDB या TokuDB कई अनुक्रमित के साथ बेहतर प्रदर्शन करते हैं।
— रिक जेम्स
आपके पास दो अलग-अलग हैं UPDATEs । कृपया हमें बताएं कि वास्तव में क्या सीधा बयान दिखता csv डेटा से तालिका अद्यतन करने के लिए पसंद करते हैं। फिर हम आपकी आवश्यकताओं को पूरा करने वाली तकनीक को तैयार करने में आपकी सहायता करने में सक्षम हो सकते हैं।
— रिक जेम्स
@RickJames केवल एक ही है update, और कृपया अद्यतन प्रश्न की जाँच करें। धन्यवाद
— AMB

जवाबों:

17

अपने अनुभव के आधार पर, मैं आपकी CSV फ़ाइल को आयात करने के लिए LOAD DATA INFILE का उपयोग करूंगा ।

LOAD DATA INFILE बयान एक पाठ फ़ाइल से एक बहुत ही उच्च गति पर एक तालिका में पंक्तियों को पढ़ता है।

उदाहरण मुझे इंटरनेट लोड डेटा उदाहरण पर मिला । मैंने अपने बॉक्स पर इस उदाहरण का परीक्षण किया और ठीक काम किया

उदाहरण तालिका

CREATE TABLE example (
  `Id` int(11) NOT NULL AUTO_INCREMENT,
  `Column2` varchar(14) NOT NULL,
  `Column3` varchar(14) NOT NULL,
  `Column4` varchar(14) NOT NULL,
  `Column5` DATE NOT NULL,
  PRIMARY KEY (`Id`)
) ENGINE=InnoDB

उदाहरण CSV फ़ाइल

# more /tmp/example.csv
Column1,Column2,Column3,Column4,Column5
1,A,Foo,sdsdsd,4/13/2013
2,B,Bar,sdsa,4/12/2013
3,C,Foo,wewqe,3/12/2013
4,D,Bar,asdsad,2/1/2013
5,E,FOObar,wewqe,5/1/2013

आयात कथन MySQL कंसोल से चलाया जाएगा

LOAD DATA LOCAL INFILE '/tmp/example.csv'
    -> INTO TABLE example
    -> FIELDS TERMINATED BY ','
    -> LINES TERMINATED BY '\n'
    -> IGNORE 1 LINES
    -> (id, Column3,Column4, @Column5)
    -> set
    -> Column5 = str_to_date(@Column5, '%m/%d/%Y');

परिणाम

MySQL [testcsv]> select * from example;
+----+---------+---------+---------+------------+
| Id | Column2 | Column3 | Column4 | Column5    |
+----+---------+---------+---------+------------+
|  1 |         | Column2 | Column3 | 0000-00-00 |
|  2 |         | B       | Bar     | 0000-00-00 |
|  3 |         | C       | Foo     | 0000-00-00 |
|  4 |         | D       | Bar     | 0000-00-00 |
|  5 |         | E       | FOObar  | 0000-00-00 |
+----+---------+---------+---------+------------+

IGNORE बस पहली पंक्ति को अनदेखा करता है जो कॉलम हेडर हैं।

IGNORE के बाद, हम आयात करने के लिए कॉलम (स्किपिंग कॉलम 2) को निर्दिष्ट कर रहे हैं, जो आपके प्रश्न में एक मापदंड से मेल खाता है।

यहाँ Oracle से सीधे एक और उदाहरण है: LOAD DATA INFILE उदाहरण

यह आपको शुरू करने के लिए पर्याप्त होना चाहिए।

— क्रेग एफ्रेइन
स्रोत
मैं अस्थायी तालिका में डेटा लोड करने के लिए लोड डेटा का उपयोग कर सकता हूं और फिर इसे मुख्य तालिका में अपडेट करने के लिए अन्य प्रश्नों का उपयोग कर सकता हूं। धन्यवाद
— AMB
14

उल्लिखित सभी चीजों के प्रकाश में, ऐसा लग रहा है कि टोंटी खुद में शामिल है।

ASPECT # 1: बफर आकार में शामिल हों

सभी संभावना में, आपका join_buffer_size संभवतः बहुत कम है।

MySQL डॉक्यूमेंटेशन के अनुसार कैसे MySQL जॉइन बफ़र कैश का उपयोग करता है

हम केवल उपयोग किए गए कॉलम को ही बफर में स्टोर करते हैं, न कि पूरी पंक्तियों में।

यह मामला होने के नाते, रैम में शामिल होने वाले बफर रहने की कुंजी बनाएं।

आपके पास प्रत्येक कुंजी के लिए 10 मिलियन पंक्तियाँ 4 बाइट्स हैं। जो कि लगभग 40 मी।

42M (40M से थोड़ा बड़ा) सत्र में इसे उछालने की कोशिश करें

SET join_buffer_size = 1024 * 1024 * 42;
UPDATE table1 a JOIN table2 b 
ON a.field1 = b.field1 
SET 
a.field2 = b.field2,
a.field3 = b.field3,
a.field4 = b.field4;

यदि यह चाल है, तो इसे जोड़ने के लिए आगे बढ़ें my.cnf

[mysqld]
join_buffer_size = 42M

नए कनेक्शन के लिए mysqld की आवश्यकता नहीं है। बस दौडो

mysql> SET GLOBAL join_buffer_size = 1024 * 1024 * 42;

ASPECT # 2: ऑपरेशन में शामिल हों

आप ऑप्टिमाइज़र को ट्विक करके ज्वाइन ऑपरेशन की शैली में फेरबदल कर सकते हैं

MySQL प्रलेखन के अनुसार ब्लॉक नेस्टेड-लूप और बैचेड कुंजी एक्सेस जॉइन पर

जब BKA का उपयोग किया जाता है, तो join_buffer_size का मान परिभाषित करता है कि स्टोरेज इंजन के लिए प्रत्येक अनुरोध में कुंजी का बैच कितना बड़ा है। बड़ा बफर, अधिक अनुक्रमिक पहुंच एक ऑपरेशन में शामिल होने के दाहिने हाथ की मेज पर होगा, जो प्रदर्शन में काफी सुधार कर सकता है।

BKA का उपयोग करने के लिए, optimizer_switch सिस्टम वैरिएबल के बैचेड_की_केस फ्लैग को सेट किया जाना चाहिए। बीकेआर एमआरआर का उपयोग करता है, इसलिए श्री ध्वज भी होना चाहिए। वर्तमान में, MRR के लिए लागत अनुमान बहुत निराशावादी है। इसलिए, यह भी आवश्यक है कि mrr_cost_based के लिए BKA का उपयोग किया जाए।

यह वही पृष्ठ ऐसा करने की अनुशंसा करता है:

mysql> SET optimizer_switch='mrr=on,mrr_cost_based=off,batched_key_access=on';

ASPECT # 3: डिस्क पर अद्यतन लेखन (वैकल्पिक)

अधिकांश तेजी से बफर पूल से बाहर गंदे पृष्ठों को लिखने के लिए innodb_write_io_threads बढ़ाने के लिए भूल जाते हैं ।

[mysqld]
innodb_write_io_threads = 16

इस परिवर्तन के लिए आपको MySQL पुनः आरंभ करना होगा

कोशिश तो करो !!!

— RolandoMySQLDBA
स्रोत
अच्छा! ट्यून करने योग्य ज्वाइन बफर टिप के लिए +1। यदि आप सम्मिलित हों, तो स्मृति में सम्मिलित हों। अच्छा सुझाव!
— पीटर डिक्सन-मूसा
3
  1. CREATE TABLE जो CSV से मेल खाता है
  2. LOAD DATA उस तालिका में
  3. UPDATE real_table JOIN csv_table ON ... SET ..., ..., ...;
  4. DROP TABLE csv_table;

पंक्ति-दर-पंक्ति से चरण 3 बहुत तेज होगा, लेकिन यह अभी भी गैर-तुच्छ राशि के लिए तालिका में सभी पंक्तियों को लॉक करेगा। यदि इस लॉक का समय अधिक महत्वपूर्ण है तो पूरी प्रक्रिया में कितना समय लगता है, ...

अगर मेज पर और कुछ नहीं लिख रहा है, तो ...

  1. CREATE TABLEजो CSV से मेल खाता है; कोई अनुक्रमणिका सिवाय क्या की जरूरत है JOINमें UPDATE। यदि अद्वितीय है, तो इसे बनाएं PRIMARY KEY।
  2. LOAD DATA उस तालिका में
  3. ( ) real_tableको कॉपी करेंnew_tableCREATE ... SELECT
  4. UPDATE new_table JOIN csv_table ON ... SET ..., ..., ...;
  5. RENAME TABLE real_table TO old, new_table TO real_table;
  6. DROP TABLE csv_table, old;

चरण 3 अपडेट से तेज है, खासकर अगर अनावश्यक अनुक्रमित छोड़ दिए जाते हैं।
चरण 5 "तात्कालिक" है।

— रिक जेम्स
स्रोत
सेकंड उदाहरण में कहते हैं, चरण 3 के बाद, हम चरण 4 कर रहे हैं, तो नया डेटा real_table में सम्मिलित हो जाता है इसलिए हम उस डेटा को new_table में याद करेंगे? इसके लिए वर्कअराउंड क्या है? धन्यवाद
— AMB
देखें क्या pt-online-schema-digest; यह एक के माध्यम से इस तरह के मुद्दों का ख्याल रखता है TRIGGER।
— रिक जेम्स
आपको संभवतः तालिका से किसी भी अनुक्रमित की आवश्यकता नहीं है LOAD DATA। अनावश्यक अनुक्रमित जोड़ना महंगा है (समय में)।
— रिक जेम्स
नवीनतम जानकारी के आधार पर, मैं CSV फ़ाइल की ओर झुकाव कर रहा हूं, जिसमें केवल एक के साथ एक MyISAM तालिका में लोड किया जा रहा है AUTO_INCREMENT, फिर PK के आधार पर एक समय में 1K पंक्तियों को चून रहा है। लेकिन मुझे विवरणों को समझने की कोशिश करने से पहले सभी आवश्यकताओं और तालिका स्कीमा को देखना होगा ।
— रिक जेम्स
मैंने हैश के रूप में सेट किया है PRIMARY index, लेकिन ऑर्डर क्वेरी का उपयोग करते हुए 50k में चैंकिंग करने में अधिक समय लगता है। क्या यह बेहतर होगा कि मैं ऑटो वेतन वृद्धि करूं? और इसे सेट करें PRIMARY index?
— AMB
3

आपने कहा है:

  • अपडेट आपकी तालिका का 6-25% प्रभावित करते हैं
  • आप इसे जितनी जल्दी हो सके करना चाहते हैं (<1hr)
  • बिना ताला लगाए
  • यह एक ही लेनदेन में नहीं होना चाहिए
  • अभी तक (रिक जेम्स जवाब पर टिप्पणी में), आप दौड़ की स्थिति के बारे में चिंता व्यक्त करते हैं

इनमें से कई कथन विरोधाभासी हो सकते हैं। उदाहरण के लिए, बड़े अपडेट w / o तालिका को लॉक कर रहे हैं। या एक विशाल लेनदेन का उपयोग करते हुए दौड़ की स्थिति w / o से बचें।

इसके अलावा, चूंकि आपकी तालिका बहुत अनुक्रमित है, आवेषण और अपडेट दोनों धीमा हो सकते हैं।

दौड़ की स्थिति से बचना

यदि आप अपनी तालिका में एक अपडेट किए गए टाइम स्टैम्प को जोड़ने में सक्षम हैं , तो आप एकल लेन-देन में आधा मिलियन अपडेट लॉग करने से बचने के साथ ही दौड़ की स्थिति के लिए हल कर सकते हैं।

यह आपको लाइन-बाय-लाइन अपडेट (जैसा कि आप वर्तमान में करते हैं) करने के लिए मुक्त करता है, लेकिन ऑटोकॉमिट या अधिक उचित लेनदेन बैचों के साथ।

आप दौड़ की स्थिति (लाइन-बाय-लाइन को अपडेट करते समय) से बचने के लिए जाँच कर सकते हैं कि बाद में अपडेट पहले ही नहीं हुआ है ( UPDATE ... WHERE pk = [pk] AND updated < [batchfile date])

और, महत्वपूर्ण बात, यह आपको समानांतर अपडेट चलाने की सुविधा देता है ।

जितना संभव हो उतनी तेजी से चल रहा है-समानांतर हो रहा है

इस समय के साथ अब स्टैंप की जाँच करें:

  1. अपनी बैच फ़ाइल को कुछ उचित आकार के टुकड़ों में विभाजित करें (50,000 पंक्तियाँ / फ़ाइल कहें)
  2. समानांतर में, प्रत्येक फ़ाइल में एक स्क्रिप्ट पढ़ी जाती है और 50,000 अपडेट स्टेटमेंट्स के साथ एक फ़ाइल आउटपुट होती है।
  3. समानांतर में, एक बार (2) खत्म होने पर, mysqlप्रत्येक sql फ़ाइल को चलाएं।

(उदा । समानांतर रूप से कमांड को चलाने के तरीकों को आसानी से bashदेखने के लिए splitऔर xargs -Pसमानांतर में डिग्री। समानता की डिग्री इस बात पर निर्भर करती है कि आप कितने थ्रेड्स अपडेट के लिए समर्पित करने के लिए तैयार हैं )

— पीटर डिक्सन-मूसा
स्रोत
ध्यान रखें कि "लाइन-बाय-लाइन" कम से कम 100 के बैचों में काम करने की तुलना में 10x धीमा होने की संभावना है।
— रिक जेम्स
यह सुनिश्चित करने के लिए आपको इस मामले में बेंचमार्क करना होगा। तालिका के 6-25% (अद्यतन स्तंभों के साथ शामिल 8 अनुक्रमित) के साथ, मैं इस संभावना का मनोरंजन करूंगा कि सूचकांक रखरखाव अड़चन बन जाता है।
— पीटर डिक्सन-मूसा
मेरा मतलब है, कुछ मामलों में सूचकांकों को छोड़ना, थोक अपडेट करना और उसके बाद उन्हें फिर से बनाना तेज हो सकता है ... लेकिन ओपी डाउनटाइम नहीं चाहता है।
— पीटर डिक्सन-मूसा
1

बड़े अपडेट I / O बाध्य हैं। मै सुझाव दूंगा:

  1. एक अलग तालिका बनाएं जो आपके 3 अक्सर अद्यतन किए गए फ़ील्ड को संग्रहीत करेगा। आइए एक टेबल एसेट्स_स्टैटिक को कॉल करें जहां आप रखते हैं, अच्छी तरह से, स्टैटिक डेटा, और दूसरे एसेट्स_डायनामिक जो अपलोडर्स , डाउनलोडर्स और वैरिफाइड करेंगे।
  2. यदि आप कर सकते हैं, तो आस्तियों के लिए MEMORY इंजन का उपयोग करें । (प्रत्येक अद्यतन के बाद डिस्क पर बैकअप)।
  3. अपने अपडेट 4 के अनुसार अपनी हल्की और फुर्तीली आस्तियों_आदमी को अपडेट करें (यानी लोड करें ... INTO temp; UPDATE आस्तियों_ dynamic a.id = b.id SET [a अपडेट पर बी] पर एक अस्थायी अस्थायी बी। यह कम से कम लेना चाहिए। मिनट। (हमारे सिस्टम पर, संपत्ति_डायनामिक में 95M पंक्तियां हैं और अद्यतन प्रभाव ~ 6M पंक्तियों, कुछ हद तक अधिक से अधिक है।)
  4. जब आप Sphinx का इंडेक्स चलाते हैं, तो JOIN संपत्तियां_स्टैटिक और एसेट्स_डायनामिक (यह मानते हुए कि आप इनमें से किसी एक फ़ील्ड को एक विशेषता के रूप में उपयोग करना चाहते हैं)।
— user3127882
स्रोत
0

UPDATEतेजी से दौड़ने के लिए, आपको जरूरत है

INDEX(uploaders, downloaders, verified)

यह या तो टेबल पर हो सकता है। तीनों क्षेत्र किसी भी क्रम में हो सकते हैं।

यह UPDATEदो तालिकाओं के बीच की पंक्तियों को जल्दी से मिलाने में सक्षम होने की सुविधा प्रदान करेगा ।

और दो टेबल (दोनों INT SIGNEDया दोनों INT UNSIGNED) में डेटाटाइप्स समान करें ।

— रिक जेम्स
स्रोत
यह वास्तव में अद्यतन धीमा कर दिया।
— एएमबी
हममम ... कृपया प्रदान करें EXPLAIN UPDATE ...;।
— रिक जेम्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.