通常我們在項目中，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個。