MySQL效能優化之高階篇

2021-10-04 11:38:30 字數 2991 閱讀 5409

4.1、索引是什麼,建立索引的原因

索引用於快速找出在某個列中有一特定值的行,不使用索引mysql必須從第一條記錄開始讀完整個表,直到找出相關的行,表越大查詢資料所花費的時間就越多,如果表中查詢的列有乙個索引,mysql能夠快速到達乙個位置去搜尋資料檔案,而不必檢視所有資料,那麼將會節省很大一部分時間。

例如:有一張person表,其中有 2w 條記錄,記錄著2w個人的資訊。有乙個phone的字段記錄每個人的**號碼,現在想要查詢出**號碼為***x的人的資訊。

如果沒有索引,那麼將從表中第一條記錄一條條往下遍歷,直到找到該條資訊為止。

如果有了索引,那麼會將該phone欄位,通過一定的方法進行儲存,好讓查詢該字段上的資訊時,能夠快速找到對應的資料,而不必在遍歷2w條資料了。其中mysql中的索引的儲存型別有兩種:btree、hash。 也就是用樹或者hash值來儲存該欄位,要知道其中詳細是如何查詢的,需要一定的演算法知識了。

4.2、索引的優點和缺點

優點:所有的 mysql 列型別(字段型別)都可以被索引,也就是可以給任意字段設定索引

大大加快資料的查詢速度

缺點:建立索引和維護索引要耗費時間,並且隨著資料量的增加所耗費的時間也會增加

索引也需要佔空間,我們知道資料表中的資料也會有最大上線設定的,如果我們有大量的索引,索引檔案可能會比資料檔案更快達到上線值

當對表中的資料進行增加、刪除、修改時,索引也需要動態的維護,降低了資料的維護速度。

4.3、使用原則

通過上面說的優點和缺點,我們應該可以知道,並不是每個字段度設定索引就好,也不是索引越多越好,而是需要自己合理的使用:

並不是所有索引對查詢都有效。

並不是所有索引對查詢都有效,sql是根據表中資料來進行查詢優化的,當索引列有大量資料重複時,sql查詢可能不會去利用索引,如一表中有字段***,male、female幾乎各一半,那麼即使在***上建了索引也對查詢效率起不了作用。

索引並不是越多越好。索引固然可以提高相應的select的效率,但同時也降低了insert及update的效率,因為insert或update時有可能會重建索引,所以怎樣建索引需要慎重考慮,視具體情況而定。乙個表的索引數較好不要超過6個,若太多則應考慮一些不常使用到的列上建的索引是否有必要。

對經常更新的表就避免對其進行過多的索引,對經常用於查詢的字段應該建立索引。

資料量小的表最好不要使用索引,因為由於資料較少,可能查詢全部資料花費的時間比遍歷索引的時間還要短,索引就可能不會產生優化效果。

在一不同值少的列上(欄位上)不要建立索引,比如在學生表的"性別"欄位上只有男,女兩個不同值。相反的,在乙個欄位上不同值較多可以根據需要建立索引。

根據業務需求建立索引索引的建立要根據業務特點進行,不能憑空想象的設定索引。經常作為查詢條件的列才有建立索引的必要性。

4.4、索引優化口訣

???全值匹配我最愛,最左字首要遵守;

帶頭大哥不能死,中間兄弟不能斷;

索引列上少計算,範圍之後全失效;

like 百分寫最右,覆蓋索引不寫星;

不等空值還有 or,索引失效要少用。

5.1、永遠為每張表設定乙個id

為資料庫裡的每張表都設定乙個id做為其主鍵,而且最好的是乙個int型的(推薦使用unsigned),並設定上自動增加的auto_increment標誌。

5.2、有限字段使用enum而不是varchar

5.3、盡可能的使用not null

除非你有乙個很特別的原因去使用null值,你應該總是讓你的字段保持not null。

6.1、使用innodb儲存引擎

innodb引擎已經在多方面超越了myisam引擎,沒有特殊需求的情況下建議選擇innodb引擎

6.2、讓innodb使用全部記憶體

innodb_buffer_pool_size引數指定了innodb可以使用的記憶體總量。建議設定為物理記憶體的80%,因為要給作業系統留有空間。

如果你的記憶體是 32gb,可以設定為大約 25gb

innodb_buffer_pool_size =

25600m

注意:

如果值小於 1gb,說明真的應該公升級伺服器了

如果記憶體特別大,例如200gb,就不必給作業系統留20%了,因為os用不了40gb。

6.3、讓innodb多例項

innodb_buffer_pool_size的值大於1g時,innodb_buffer_pool_instances會把innodb的快取池劃分成多個例項。

多個緩衝池的好處:多個執行緒同時訪問緩衝池時可能會遇到瓶頸,而多個緩衝池則可以最小化這個衝突官方建議的buffer數量:每個buffer pool例項至少要1g

6.4、加大max_length_for_sort_data引數的設定

在mysql中,排序演算法分為兩種。

一是只載入排序欄位到記憶體,排序完成後再到表中取其他字段,二是載入所有需要的字段到記憶體。

顯然第二種節省了 io 操作,所以更快。

決定使用哪種演算法是通過引數max_length_for_sort_data來決定的,當所有返回欄位的最大長度小於這個引數值時,mysql就會選擇第二種演算法,反之使用第一種。

所以,如果有充足的記憶體讓mysql存放須要返回的非排序字段,就可以加大這個引數的值來讓mysql選擇第二種排序演算法。

當記憶體不是很充裕時,不能簡單地通過強行加大上面的引數來強迫 mysql 去使用高效演算法,否則可能會造成mysql不得不將資料分成很多段,然後進行排序,這樣可能會得不償失,此時就須要去掉不必要的返回字段,讓返回結果長度適應max_length_for_sort_data引數的限制。

6.5、增大sort_buffer_size引數設定

增大sort_buffer_size並不是為了讓mysql選擇第二種排序演算法,而是為了讓mysql儘量減少在排序過程中對須要排序的資料進行分段,因為分段會造成mysql不得不使用臨時表來進行交換排序。

6.6、開啟查詢快取

充分利用mysql的查詢快取機制,業務中很多sql都會重複執行的,當然現在很多資料層框架中也有快取功能,但資料層框架中的快取屬於應用級別的,在資料被外部更新時會導致快取資料過期問題。

list之高階篇

自己模擬實現的list include include include using namespace std 模擬實現list 雙向帶頭節點鍊錶 定義乙個list節點 template struct listnode template struct myiterator 注意,迭代器只是為了訪問容...

mysql容器效能優化 MySQL高階 效能優化

1.應用優化 1.1 使用資料庫連線池 使用資料庫連線池,避免資料庫連線頻繁的建立和銷毀,進而減少資源的消耗,提高資料庫的訪問效能。1.2 減少對mysql的訪問 1.2.1 避免資料重複檢索 能一次檢索獲取到結果,就不要進行倆次檢索,減少對資料庫的無用重請求。1.2.2 增加cache層 增加快取...

MySQL高階效能優化 效能分析

是指資料庫表的每一列都是不可分割的基本資料項,同一列不能有多個值。第一正規化 1nf 是對關係模式的基本要求,不滿足第一正規化的資料庫就不是關聯式資料庫 要求資料庫表中的每個例項或行必須可以被唯一的區分。設定主鍵來區分 要求乙個資料庫表中不包括已在其它表中已包含的非主關鍵資訊。兩張表不要重複的字段,...