程序員熬夜寫代碼為什么效率低？看我因?yàn)橐粋€(gè)簡(jiǎn)單的問題撓破頭！硬是花了我快一個(gè)小時(shí)，最后突然反應(yīng)過來，想死的心都有了！后來我安慰自己：這不能怪我，因?yàn)榘疽箤?a class="keyword-search" >代碼真的容易走神！
事情很簡(jiǎn)單，我需要做一個(gè)Excel導(dǎo)出數(shù)據(jù)的功能，根據(jù)時(shí)間先把數(shù)據(jù)查詢出來，然后寫入Excel中進(jìn)行保存，功能很簡(jiǎn)單吧？
這就涉及到了Sql語句了，現(xiàn)在有兩張表，本來這兩張表的數(shù)據(jù)是獨(dú)立的，但是，做Excel導(dǎo)出時(shí)，需要將這兩張表中的部分?jǐn)?shù)據(jù)進(jìn)行合并，所以，就涉及到了聯(lián)查功能。
最開始，我以為問題很簡(jiǎn)單，因?yàn)閮蓮埍碇卸加凶侄巍皒xxNo”和“xxxId”，而在系統(tǒng)的業(yè)務(wù)邏輯中，這兩個(gè)字段合并起來應(yīng)該是全局唯一的，但是，偶爾會(huì)出現(xiàn)不是唯一的情況，因此，這兩個(gè)字段并沒有被設(shè)計(jì)成唯一索引。
我希望Sql語句達(dá)到的效果應(yīng)該是A表為主表，B表為從表，A表Left Join B表，想要達(dá)到的目的就是，A表不管有多少數(shù)據(jù)先查出來，然后再根據(jù)A表已有的數(shù)據(jù)去聯(lián)查B表。
但是，我查詢出來的數(shù)據(jù)條數(shù)始終不對(duì)，假設(shè)A表的數(shù)據(jù)量有100條，我希望不管B表有多少數(shù)據(jù)，聯(lián)表查詢后的數(shù)據(jù)總條數(shù)就應(yīng)該是100條，但是，我查出來的數(shù)據(jù)始終是大于100條。
因?yàn)椤皒xxNo”和“xxxId”這兩個(gè)字段在B表內(nèi)并非唯一，所以查詢就有問題了。
然后，我對(duì)B表進(jìn)行了重新改造，直接在B表中新增了一個(gè)字段“AId”，即A表數(shù)據(jù)行的Id。
按照我的認(rèn)知，這樣一來，不管怎么樣，這個(gè)“AId”在B表內(nèi)肯定是唯一的，因?yàn)橹挥蠥表在新增數(shù)據(jù)時(shí)，B表會(huì)跟著新增數(shù)據(jù)，并且因?yàn)锳表的Id是自增的，怎么搞也不會(huì)重復(fù)吧！
然后，詭異的事情就出現(xiàn)了，我將代碼改好以后，新增了一條數(shù)據(jù)，選擇了數(shù)據(jù)導(dǎo)出，結(jié)果只出現(xiàn)了一條數(shù)據(jù)！可是，A表明明有101條數(shù)據(jù)啊，怎么在B表中新增字段以后查出來的數(shù)據(jù)只有1條了呢？
我開始懷疑起了我對(duì)數(shù)據(jù)庫的認(rèn)知，難道Left Join B表后，按照A表的Id進(jìn)行匹配，只會(huì)聯(lián)合查詢出A表Id和B表“AId”匹配的數(shù)據(jù)？
為了驗(yàn)證我的想法，我又新增了一條數(shù)據(jù)，A表數(shù)據(jù)來到了102行，然后我再點(diǎn)擊數(shù)據(jù)導(dǎo)出，結(jié)果數(shù)據(jù)真的只有2行！
此時(shí)，我有點(diǎn)崩潰了！難道我一直以來對(duì)數(shù)據(jù)庫查詢的認(rèn)知有問題？
你們絕對(duì)想不到我犯了什么樣的錯(cuò)誤！并且，你們也絕對(duì)想不到我是怎么發(fā)現(xiàn)這個(gè)錯(cuò)誤的！其實(shí)，錯(cuò)誤非常簡(jiǎn)單！
因?yàn)?，在“錯(cuò)誤”出現(xiàn)的時(shí)候，已經(jīng)過了凌晨0點(diǎn)！
我一直以來都是根據(jù)時(shí)間查詢的，即當(dāng)天的0點(diǎn)到當(dāng)天的23點(diǎn)59分59秒這個(gè)時(shí)間段查詢的數(shù)據(jù)，根據(jù)這個(gè)條件，查詢出來的數(shù)據(jù)是100行！
并且，我的軟件第一次進(jìn)入查詢界面，代碼就會(huì)自動(dòng)將時(shí)間控件置為當(dāng)天的0點(diǎn)到當(dāng)天的23點(diǎn)59分59秒。
因?yàn)槊看胃耐甏a，我都需要重啟軟件，因此，時(shí)間控件的值就會(huì)被自動(dòng)重置，在我改完代碼后，時(shí)間就被重置了。
所以，我即使新增了一條字段，A表此時(shí)能查詢出來的數(shù)據(jù)條數(shù)也就只有一條！
而我是怎么發(fā)現(xiàn)這個(gè)問題的呢？
因?yàn)槲腋耐甏a以后，數(shù)據(jù)條數(shù)始終不對(duì)，我就進(jìn)了數(shù)據(jù)庫去查詢數(shù)據(jù)來驗(yàn)證我的Sql語句到底有沒有寫錯(cuò)，但是，在我的意識(shí)里，是還沒過0點(diǎn)的，所以，我的查詢條件依然寫得是前一天的0點(diǎn)到23點(diǎn)59分59秒這個(gè)時(shí)間段。
結(jié)果，查出來的數(shù)據(jù)依然是100條！
剛開始我還納悶，此時(shí)數(shù)據(jù)明明是102條啊，怎么查詢出來的數(shù)據(jù)只有100條呢？
直到現(xiàn)在，我都沒有懷疑時(shí)間是否已經(jīng)過了0點(diǎn)這件事情！直到我撓破頭都想不到我錯(cuò)在哪里的時(shí)候，我下意識(shí)地拿起手機(jī)想要放松一會(huì)兒，結(jié)果發(fā)現(xiàn)我的手機(jī)是黑屏的！
此時(shí)我恍然大悟，因?yàn)槲业氖謾C(jī)過了凌晨0點(diǎn)會(huì)自動(dòng)熄屏的！
結(jié)語
得知真相的我，真的被自己蠢哭了，直到我解決問題的時(shí)候，都已經(jīng)快凌晨1點(diǎn)了！我竟然在這個(gè)問題上折騰了那么久！
不過，這也提醒我，此時(shí)應(yīng)該關(guān)閉電腦，好好休息了！否則，下一步又不知道犯什么蠢事了！
很多程序員都說加班或者熬夜寫代碼效率低，可能非程序員沒有什么概念，經(jīng)過我的事情，你們現(xiàn)在應(yīng)該知道為什么加班或者熬夜寫代碼效率低了吧？因?yàn)楫?dāng)連續(xù)工作時(shí)間太長的話，腦子是真不好使了！
熱門跟貼