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
如果可以重启数据库开启，最好是重启开启，在线理论是可行，但是出现问题之后比较麻烦。
