मैं वर्तमान में स्टैक ओवरफ्लो की टिप्पणियों के डेटा डंप के खिलाफ कुछ प्रश्नों को चलाने की कोशिश कर रहा हूं। यहाँ स्कीमा कैसा दिखता है:
CREATE TABLE `socomments` (
`Id` int(11) NOT NULL,
`PostId` int(11) NOT NULL,
`Score` int(11) DEFAULT NULL,
`Text` varchar(600) NOT NULL,
`CreationDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`UserId` int(11) NOT NULL,
PRIMARY KEY (`Id`),
KEY `idx_socomments_PostId` (`PostId`),
KEY `CreationDate` (`CreationDate`),
FULLTEXT KEY `Text` (`Text`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8मैंने इस क्वेरी को तालिका के विरुद्ध चलाया, और यह अविश्वसनीय रूप से धीमी गति से चली (इसमें 29 मिलियन पंक्तियाँ हैं, लेकिन इसमें एक पूर्ण-पाठ अनुक्रमणिका है):
SELECT *
FROM socomments
WHERE MATCH (Text) AGAINST ('"fixed the post"' IN BOOLEAN MODE)इसलिए मैंने इसे प्रोफाइल किया, जिसके परिणाम हैं:
|| Status || Duration ||
|| starting || 0.000058 ||
|| checking permissions || 0.000006 ||
|| Opening tables || 0.000014 ||
|| init || 0.000019 ||
|| System lock || 0.000006 ||
|| optimizing || 0.000007 ||
|| statistics || 0.000013 ||
|| preparing || 0.000005 ||
|| FULLTEXT initialization || 207.1112 ||
|| executing || 0.000009 ||
|| Sending data || 0.000856 ||
|| end || 0.000004 ||
|| query end || 0.000004 ||
|| closing tables || 0.000006 ||
|| freeing items || 0.000059 ||
|| logging slow query || 0.000037 ||
|| cleaning up || 0.000046 ||जैसा कि आप देख सकते हैं, यह फुलटेक्ट आरंभीकरण में एक लंबा समय बिताता है। क्या यह सामान्य है? यदि नहीं, तो मैं इसे कैसे ठीक करूँगा?
id_group 2औरid_group 23। इसके साथ आपकी मुख्य तालिका के अंदर आपकी खोज और आपकी क्वेरी को २.००० से २.९९ और २३.०० से २३.९९ तक सीमित कर देता है। निश्चित रूप से 2 के रूप में आवश्यकतानुसार अधिक परिणाम मिलेंगे क्योंकि आप नए कीवर्ड संयोजन बनाते हुए सभी टिप्पणियों को मिलाते हैं, लेकिन अंत में इसे पूरी चीज़ को गति देना चाहिए। बेशक यह डिस्क स्थान उपयोग को दोगुना करता है। नई टिप्पणियाँ जाना चाहिए CONCAT'ed समूह-मेज पर।