一個mysql優化就難住了？別怕，來看這張思惟導圖

最近，周圍的同事離職的愈來愈多，身邊的小夥伴好像也有動做了，找他聊聊。

「咋了，你也要走？」

小夥伴：」如今的工做太枯燥，缺乏成就感，想換一個，有技術挑戰的那種「

」你如今不挺好麼，leader對你也不錯，也挺器重，感受你前途一片光明「

小夥伴：」這叫不錯？這叫器重？我這種邊緣項目，一沒技術難度、二沒流量、三沒數據量，更別談高併發了，每天作不完的需求，修不完的BUG，在這裏就感受溫水煮青蛙，我就是那隻呱呱呱，我得去外面看看「

"..."

看來積怨已深，我只能打住，說了一些恭維的話，結束了交流。

這幾天，感受小夥伴的氣壓比較低，我猜是面試受打擊了，因而又找他聊。

「最近咋了？狀況不對啊」

小夥伴：「上次去面試，面試官問我，項目中用了那些SQL優化，我一下就懵了，沒回答上來...」

「懵啥？」

小夥伴：「我這種每天接需求，寫的SQL只關心查出來的數據正確與否 ，哪有須要作優化？」

「這...」

小夥伴：「只能怪本身，這破項目，SQL隨便寫寫也不會出問題「

小夥伴：」最後出問題的是本身，我廢了。」

小夥伴：「對了，常見的SQL優化有哪些？」

「行，我給你整理下。」

「其實大部分主要對查詢進行優化，最重要的是儘可能避免全表掃描」

• 適當的建立索引，考慮在 where 及 order by 涉及的列上創建索引
• 儘可能避免在 where 子句中對字段進行 null 值判斷、使用!=或<>操做符、使用 or 來鏈接條件、對字段進行函數操做等
• in 和 not in 也要慎用，不然可能會致使全表掃描
• 不少時候用 exists 代替 in 是一個好的選擇
• 儘可能使用數字型字段，若只含數值信息的字段儘可能不要設計爲字符型，這會下降查詢和鏈接的性能，並會增長存儲開銷。
• 儘量的使用 varchar 代替 char ，由於首先變長字段存儲空間小，能夠節省存儲空間，其次對於查詢來講，在一個相對較小的字段內搜索效率顯然要高些。

SQL優化手段還有不少，大多數都是摸打滾爬的經驗積累，只有本身碰到了，纔有深入的理解和體會。

這麼說可能沒什麼特別的，那若是剛纔的那些話這樣看呢？

總圖

分圖

篇幅緣由，只展現一部分，須要完整架構圖的，點贊支持一下，而後私信「資料」便可

怎麼樣，這樣話是否是就很體系了

可是這個只是解決方案，還真的不是我今天的重點，重點在於和同事聊天的那最後一句話：這破項目，隨便寫寫SQL就解決了，出問題是我，我廢了

你們應該都聽過或正在經歷：面試造航母，工做擰螺絲

可是，我想說，難道工做擰螺絲你就是個螺絲工了嗎？難道你以爲你比一個在學校的大學生差嘛？不要爲本身的偷懶找理由，可能這個時候會有人出來反駁我，天天工做加班累的要死，哪有時間。。。。吧啦吧啦，相似這樣的話，當你說出這句話的時候，其實你就應該知道爲何一樣是作程序員，有的人年薪8W，有的人80W了，最大的緣由其實就是你已經放棄學習了，而程序員這麼個隨時在更替技術的行業，可能明天技術就會更新一輪，若是你忘記了學習，可能短期不會有什麼問題，可是時間一長呢？

好比說：

之前：會個ssm就能找工做 如今：微服務、分佈式、源碼、調優。。。

之前：會個大數據集羣就能夠 如今：參數調優、推薦系統。。。

兄弟，這才幾年啊，jdk都已經14了，你又去了解過多少？spring源碼看過多少？jvm調優又理解過多少？

最近，小編公衆號後臺有好多人私聊我說面試好難啊，如今面試都要什麼人啊？小編想說，真的不是面試官再爲難你，而是要求變高了，對於項目編碼的要求也不是能夠實現功能就行得了，因此對於人才的質量要求也高了，沒得辦法，你在說什麼都很差使，什麼crud是基礎，其餘的都是輔助，什麼那家公司能不作crud，我想說：這算是你安慰本身以爲問題不大的藉口嗎？若是不是最好，若是是，那爲何還不行動起來呢？你還在猶豫什麼呢？

不信，看一個大學生的筆記吧

基礎：

消息隊列：

後來者都如此努力，咱們做爲先行者，怎麼能夠不努力

最後，小編整理了一套技術資料不只能精準消除技術盲點、累計面試經驗，更能夠攻克JVM、Spring、分佈式、微服務等技術難題。這裏也就不展現了，有須要的
關注公衆號：Java架構師聯盟，每日更新技術好文