sql優化

mysql客戶端/服務端是半雙工，都是要麼伺服器==》客戶端，客戶端 ==》服務端

查詢語句過長，需要設定max_allowed_packet引數，太大，會跑出異常；

mysql處理過程

很多的查詢優化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的合理方式執行而已

mysql的優化器基於成本判斷，選擇最小成本的一個，並不一定最快的一個。

• 檢視設計和資料型別優化
• 建立高效能的索引
• 索引對應的資料結構和演算法優化
• 避免多個範圍條件
• 覆蓋索引
• 使用索引掃描排序
• 優化count（）查詢
• 優化union
  總結下上面：

• 索引
• 資料型別
• 簡單的函式條件判斷減少
  請還是以實際開發中的遇到的問題，選擇適合的優化，否則，與業務無關的優化，都是耍流氓！
  優化sql語句是很重要的，但是對於整個系統來說，優化的方向，更應該是系統中的應用服務，減少資料庫方面的函式呼叫，用服務解決函式問題，更容易提高效能，減少資料庫壓力。

謹記:資料庫就是儲存資料的，是最不要計算的地方！

參考部落格：https://www.cnblogs.com/liujiacai/p/7605612.html

select* 和select 全部欄位有什麼區別

從執行效率上，一般的sql語句解析都有快取，沒有什麼差距。select * 可能會查詢 Query Table Metadata For Columns（查詢元資料表的列），可能會增加資料庫壓力，實際上，並沒有什麼不同！

從實際開發，優化開發角度，* 不容易讓其他程式設計師看懂返回的具體資料有哪些，很不友好！（你要是囂張，堅持* 的道路吧！）

建議：* 這種查詢方式，適合在程式開發測試以及demo的時候，其他時間儘量寫清返回的欄位名

springboot的優勢

• 編碼簡單==用java config配置方式配置spring，提供大量註解
• 配置簡單==超多的預設配置，很多jar間的版本都會選用穩定的，不用自己注意jar衝突
• 部署簡單==不用tomcat等web容器，內建tomcat，jetty，undertow三種容器
• 監控簡單==提供了actuator包，可以使用它來對你的應用進行監控。

缺點：入門級的微服務

• 集中式application.yml，這種配置不安全，不適合企業級的集中式的配置管理系統，不同配置嚴格分割槽存放
• 監控系統的認證方式簡單，不安全。
• 在服務發現、註冊沒有的

如何啟動springboot

• 在開發階段：啟動springboot 的start類
• 在部署階段：
  • maven方式
  • java -jar jar包名