關於資料庫優化分可以以下幾個方面來講
先說幾個小的注意點
當表中無主鍵時，首先判斷表中是否有非空的整形唯一索引，如果有，則該列為主鍵，如果不符合上述條件,innodb儲存引擎自動建立乙個6byte自增主鍵，且_rowid無法被查詢到，如果使用int型別自增主鍵為4byte，所以在建立表時，必選顯式地指定主鍵
我們平時使用的mysql的引擎時innodb，是mysql四種引擎中唯一支援事務的
一張表有且只有乙個聚集索引就是主鍵
最左匹配原則
離散型、選擇性最好的列放在最左邊
mysql索引底層實現是b+tree
1、可視情況開啟快取查詢，開啟快取查詢後，當表內資料和字段沒有變化時，相同sql查詢結果會從mysql快取中讀取，不會再次查詢可提高效率
tips：即使sql相同但編碼不同的查詢語句，也會被mysql認為是兩個查詢，會重新查詢
2、設定最大連線數，預設為100，最大為16384（超過的無效）
可根據實際業務需求適應儲存過程
sql語句的優化最主要的就是避免全表掃瞄
1、避免select * 的存在，會導致全表掃瞄，同時也會增加io負擔
2、在可以確定只存在乙個查詢結果或者判斷庫中有無符合條件資料時，使用limit 1來限定查詢結果，limit 1會在查詢到一條資訊後停止查詢返回結果，而不是繼續往後查詢下一條符合條件的資料，即使用select 1 from table where condition limit 1，來代替select count
3、like本身效率就比較低，所以應該盡量避免使用like，左like無法使用索引，右like可以
4、避免在where子句中對字段進行null判斷，使用null會導致全表掃瞄
5、在照顧到實際業務需求的同時，在where、order by和join涉及的列上建立索引
6、使用union all 代替 union，如果結果集允許重複的話，union會去重效率較低
總結sql 優化的實質就是了解優化器的工作原理，盡可能的使用符合優化器工作原理的sql和索引
為列選擇合適的資料型別
1、在varchar和char中選擇時，應盡量選擇char，定長字段查詢比可變長度欄位快，簡言之就是空間換時間
2、能用tinyint就不用smallint，能用smallint就不用int，磁碟和記憶體消耗越小越好
索引是幫助mysql更加高效獲取資料的資料結構，索引建立的應該遵循一下幾個原則
1、where後面匹配的索引關鍵字列越多越好，掃瞄的資料越精確越少越好（通過索引篩選出的資料越少越好）
2、避免再次排序
3、盡可能的使用覆蓋索引，減少回表操作
覆蓋索引
當sql語句的所求查詢字段（select列）和查詢條件字段（where子句）全都包含在乙個索引中（聯合索引），可以直接使用索引查詢而不需要回表。這就是覆蓋索引，通過使用覆蓋索引，可以減少搜尋樹的次數，這就是覆蓋索引，
同時在某些情況下會發生索引失效的問題，我們在查詢時應避免這些情況的發生
對索引列運算及使用聚合函式
or的左右需同時使用索引，如果只有or的左側或右側使用索引，也會導致索引失效
like以%開頭
索引列上使用!=、<>、not時會導致索引失效
資料型別發生隱式轉換時，varchar型別列的數字不加單引號可能會導致資料型別轉換
暫時不太了解，先按下不表
才疏學淺斗膽在此拋磚引玉，還望各路大神口下留情
資料庫優化 資料庫設計優化
一 索引優化 1.首先索引不是越多越好，要視情況而定。因為索引會降低insert和update的效率 insert和update有時可能會重建索引。2.乙個表的索參數量最好不要超過6個，擇優而建。3.專案上線後，根據使用者的查詢條件字段稍微調整資料庫中的字段索引。二 分表 1.縱切 根據表字段來且分...
資料庫引擎優化顧問優化資料庫
現在一直在做的專案，資料量相對也不小，開始的時候沒有覺得，因為是剛開始，資料量還很小，在程式使用過程中速度還挺快，但是隨著資料量的不停的增長，發現程式越來越慢，甚至出現了超時的問題，因此要對程式和資料庫進行優化，前期專案比較緊，沒有針對大資料量業務進行分析設計，所以索引等相關優化沒有做到位，通過後期...
資料庫優化
資料庫優化 1 合理使用索引 索引是資料庫中重要的資料結構，它的根本目的就是提高查詢效率。索引的使用要恰到好處，其使用原則如下 在經常進行連線，但是沒有指定為外來鍵的列上建立索引，而不經常連線的字段則由優化器自動生成索引 在頻繁進行排序或分組 即進行groupby或orderby操作 的列上建立索引...