MIN (DATE) कब है? = MIN (DATE)?

मेरे दोस्त ग्रेग यांगबालाड ने मुझे इस पोस्ट को लिखने के लिए प्रेरित किया। उन्होंने पिछले हफ्ते MySQL में मुझे एक दिलचस्प पहेली दिखाई।

उनके पास पेरकोना सर्वर 5.5.21 था जो लगभग निम्नलिखित तालिका संरचना के साथ चल रहा था:

CREATE TABLE foo ( id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, uid INT UNSIGNED NOT NULL, update_time DATETIME NOT NULL, .... INDEX `uid` (uid, update_time), INDEX `bar` (some_other_columns) .... ) ENGINE=InnoDB; 

जब उसने निम्नलिखित प्रश्न निष्पादित किया:

 SELECT MIN(update_time) FROM foo WHERE update_time IS NOT NULL AND update_time <> '0000-00-00 00:00:00'; 

परिणाम 2012-06-22 10:28:16 पर लौटा। हालाँकि, जब उसने कुछ अलग अनुरोध किया:

 SELECT MIN(t.update_time) FROM (SELECT uid, MIN(update_time) AS "update_time" FROM foo WHERE update_time IS NOT NULL AND update_time <> '0000-00-00 00:00:00' GROUP BY 1) t; 

जो जवाब वापस आया वह पूरी तरह से अलग था: 2011-08-22 11:27:27। यह सही उत्तर है, तिथि 2012 से नहीं है। हम कारण की गणना करने के बारे में कई विचारों के साथ आए थे, और एक सुझाव था कि एक अलग सूचकांक का उपयोग करने के लिए MySQL प्राप्त किया जाए। हमारे आश्चर्य की कल्पना करें जब हमने बार या IGNORE INDEX (बच्चे) पर INDEX की कोशिश की और पूरी तरह से अलग जवाब मिला: 2012-06-21 20:36:35।
इसलिए, जब हमने "स्पष्ट" विकल्प की कोशिश की:

 SELECT update_time FROM foo ORDER BY update_time ORDER BY update_time LIMIT 3; 

और नतीजा?

 0024-06-22 01:34:25 2011-08-22 11:27:27 2011-08-23 11:31:40 

अहा! घुमावदार डेटा! हमने मान लिया कि MIN () फ़ंक्शन ने unix_timestamp / पूर्णांक या ctime में किसी प्रकार का रूपांतरण किया; और वास्तव में, SELECT MIN (UNIX_TIMESTAMP (update_time)) को निष्पादित करना ...। पहले अद्यतन_टाइम फ़ील्ड पर CAST () या CONVERT () का उपयोग करते हुए शून्य लौटता है (ताकि इसे एक स्ट्रिंग के रूप में स्पष्ट रूप से माना जाएगा) 0024-06-22 रिटर्न।

MySQL 5.5 दस्तावेज में कहा गया है कि DATETIME प्रकार में समर्थित तिथि सीमा 1000-01-01 00:00:00 से 9999-12-31 23:59:59 है। निरंतरता बताती है कि "DATE ​​और DATETIME के ​​लिए," समर्थित "का अर्थ है कि कम मान काम कर सकते हैं, लेकिन इसकी कोई गारंटी नहीं है।" यह पता चला कि एप्लिकेशन ने डेटाबेस में एक अजीब डेटाटाइम दर्ज किया है, और इस तथ्य के कारण कि मूल्य प्रारूप की जांच से गुजर गया और डेटाबेस में आ गया। उफ़ ...

इससे हम क्या समझते हैं?

* दुर्भाग्य से, यहां sql_mode सेट करने से आपको मदद नहीं मिलेगी। यद्यपि 0024-06-21 तकनीकी रूप से DATE / DATETIME के ​​लिए समर्थित सीमा से बाहर है, न ही TRADITIONAL, STRICT_ALL_TABLES, या STRICT_TRANS_TABLES भी एक चेतावनी फेंकता है। यह एक बग या एक सुविधा है? चुनाव आपका है।
* जब दस्तावेज़ कहता है कि "इस बात की कोई गारंटी नहीं है कि यह काम करेगा", तो बेहतर है कि जोखिम न लें।
* भले ही डेटा का एक टुकड़ा अपेक्षित प्रारूप में फिट बैठता है, इसका मतलब यह नहीं है कि यह सही मूल्य है। तो शायद इस सब से यह सबसे महत्वपूर्ण सबक है: हमेशा, हमेशा दर्ज किए गए डेटा की सीमा की जांच करें! केवल प्रारूप की जाँच करना पर्याप्त नहीं है।
और अंतिम बिंदु - मैं Percona सर्वर 5.5.25a के साथ एक ही स्थिति को दोहराने में कामयाब रहा, लेकिन मेरे मामले में, यह व्यवहार भी अजनबी था। मैंने एक समान संरचना वाली एक तालिका बनाई:

 CREATE TABLE `foo` ( `i` int(11) NOT NULL AUTO_INCREMENT, `update_date` datetime NOT NULL, PRIMARY KEY (`i`), KEY `i` (`i`,`update_date`) ) ENGINE=InnoDB 

और फिर दिनांक 0024-06-21 के साथ कुछ डमी लाइनें सम्मिलित कीं। फिर मैंने एक साधारण पर्ल स्क्रिप्ट के साथ इस तालिका में कई हजार यादृच्छिक डेटासेट को डंप किया। पहली नज़र में, सब कुछ ऐसा दिख रहा था जैसे मैं अपनी स्थिति को दोहरा नहीं सकता था - मेरी मेज के लिए "SELECT MIN (अपडेट_टाइम) Foo" के निष्पादन ने सही उत्तर दिया (1058-11-06 00:00:00), जो न्यूनतम तारीख थी न्यूनतम समर्थित मूल्य 1000-01-01 00:00:00 से बड़े मूल्य के साथ। लेकिन जब मैंने उनके पीके को बदलकर डमी लाइनों को स्थानांतरित करने का फैसला किया, तो यह हुआ:

  : (root@localhost) [test]> select * from foo order by update_date limit 5; +-------+---------------------+ | i | update_date | +-------+---------------------+ | 1 | 0024-06-21 10:35:55 | | 2 | 0024-06-21 10:35:55 | | 3 | 0024-06-21 10:35:55 | | 4 | 0024-06-21 10:35:55 | | 1159 | 1058-11-06 00:00:00 | +-------+---------------------+ (root@localhost) [test]> select min(update_date) from foo; +---------------------+ | min(update_date) | +---------------------+ | 1058-11-06 00:00:00 | +---------------------+ (root@localhost) [test]> update foo SET i=i+100000 where i<5; Query OK, 4 rows affected (0.00 sec) Rows matched: 4 Changed: 4 Warnings: 0 

  : (root@localhost) [test]> select min(update_date) from foo; +---------------------+ | min(update_date) | +---------------------+ | 2024-06-21 10:35:55 | +---------------------+ (root@localhost) [test]> select update_date FROM foo order by update_date LIMIT 5; +---------------------+ | update_date | +---------------------+ | 0024-06-21 10:35:55 | | 0024-06-21 10:35:55 | | 0024-06-21 10:35:55 | | 0024-06-21 10:35:55 | | 1058-11-06 00:00:00 | +---------------------+ 

बहुत अजीब है। एक ओर, ऐसा लगता है कि जैसे MySQL दो अंकों की तारीखों के लिए दिनांक फ़िल्टरिंग का उपयोग करता है (यह 2024-06-21 बताते हैं), दूसरी ओर, इसने DATETIME डेटा को किसी भी तरह से प्रभावित नहीं किया, और अब यह निश्चित रूप से गलत उत्तर देता है।

निष्कर्ष: हमेशा अपनी प्रविष्टियां जांचें!

मूल लेख: एर्नी सौहार्द MIN (DATE) कब है? = MIN (DATE)?