資料庫優化主要可以分為兩大類，軟優化和硬優化：
軟優化一般是運算元據庫即可，而硬優化則是操作伺服器硬體及引數設定.
先比較三個sql：
student表中有四條資料，如圖：
由於資料量和字段都比較少，導致結果和查詢時間完全一樣，都是：
但是，用desc 分析時可以發現差距：
如果全表掃瞄，那麼 filtered 就代表滿足搜尋條件的記錄的滿分比
如果是索引，那麼 filtered 就代表除去索引對應的搜尋，其他搜尋條件的百分比
軟優化：
1. 查詢語句優化：
1.1 盡量避免在where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃瞄
1.2 盡量避免在where 子句中使用 or 來連線條件，否則將導致引擎放棄使用索引而進行全表掃瞄
1.3 盡量避免在where 子句中使用 in 和 not in，否則會導致全表掃瞄，用 exists 代替 in
1.4 盡量避免在where 子句中使用 "%c%"，否則會導致全表掃瞄
1.5 盡量避免在where 子句中對字段進行表示式操作，導致引擎放棄使用索引而進行全表掃瞄
1.6 盡量避免在where 子句中對字段進行函式操作，導致引擎放棄使用索引而進行全表掃瞄
1.8 盡可能的使用 varchar 代替 char
1.9 當只要一行資料時使用 limit 1
2. 使用索引
2.1 在使用索引字段作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第乙個字段作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓字段順序與索引順序相一致
2.2 盡量確認兩個表中 join 的字段是被建過索引的
2.3 並不是所有索引對查詢都有效
當索引列有大量資料重複時，sql 查詢可能不會去利用索引，如一表中有字段 ***，male、female 幾乎各一半，那麼即使在***上建了索引也對查詢效率起不了作用
2.4 like關鍵字匹配'%'開頭的字串,不會使用索引
2.5 or 關鍵字的兩個字段必須都是用了索引,該查詢才會使用索引
3. 分表
對於欄位較多的表,如果某些字段使用頻率較低,此時應當,將其分離出來從而形成新的表,
4. 中間表
對於將大量連線查詢的表可以建立中間表,從而減少在查詢時造成的連線耗時
5. 增加冗餘字段
類似於建立中間表,增加冗餘也是為了減少連線查詢
6. 分析表,檢查表,優化表
分析表: 使用 analyze 關鍵字，如analyze table student
op：表示執行的操作
msg_type：資訊型別,有status、info、note、warning、error
msg_text：顯示資訊
檢查表: 使用 check關鍵字，如check table student[option]
優化表:使用optimize關鍵字，如optimize [local|no_write_to_binlog] table student
當刪除了表的部分資料，或者已經對含有可變長度行的表（含有varchar, blob或text列的表）進行了很多更改，則應使用optimize table。被刪除的資料被保持在鏈結清單中，後續的insert操作會重新使用舊的記錄位置。您可以使用optimize table來重新利用未使用的空間，並整理資料檔案的碎片。
在多數的設定中，您根本不需要執行optimize table。即使您對可變長度的行進行了大量的更新，您也不需要經常執行，每週一次或每月一次即可，只對特定的表執行。
optimize table 只對myisam，bdb和innodb表起作用
注意：在ptimize table 執行過程中，mysql會鎖定表
硬優化：
1. 硬體優化
2. 優化資料庫引數
優化資料庫引數可以提高資源利用率,從而提高mysql伺服器效能.mysql服務的配置引數都在my.cnf或my.ini,下面列出效能影響較大的幾個引數.
3. 分庫分表
因為資料庫壓力過大，首先乙個問題就是高峰期系統效能可能會降低，因為資料庫負載過高對效能會有影響。另外乙個，壓力過大把你的資料庫給搞掛了怎麼辦？
所以此時你必須得對系統做分庫分表 + 讀寫分離，也就是把乙個庫拆分為多個庫，部署在多個資料庫服務上，這時作為主庫承載寫入請求。然後每個主庫都掛載至少乙個從庫，由從庫來承載讀請求。
4. 快取集群
如果使用者量越來越大，此時你可以不停的加機器，比如說系統層面不停加機器，就可以承載更高的併發請求。然後資料庫層面如果寫入併發越來越高，就擴容加資料庫伺服器，通過分庫分表是可以支援擴容機器的，如果資料庫層面的讀併發越來越高，就擴容加更多的從庫。
但是這裡有乙個很大的問題：資料庫其實本身不是用來承載高併發請求的，所以通常來說，資料庫單機每秒承載的併發就在幾千的數量級，而且資料庫使用的機器都是比較高配置，比較昂貴的機器，成本很高。如果你就是簡單的不停的加機器，其實是不對的。所以在高併發架構裡通常都有快取這個環節，快取系統的設計就是為了承載高併發而生。
所以單機承載的併發量都在每秒幾萬，甚至每秒數十萬，對高併發的承載能力比資料庫系統要高出一到兩個數量級。所以你完全可以根據系統的業務特性，對那種寫少讀多的請求，引入快取集群。
具體來說，就是在寫資料庫的時候同時寫乙份資料到快取集群裡，然後用快取集群來承載大部分的讀請求。這樣的話，通過快取集群，就可以用更少的機器資源承載更高的併發。
資料庫優化 資料庫設計優化
一 索引優化 1.首先索引不是越多越好，要視情況而定。因為索引會降低insert和update的效率 insert和update有時可能會重建索引。2.乙個表的索參數量最好不要超過6個，擇優而建。3.專案上線後，根據使用者的查詢條件字段稍微調整資料庫中的字段索引。二 分表 1.縱切 根據表字段來且分...
資料庫引擎優化顧問優化資料庫
現在一直在做的專案，資料量相對也不小，開始的時候沒有覺得，因為是剛開始，資料量還很小，在程式使用過程中速度還挺快，但是隨著資料量的不停的增長，發現程式越來越慢，甚至出現了超時的問題，因此要對程式和資料庫進行優化，前期專案比較緊，沒有針對大資料量業務進行分析設計，所以索引等相關優化沒有做到位，通過後期...
資料庫優化
資料庫優化 1 合理使用索引 索引是資料庫中重要的資料結構，它的根本目的就是提高查詢效率。索引的使用要恰到好處，其使用原則如下 在經常進行連線，但是沒有指定為外來鍵的列上建立索引，而不經常連線的字段則由優化器自動生成索引 在頻繁進行排序或分組 即進行groupby或orderby操作 的列上建立索引...