innodb_buffer_pool_instances 引數，將 buffer pool 分成幾個區，每個區用獨立的鎖保護，這樣就減少了訪問 buffer pool 時需要上鎖的粒度，以提高效能。準備一個空資料庫，在這裡我們將 performance_schema_events_waits_history_long_size 調大，是為了讓之後實驗資料能採集的更多，在此不多做介紹。使用 sysbench，準備一些資料，

對資料進行預熱 60s，可以看到預熱期間的效能會不太穩定，預熱後會比較穩定，

設定 performance_schema，這次我們將僅開啟觀察項（生產者）hash_table_locks，並開啟 waits 相關收集端（消費者）。（相關介紹參看 實驗 03）

為什麼我們知道觀察項應該選擇 hash_table_locks？在 performance_schema.setup_instruments 表中，列出了所有觀察項，但我們很難從中選出我們應觀察哪個觀察項。這時候，可以將所有觀察項都啟用，然後設計一些對比實驗，比如使用幾種不同的 SQL，觀察這些操作影響了哪些觀察項，找到共性或者區。還有一種高效的方式是搜尋別人的經驗，或者閱讀 MySQL 原始碼。本例中 hash_table_locks 隱藏的比較深，使用了閱讀 MySQL 原始碼和對比試驗結合的方法。

只有當併發量較高，表較大（大於千萬的表）時，分表分割槽才能提高查詢效能，否則的話只要合理的使用索引即可提高查詢效能。

水平分表目的是把一個大表分成多個小表，最佳效果是把不同訪問頻率的資料儲存在不同的表裡。

特別是當不同資料的訪問頻率差異比較大時，更能體現分表的好處，因為表的體量小，索引層數小，佔空間小，查詢資料效率更高。

另外一個是不同的表可以更好的支援併發查詢，例如一個查詢查表1，同時可以支援併發查詢查表2，個鎖個的行，或個鎖個的表，互不影響，更不會出現死鎖，因此併發效能更好。

分割槽表是將表放在不同的磁碟扇區，降低單個磁碟I/O負載，因此可以提高查詢效率。