MySQL 5.7已經推出多年了，各家針對不同版本也梳理了不同的參數模板。
在實踐的過程中，也發現了一些潛在的問題，有些參數開始的時候沒有注意到，結果想開啟的時候發現是只讀變量，要生效只能等待下次重啟，這種代價對于數據庫高可用維護而言實在是太高了。所以需要提前規劃和修正。
在此我不會把所有的參數都列出來，而是列出來最近碰到的一些。
log_timestamps
如果發現有些日志的時間戳不大對勁，其實可以注意以下log_timestamps的參數設置，默認是UTC,我們可以改為SYSTEM，這樣就是和系統同步的方式了。這個參數可以在線修改。
extra_max_connections
extra_port
如果數據庫運維的時候碰到too many connections,但是你卻發現自己也連不上數據庫的時候，這種感覺就好比你是一個公交車司機，但是你卻擠不上公交車的絕望。如果給我一次機會，就一個連接也可以化解這種困境，什么，要重啟，你們DBA怎么就會重啟，其實我很擔心業務同學這么問。如果一切都在控制中，就不會這么被動了。
這個參數本身不是新參數，在MySQL 5.6.14引入，但是直到MySQL 5.7也是默認沒有打開的。所以我們需要關注這兩個參數，給自己留點后路。
這個參數是只讀變量，要修改后重啟數據庫生效。
secure_file_priv
這個參數和文件處理有關，在5.7中默認是NULL，即沒有開啟，這樣對于一些導出的SQL語句來說就不可用了。
比如：
select * from user into outfile '/tmp/user.csv'
這個參數如果設置為空串，就和5.6及以下版本兼容了。
secure_file_priv=''
innodb_deadlock_detect
這個參數是我們在版本規劃時的一個重點參考參數，這個參數是在5.7.15引進，有了這個參數，對于系統內的死鎖靈活開關，很多數據庫分支就是還專門定制了類似的功能，當然作為系統優化來說，關閉這個參數對于性能的提升比較明顯，作為日常監測問題還是需要的。
slave_parallel_type
slave_parallel_workers
MySQL的并行復制在5.7才算是有了本質的改變，需要注意下從庫的這兩個參數設置，默認slave_parallel_type不是LOGICAL_CLOCK,我們可以根據服務器的配置來開啟相應的并行度。
innodb_purge_threads
innodb_page_cleaners
這兩個參數原來是1，需要注意下已有的模板是不是做了固定，5.7中已經是4了。
半同步插件的改進也比較明顯，也需要關注下。
此外有幾個參數在性能負載不高的數據庫環境中根據需要可以使用。
innodb_buffer_pool_size
在線修改buffer pool大小，不建議放心使用，還是負載不高的時候試用。
在線開啟GTID
如果可以重啟數據庫開啟，最好是重啟開啟，在線理論是可行，但是出現問題之后比較麻煩。
