可用性
back_log
如果同一時間連接的線程超過了max_connections，超出的部分並不會立即拒絕連接，而是被放入到一個等待主線程處理的堆棧中，超出back_log數量的連接將會直接被拒絕。
max_connections
有些時候實例被大量連接堵住，新的進不來。這個時候一般不用調大這個參數，而是考慮看看風暴連接產生的原因，再看看有沒有長期睡眠狀態的連接，殺掉這些連接
wait_timeout
這個對應上面睡眠連接的最大時長，一般把這個縮短會可以比較好的解決上面的問題，但是也要實際業務情況。不能貿然修改的很小
max_user_connection
單用戶同時可以連接的最大線程數
innodb_file_per_table
每個表單獨存放爲一個文件，這個對備份或者恢復都比較方便，一定要開啓
安全
skip_name_resolve
生產環境中使用純IP連接時，啓用此參數或許可以減少域名解析的開銷或者延時。而且這種情況下，使用域名或者主機名創建的用戶可能無法連接
性能
no-auto-rehash
mysql客戶端連接時不主動獲取實例的庫表等元信息，獲取庫表元信息是個比較慢，而且有開銷和阻塞風險的操作
innodb_io_capacity
告訴MySQL實例本機硬盤的性能情況，實例會根據此參數調整刷盤的某些策略
innodb_max_dirty_pages_pct
髒頁比，用於控制未落盤數據在IBP中的比例，如果DML語句比較頻繁的話，這裏適當提高，可以某種程度上提高性能，畢竟刷磁盤是個很慢的操作
innodb_lock_wait_timeout
鎖等待超時，這個可以適當減小，以避免垃圾事務的長時間持有數據鎖，阻塞其他請求線程
innodb_rollback_on_timeout
鎖等待超時後是否是否回滾掉整個事務，這裏建議開啓，默認只回滾掉事務中的最後一條語句，我認爲這樣可以減少鎖爭用。
internal_tmp_disk_storage_engine
內部臨時表的類型，這裏建議制定爲InnoDB，這個參數可以覆蓋掉默認引擎的對臨時表的染色。
innodb_stats_on_metadata
建議關掉，關掉之後不對內部元數據表的表信息進行統計收集。當然了，隱含條件是內部元數據信息表不落盤。
innodb_log_file_size
這個是指代內部重做日誌文件的大小,如果對實例重啓的時間有要求，那麼這個文件要設置的小一點。
IBP相關
這個就老生常談了，就是IBP大小，IBP實例，還有UPDATE_BUFFER,INSERT_BUFFER一類的，適當調大就可以了
innodb_autoinc_lock_mode
自增鎖模式，對於load data（包括：INSERT … SELECT, REPLACE … SELECT）場景下會使用自增表鎖，這樣會則可能導致應用在併發導入數據出現死鎖。建議將參數設置改爲2，則表示所有情況插入都使用輕量級別的mutex鎖(只針對row模式)，這樣就可以避免auto_inc的死鎖，同時在INSERT … SELECT 的場景下會提升很大的性能（注意該參數設置爲2，binlog的格式需要設置爲row）。