मुझे नहीं पता कि आप अपने पिछले और वर्तमान इंस्टॉलेशन में क्या अंतर देख रहे हैं लेकिन सर्वर का व्यवहार समझ में आता है।
SELECT test_events.create_time FROM test_events LEFT JOIN test_event_types ON ( test_events.event = test_event_types.id ) ORDER BY test_events.create_time DESC LIMIT 1;
इस क्वेरी में आपके पास एक क्लॉज नहीं है लेकिन आप केवल एक पंक्ति ला रहे हैं। और वह create_time . द्वारा क्रमबद्ध करने के बाद है जो होता है एक index. और उस अनुक्रमणिका का उपयोग छँटाई के लिए किया जा सकता है। लेकिन चलिए दूसरी क्वेरी देखते हैं।
SELECT test_events.create_time FROM test_events LEFT JOIN test_event_types ON ( test_events.event = test_event_types.id ) WHERE base = 314 ORDER BY test_events.create_time DESC LIMIT 1
आपके पास आधार स्तंभ पर कोई अनुक्रमणिका नहीं है। तो उस पर किसी इंडेक्स का इस्तेमाल नहीं किया जा सकता है। रिलेवेंट रिकॉर्ड खोजने के लिए mysql को एक टेबल स्कैन करना होगा। प्रासंगिक पंक्तियों की पहचान करने के बाद, उन्हें क्रमबद्ध करने की आवश्यकता है। लेकिन इस मामले में क्वेरी प्लानर ने फैसला किया है कि create_time पर इंडेक्स का उपयोग करना इसके लायक नहीं है
मुझे आपके सेटअप के साथ कई समस्याएं दिखाई दे रही हैं, पहली नहीं होने और base . पर अनुक्रमणिका जैसा कि पहले ही उल्लेख किया। लेकिन बेस वर्चर क्यों है? ऐसा लगता है कि आप इसमें पूर्णांक संग्रहित कर रहे हैं।
ALTER TABLE test_events
ADD PRIMARY KEY (id),
ADD KEY client (client),
ADD KEY event_time (event_time),
ADD KEY manager (manager),
ADD KEY base_id (base_id),
ADD KEY create_time (create_time);
और इस तरह से कई इंडेक्स बनाना MySQL में ज्यादा मायने नहीं रखता है। ऐसा इसलिए है क्योंकि mysql प्रश्नों के लिए प्रति तालिका केवल एक अनुक्रमणिका का उपयोग कर सकता है। आप एक या दो इंडेक्स के साथ कहीं बेहतर होंगे। संभवतः बहु स्तंभ अनुक्रमणिका।
मुझे लगता है कि आपकी आदर्श अनुक्रमणिका में create_time और ईवेंट फ़ील्ड दोनों शामिल होंगे
