問題復現
今天加班寫了一個介面，剛開始發現誒資料還是正常的，覺得可以上線了，因為這個介面只是去ES查了一次資料，統計了一下數量，前端驗證也沒什么問題，但是突然，我發現了另一個問題：
這里面待處理是0 啊，為什么介面回傳的是10，有值導致前端加了一個小紅點，代表有會話的，
然后我就去看我寫的代碼
問題出在SQL查詢，因為我要查詢這個組（你可以理解為一個小組）下的所有資料，結果我沒剔除已經洗掉了的人(賬戶).結果把那些剔除出這個組的賬戶的會話也查詢了出來，
那好啊，我直接把SQL改了就行了吧，只查離線，在線的，那些洗掉的我不查這樣總行了吧
結果，想象是美好的，現實是殘酷的，還是資料不對，這個地方還是10，10
那是什么問題？
出路
因為這個地方是去查ES的，我在MySQL肯定是查不到這個結果的，難道是因為ES和MySQL資料不同步的原因么？
然后我就去ES查詢工具查了一下，發現沒有資料啊，都是0，應該也是兩個0的，那么肯定就是代碼問題了，然后我就回頭開始看代碼流程，最后發現，原因是我查詢這個組的用戶/賬戶后，并沒有判空/null操作，就像MyBatisPlus一樣，如果傳遞的引數為null，他會自動把這個引數給去掉，就是像這樣
那是不是說我鏈接ES然后去查詢的時候，ES看到這個引數傳遞的是null，他也把這個查詢條件給干掉了，經過驗證，確實是這樣，ES的機制跟MyBatisPlus，或者上面那種SQL的寫法一樣，他也會幫你做一次判斷，至此問題排查出來
解決
這個bug很簡單，只是當時并沒有想到這種情況，解決辦法就是如果我查詢的這個組下面的用戶集合是個null的話，我們直接return就行了，return 這個物件都是0就行了
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/379436.html
標籤：其他
上一篇：Shell基礎知識