back_log如果同一时间连接的线程超过了max_connections，超出的部分并不会立即拒绝连接，而是被放入到一个等待主线程处理的堆栈中，超出back_log数量的连接将会直接被拒绝。
max_connections有些时候实例被大量连接堵住，新的进不来。这个时候一般不用调大这个参数，而是考虑看看风暴连接产生的原因，再看看有没有长期睡眠状态的连接，杀掉这些连接
wait_timeout这个对应上面睡眠连接的最大时长，一般把这个缩短会可以比较好的解决上面的问题，但是也要实际业务情况。不能贸然修改的很小
max_user_connection单用户同时可以连接的最大线程数
innodb_file_per_table每个表单独存放为一个文件，这个对备份或者恢复都比较方便，一定要开启
skip_name_resolve生产环境中使用纯IP连接时，启用此参数或许可以减少域名解析的开销或者延时。而且这种情况下，使用域名或者主机名创建的用户可能无法连接
no-auto-rehashmysql客户端连接时不主动获取实例的库表等元信息，获取库表元信息是个比较慢，而且有开销和阻塞风险的操作
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实例，还有UPDATE_BUFFER,INSERT_BUFFER一类的，适当调大就可以了
innodb_autoinc_lock_mode自增锁模式，对于load data（包括：INSERT … SELECT, REPLACE … SELECT）场景下会使用自增表锁，这样会则可能导致应用在并发导入数据出现死锁。建议将参数设置改为2，则表示所有情况插入都使用轻量级别的mutex锁(只针对row模式)，这样就可以避免auto_inc的死锁，同时在INSERT … SELECT 的场景下会提升很大的性能（注意该参数设置为2，binlog的格式需要设置为row）。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
