為什麼不建議在工作中使用連表查詢？
singwa答：最近在swoole課程群裡面有小夥伴在諮詢有關連表查詢的一些事情，其實連表查詢在實際工作中，特別是中型以上的公司基本不建議用連表查詢的 原因我彙總如下：
場景：比如你要查詢文章的資訊，並且是分頁列表展示，然後文章裡面還有其他的內容比如欄目等，但是文章表裡面的欄目肯定存的是欄目表的主鍵id， 但是在平台中展示文章列表的時候肯定是需要展示欄目的名稱的，那這個時候很多任務程師基本是使用關聯連表查詢比比如 left join等的。但是實際上不建議這樣來做。 作法如下：
取出文章的內容(比如第一頁的時候 展示 20條內容) ，放到乙個陣列裡面；
並且把這資料中欄目id放到 另外乙個陣列裡面 需要去重處理， 然後在拿到這些id 去欄目表裡面 in查詢下，1條sql。不是多個sql
查詢後組織下欄目的資料 id=>name的關係
在列表展示的時候 迴圈文章的陣列、展示欄目的時候就可以拿到3中的對應關係對上。
在工作中使用分而治之的思想
分而治之，是將大問題分解為小問題，然後求解每個小問題，最終完成求解剛開始的大問題的一種思想和方法。分而治之是演算法中經常採用的一種思路，其實，在日常的工作中，我們也可以採用分而治之的思想更好的完成自己的工作。前幾天，自己收到乙個任務，程式完成後，在進行完必要的效能優化後，經過計算，發現仍然需要20個...
為什麼不建議使用儲存過程了
在公司的系統公升級換代中，明確規定在資料庫開發中不允許再使用儲存過程了，以前的老一代系統中，很多複雜的業務邏輯都是儲存過程寫的，那為什麼風光無限的儲存過程不再被寵幸了呢？首先了解下什麼是儲存過程，它有什麼好處，又有哪些劣勢，為什麼現在都不建議使用儲存過程呢？儲存過程 stored procedure...
為什麼不建議在for迴圈中使用「 「進行字串拼接
舉例 long t1 system.currenttimemillis string str hollis for int i 0 i 50000 i long t2 system.currenttimemillis system.out.println cost t2 t1 反編譯後 如下 lon...