程序員加班熬夜寫代碼為什么效率低？一個小疏忽折騰我一小時！

程序員熬夜寫代碼為什么效率低？看我因為一個簡單的問題撓破頭！硬是花了我快一個小時，最后突然反應過來，想死的心都有了！后來我安慰自己：這不能怪我，因為熬夜寫代碼真的容易走神！

事情很簡單，我需要做一個Excel導出數據的功能，根據時間先把數據查詢出來，然后寫入Excel中進行保存，功能很簡單吧？

這就涉及到了Sql語句了，現在有兩張表，本來這兩張表的數據是獨立的，但是，做Excel導出時，需要將這兩張表中的部分數據進行合并，所以，就涉及到了聯查功能。

最開始，我以為問題很簡單，因為兩張表中都有字段“xxxNo”和“xxxId”，而在系統的業務邏輯中，這兩個字段合并起來應該是全局唯一的，但是，偶爾會出現不是唯一的情況，因此，這兩個字段并沒有被設計成唯一索引。

我希望Sql語句達到的效果應該是A表為主表，B表為從表，A表Left Join B表，想要達到的目的就是，A表不管有多少數據先查出來，然后再根據A表已有的數據去聯查B表。

但是，我查詢出來的數據條數始終不對，假設A表的數據量有100條，我希望不管B表有多少數據，聯表查詢后的數據總條數就應該是100條，但是，我查出來的數據始終是大于100條。

因為“xxxNo”和“xxxId”這兩個字段在B表內并非唯一，所以查詢就有問題了。

然后，我對B表進行了重新改造，直接在B表中新增了一個字段“AId”，即A表數據行的Id。

按照我的認知，這樣一來，不管怎么樣，這個“AId”在B表內肯定是唯一的，因為只有A表在新增數據時，B表會跟著新增數據，并且因為A表的Id是自增的，怎么搞也不會重復吧！

然后，詭異的事情就出現了，我將代碼改好以后，新增了一條數據，選擇了數據導出，結果只出現了一條數據！可是，A表明明有101條數據啊，怎么在B表中新增字段以后查出來的數據只有1條了呢？

我開始懷疑起了我對數據庫的認知，難道Left Join B表后，按照A表的Id進行匹配，只會聯合查詢出A表Id和B表“AId”匹配的數據？

為了驗證我的想法，我又新增了一條數據，A表數據來到了102行，然后我再點擊數據導出，結果數據真的只有2行！

此時，我有點崩潰了！難道我一直以來對數據庫查詢的認知有問題？

你們絕對想不到我犯了什么樣的錯誤！并且，你們也絕對想不到我是怎么發現這個錯誤的！其實，錯誤非常簡單！

因為，在“錯誤”出現的時候，已經過了凌晨0點！

我一直以來都是根據時間查詢的，即當天的0點到當天的23點59分59秒這個時間段查詢的數據，根據這個條件，查詢出來的數據是100行！

并且，我的軟件第一次進入查詢界面，代碼就會自動將時間控件置為當天的0點到當天的23點59分59秒。

因為每次改完代碼，我都需要重啟軟件，因此，時間控件的值就會被自動重置，在我改完代碼后，時間就被重置了。

所以，我即使新增了一條字段，A表此時能查詢出來的數據條數也就只有一條！

而我是怎么發現這個問題的呢？

因為我改完代碼以后，數據條數始終不對，我就進了數據庫去查詢數據來驗證我的Sql語句到底有沒有寫錯，但是，在我的意識里，是還沒過0點的，所以，我的查詢條件依然寫得是前一天的0點到23點59分59秒這個時間段。

結果，查出來的數據依然是100條！

剛開始我還納悶，此時數據明明是102條啊，怎么查詢出來的數據只有100條呢？

直到現在，我都沒有懷疑時間是否已經過了0點這件事情！直到我撓破頭都想不到我錯在哪里的時候，我下意識地拿起手機想要放松一會兒，結果發現我的手機是黑屏的！

此時我恍然大悟，因為我的手機過了凌晨0點會自動熄屏的！

結語

得知真相的我，真的被自己蠢哭了，直到我解決問題的時候，都已經快凌晨1點了！我竟然在這個問題上折騰了那么久！

不過，這也提醒我，此時應該關閉電腦，好好休息了！否則，下一步又不知道犯什么蠢事了！

很多程序員都說加班或者熬夜寫代碼效率低，可能非程序員沒有什么概念，經過我的事情，你們現在應該知道為什么加班或者熬夜寫代碼效率低了吧？因為當連續工作時間太長的話，腦子是真不好使了！