可用性

back_log

如果同一时间连接的线程超过了max_connections，超出的部分并不会立即拒绝连接，而是被放入到一个等待主线程处理的堆栈中，超出back_log数量的连接将会直接被拒绝。

贺州ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：13518219792（备注：SSL证书合作）期待与您的合作！

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）。

参考阅读

• RDS参数调优

当前题目：【MySQL】值得关注的参数
本文来源：http://ybzwz.com/article/pgecip.html