MySQL資料庫優化

盡可能不要使用null值

新增索引

優化表字段結構

大表拆分

優化查詢語句

新增快取

使用「臨時表」暫存中間結果

聯合查詢和單查詢的優缺點（建議使用單查詢）

盡量避免在where子句中對字段進行函式或表示式操作

因為建表的時候，如果不對建立的值設定預設值，mysql都會設定預設為null

那麼，為啥用null不好呢？

設定乙個預設值吧，空字串呀，0呀

雖然這種方法對於mysql的效能來說沒有提公升多少，但是這是乙個好習慣，而且以小見大，不要忽略這些細節。

對於經常查詢的字段，**上索引，有索引和沒有索引的查詢速度相差十倍甚至更多。

當表和表之間有約束時，雖然增刪查的sql語句變簡單了，但是帶來的負面效果是插入等運算元據庫都會去檢查約束（雖然可以手動設定忽略約束），這樣相當於把一些業務邏輯寫到了資料庫層，不便於維護。

這個才是很多系統資料庫瓶頸的始作俑者

使用redis等快取，還有本地檔案快取等，可以極大地減少資料庫查詢次數。快取這個東西，一定要分析自己系統的資料特點，適當選擇。

簡化sql語句的重要方法就是採用臨時表暫存中間結果，但是，臨時表的好處遠遠不止這些，將臨時結果暫存在臨時表，後面的查詢就在tempdb中了，這可以避免程式中多次掃瞄主表，也大大減少了程式執行中「共享鎖」阻塞「更新鎖」，減少了阻塞，提高了併發效能。

單查詢可重用性高，相對簡單容易理解，而且做分庫等改動較小。與聯合查詢相比較，單查詢需要自己用**去完成聯合查詢的邏輯，相對繁瑣工作量較大，聯合查詢只要開發人員能夠充分理解並且熟練使用，開發效率會提高很多，但是大量的聯合查詢會讓系統進行分庫時改動較大。

查詢效率來看

查詢的執行流程：連線資料庫、傳入sql、執行sql語句、返回查詢結果、斷開連線；

在這套流程中。服務與資料庫互動的時間花費是比較大的。但是現在隨著網路的速度與之前相比快了很多，連線資料庫、返回查詢結果、斷開連線的耗時不在是影響效率的主要原因。

當與資料庫的互動對效率的影響沒有那麼大的時候。其實單查詢更好一些。

例如：select * from tb_alarm_device_daily_statis where times/2=1