深夜上線隨感@sql語句

　　又是上線日，不知道爲啥晚上就容易想點啥。此次上線前吧有點坎坷，對接外圍系統出了點問題。測試過程當中發現了這個問題，可是去找開發，開發就一個推一個。流程說流程沒問題，你去找收單；收單說收單沒問題，你去找數據；數聽說數據沒問題，你去找外圍系統；外圍系統說咱們給你的報文沒問題，是大家本身的問題。這麼一推二推就推了兩天，給我整的又着急又生氣。只能把這個bug升級在升級，終於被大佬在羣裏@開發定位解決（測試說話是真的沒啥做用，小聲bb）。最後發現，嘿外圍系統悄悄改了點東西，沒通知咱們。收單數據是沒問題，他們給的報文也沒問題，可是轉換就有問題了。咱們9是不變，2是新增，6是修改，他們給改了，致使最後展現的不變的信息都變成修改了。。這就很頭疼，外圍系統本身改點啥不通知，此次測到了是發現了，那下次沒測到不就上生產出問題了嗎，ε=(´ο｀*)))唉

　　另外就是如何能提升推進開發修改的效率呢？首先就是提升本身定位bug的能力，是前端仍是後端，後端的話是受理、收單、數據仍是流程？接觸這個項目這麼久了，也基本能判斷是哪的問題，就是有部分bug定位還不是很準確，感受是受理或者收單的鍋，可能最後是數據的問題。另外就是及時關注bug狀態，開發發現這個bug不是本身的問題就立馬指回給測試，這就致使bug的解決效率很低，戰線拉得長。特別是對接外圍的就更難找人去處理了。。

　　這一段時間不是接手了個新項目嗎，主要是數據展現的一個項目，根據時間、類別、地區等等劃分，進行實時統計展現的一個系統，主要是在數據庫按不一樣的條件查查查，看看展現的對不對。基本的還闊以，進階一點的就須要在回憶裏再翻翻。

　　首先就遇到一個問題，就是在查詢某環節在途任務時，須要將finish_time爲空的單子判斷爲在途，想固然的寫了where finish_time = null 查的時候沒有報錯卻查到了所有走過該環節的數據。通常狀況下將任何值(包括NULL自己)與NULL作比較的時候，都會返回UnKnown。因此在寫查詢語句的時候要寫 where finish_time  is null；

　　另外就是查詢某種類型的單子的總量，這種類型包括多種類型，對一個字段匹配多個值的就能夠寫成 where type_code in（1101,1102）; 若是是不肯定的話就能夠寫成where type_code like '11%';  若是要匹配四位類型，且最後一位不肯定的話就是 where type_code like '110_';

　　用in 的時候還跟開發發生了一件事情，我比開發查的數據要多兩條，拉出數據來一瞅，有兩條是符合條件的爲啥沒篩進去呢？由於他的某一個字段裏包含了兩種字段，就比如篩選鉛筆、橡皮等商品時，會用**in（'鉛筆','橡皮'），可是這個時候是篩不到鉛筆橡皮的，而**in（鉛筆,橡皮）就能查到= =

　　最近碰上一個問題，就是有一個字段是以json串形式被保存在數據庫中，可是因爲這個json串很長，並且這個字段也不是固定位置的。須要統計若干個單子中包含這個字段，且這個字段要早於當前時間。不知道有木有大佬能給一個解決辦法，如何能快速統計呢？