通常我們在項目中,MySql遇到瓶頸有幾大因素。
1. 記錄條數。
2. 數據特性。
3. 操作時機。
4. 熱點數據。
5. 配置。
6. 硬件。
下面針對這6大因素說一下常見的優化、配置。
1. 記錄條數
當表大小小於InnoDB_buffer_pool時,增提性能會隨着表記錄增加而略微降低性能。但不會降低很多,總體性能差別不大。
當表大小大於InnoDB_buffer_pool時,性能會急劇下降。此時磁盤IO成爲了性能下降的主要因素。
因此得到結論,表記錄數本身對應能影響不大。關鍵在於表的大小是否小於Innodb_buffer_pool。
2. 數據特性
理論上說NT比CHAR更快。原因是iNT運算更快,長度更短。
但通過實際測試得出,INT比CHAR更快的原因還是因爲更短,減少了磁盤空間與磁盤IO。從而性能高。 (長度纔是關鍵)
理論上說char比varchar速度快。
但在實際項目中在字段長度在120-220 之間,把char、varchar都設置220長度時,varchar的性能高於char。 原因是varchar能節省磁盤空間,內容更短,所以性能更高。 (可以得到結論,當需要存儲指定長度的內容時使用char是最佳選擇,而當內容長度不一致時,varchar纔是最佳選擇。)
key的長度越長,表就越大。當表大於Innodb_buffer_pool時,性能下降明顯。 主鍵對錶大小影響很明顯,因爲InnoDB把主鍵當做行標識。沒個索引都會存放主鍵,主鍵越大,索引越大。
3. 操作時機
初始值: MySQLInnoDB需要將數據從磁盤載入內存
穩定值:數據已經完成從磁盤載入到內存的操作
初始值主要是磁盤操作,表大小和磁盤IO速度成爲了影響性能的關鍵因素
穩定值主要是內存操作,內存大小成爲影響性能的關鍵。
如果一個業務剛上線時,爲了讓性能更好,可以 select * 或select count(*) 把數據寫入到內存,這樣當業務來後,性能會好。
4. 熱點數據
5. 配置
sync_binlog : 執行多少條操作後寫入binlog日誌。 通常設置爲 1,而高性能時設置的值越大性能越高,但也要根據binlog的需求適當來設置。 這裏推薦100。
InnoDB_flush_log_at_trx_commit : 事務日誌刷盤。 值爲 1時,當執行事務後立刻寫入日誌,值爲 2時,當積攢到一定量時再刷盤。 通常設置爲1,而高性能時設置爲 2.
在查詢操作時,上面兩項配置對性能是沒有任何影響的,因爲查詢操作並不寫日誌。
當表大小大於InnoDB_buffer_pool時,上面兩種配置區別也並不大,因爲InnoDB_buffer_pool不能把這個表都放到內存中。
當innodb日誌文件和數據文件在同一磁盤時,性能下降會很明顯。 原因相信大家也都能猜到是“IO瓶頸”。
當innodb日誌文件配置的太小時,性能下降也會非常明顯,原因是頻繁的checkpoint。 推薦把日誌文件設置成200M,配置3個。