配置示例：2U6核48G内存
symbolic-links=0 sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION log_timestamps = SYSTEM explicit_defaults_for_timestamp=1 character-set-server = utf8 skip-name-resolve back_log = 300 max_connections = 3000 open_files_limit = 15000 table_open_cache = 2048 max_allowed_packet =128M sort_buffer_size = 256M join_buffer_size = 256M thread_cache_size = 500 query_cache_size = 256M query_cache_limit = 16M query_cache_type=1 innodb_buffer_pool_size = 34G innodb_read_io_threads=8 innodb_write_io_threads=8 innodb_thread_concurrency = 16 innodb_log_buffer_size =512M wait_timeout=28800 connect_timeout=60 max_connect_errors=300 interactive_timeout=28800 tmp_table_size=536870912 lower_case_table_names=1
一、back_log参数值:
由默认的50修改为500.（每个连接256kb, 占用：125M）
back_log=500
查看mysql 当前系统默认back_log值，命令：
show variables like 'back_log';
back_log值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。也就是说，如果MySql的连接数达到max_connections时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即back_log，如果等待连接的数量超过back_log，将不被授予连接资源。将会报：
unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待连接进程时.
back_log值不能超过TCP/IP连接的侦听队列的大小。若超过则无效，查看当前系统的TCP/IP连接的侦听队列的大小命令：cat /proc/sys/net/ipv4/tcp_max_syn_backlog，目前系统为1024。对于Linux系统推荐设置为大于512的整数。
修改系统内核参数，可以编辑/etc/sysctl.conf去调整它。如：net.ipv4.tcp_max_syn_backlog = 2048，改完后执行sysctl -p 让修改立即生效。
二、log_timestamps参数值：
log_timestamps 参数默认使用 UTC 时区，这样会使得日志中记录的时间比中国这边的慢了 8 个小时，导致查看日志不方便。修改为 SYSTEM 就能解决问题。
三、explicit_defaults_for_timestamp参数值：
如果我们在启动的时候在配置文件中指定了explicit_defaults_for_timestamp=1，MySQL会按照如下的方式处理TIMESTAMP列：
1）此时如果TIMESTAMP列没有显示的指定not null属性，那么默认的该列可以为null，此时向该列中插入null值时，会直接记录null，而不是current timestamp。
2）不会自动的为表中的第一个TIMESTAMP列加上DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP属性，除非你在建表的时候显示的指明。
3）如果TIMESTAMP列被加上了not null属性，并且没有指定默认值。这时如果向表中插入记录，但是没有给该TIMESTAMP列指定值的时候，如果strict sql_mode被指定了，那么会直接报错。如果strict sql_mode没有被指定，那么会向该列中插入’0000-00-00 00:00:00’并且产生一个warning。
这里为什么一直强调版本呢？主要还是因为这个参数explicit_defaults_for_timestamp在MySQL 5.6.6开始加入，并且MySQL 5.6跟MySQL 5.7的默认SQL模式不同了。MySQL 5.7的SQL模式更加严格了，限制了不合法的日期输入，比如”0000-00-00 00:00:00″。详情可以看：MySQL 5.7默认SQL模式带来的问题总结。
四、max_connections参数值：
MySQL的最大连接数，增加该值增加mysqld 要求的文件描述符的数量。如果服务器的并发连接请求量比较大，建议调高此值，以增加并行连接数量，当然这建立在机器能支撑的情况下，因为如果连接数越多，介于MySQL会为每个连接提供连接缓冲区，就会开销越多的内存，所以要适当调整该值，不能盲目提高设值。
数值过小会经常出现ERROR 1040: Too many connections错误，可以过’conn%’通配符查看当前状态的连接数量，以定夺该值的大小。
//最大连接数 show variables like 'max_connections' //响应的连接数 show status like 'max_used_connections'
max_used_connections / max_connections * 100% （理想值≈ 85%）
如果max_used_connections跟max_connections相同 那么就是max_connections设置过低或者超过服务器负载上限了，低于10%则设置过大。
MySQL的max_connections参数用来设置最大连接（用户）数。每个连接MySQL的用户均算作一个连接，max_connections的默认值为100。本文将讲解此参数的详细作用与性能影响。
五、open_files_limit参数值：
全局变量，不可动态调整，取值范围 0到65535。
open_files_limit指mysql能够打开的文件句柄数。该值不足时，会引发 Too many open files错误。具体需要多少个文件句柄，还需要根据 max_connections 和 table_open_cache来计算。
当open_files_limit没有被配置的时候，比较max_connections*5和ulimit -n的值，哪个大用哪个，当open_file_limit被配置的时候，
比较open_files_limit和max_connections*5的值，哪个大用哪个。
1、在Server层，整个mysqld实例打开文件总数超过用户进程级的文件数限制，需要检查内核 fs.file-max 限制、进程级限制 ulimit -n 及MySQL中的 open-files-limit 选项，是否有某一个超限了。任何一个条件超限了，就会抛出错误。
2、虽然Server层总文件数没有超，但InnoDB层也有限制，所有InnoDB相关文件打开总数不能超过 innodb-open-files 选项限制。否则的话，会先把最早打开的InnoDB文件描述符关闭，才能打开新的文件，但不会抛出错误，只有告警信息
相应地，如果提示超出限制，则可以使用下面方法提高上限：
1、首先，提高内核级总的限制。执行：sysctl -w fs.file-max=3264018；
2、其次，提高内核对用户进程级的打开文件数限制。执行：ulimit -n 204800；
3、最后，适当提高MySQL层的几个参数：open-files-limit、innodb-open-files、table-open-cache、table-definition-cache
用lsof去查看，理解myisam和innodb的文件描述符、OS 的ulimit相关认识。
lsof -p 26288 | wc -l
说明：too many files问题open_files_limit值更改无效
系统的值是正确的。然后修改/etc/my.cnf配置文件，添加
open_files_limit=65535
重启服务 之后 查看 show variables like '%open%'; 发现open_files_limit的值 还是1024
此时我们需要修改最后一个地方
vim /etc/systemd/system/mysql.service
在mysql.service中添加
LimitNOFILE=65535 #新加入的内容 添加在最后一行
重启服务服务，修改了mysql.server有可能需要systemctl daemon-reload
六、table_open_cache参数值：
table_open_cache指定表高速缓存的大小。每当MySQL访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。
通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加table_open_cache的值。
如果你发现open_tables等于table_open_cache，并且opened_tables在不断增长，那么你就需要增加table_open_cache的值了(上述状态值可通过SHOW GLOBAL STATUS LIKE ‘Open%tables’获得)。
注意，不能盲目地把table_open_cache设置成很大的值，设置太大超过了shell的文件描述符(通过ulimit -n查看)，造成文件描述符不足，从而造成性能不稳定或者连接失败。
测试环境：腾讯云CDB，内存4000M，在控制台查看到table_open_cache＝512，监测table_open_cache设置是否合理，是否需要优化。
发现open_tables等于table_open_cache，都是512，说明mysql正在将缓存的表释放以容纳新的表，此时可能需要加大table_open_cache的值，4G内存的机器，建议设置为2048
比较适合的值：
Open_tables / Opened_tables >= 0.85 Open_tables / table_open_cache <= 0.95
如果对此参数的把握不是很准，有个很保守的设置建议：把MySQL数据库放在生产环境中试运行一段时间，然后把参数的值调整得比Opened_tables的数值大一些，并且保证在比较高负载的极端条件下依然比Opened_tables略大。
七、max_allowed_packet参数值
mysql根据配置文件会限制server接受的数据包大小。
有时候大的插入和更新会被max_allowed_packet 参数限制掉，导致失败。
查看目前配置
show VARIABLES like '%max_allowed_packet%';
八、sort_buffer_size参数值：
1。 sort_buffer_size 是一个connection级参数，在每个connection第一次需要使用这个buffer的时候，一次性分配设置的内存。
2。 sort_buffer_size 并不是越大越好，由于是connection级的参数，过大的设置+高并发可能会耗尽系统内存资源。
3。 文档说“On Linux, there are thresholds of 256KB and 2MB where larger values may significantly slow down memory allocation”
mysql对于排序,使用了两个变量来控制sort_buffer_size和 max_length_for_sort_data, 不象oracle使用SGA控制. 这种方式的缺点是要单独控制,容易出现排序性能问题.
每个会话执行排序操作所分配的内存大小。想要增大max_sort_length参数，需要增大sort_buffer_size参数。如果在SHOW GLOBAL STATUS输出结果中看到每秒输出的Sort_merge_passes状态参数很大，可以考虑增大sort_buffer_size这个值来提高ORDER BY 和 GROUP BY的处理速度。建议设置为1~4MB。当个别会话需要执行大的排序操作时，在会话级别增大这个参数。
九、join_buffer_size参数值
mysql中每次join操作都会调用my_malloc、my_free函数申请/释放joib_buffer_size的大小的内存。
join_buffer_size是按照每次操作join表的操作的次数申请和释放joib_buffer_size.
MySQL服务器用来作普通索引扫描、范围索引扫描和不使用索引而执行全表扫描这些操作所用的缓存大小。通常，获取最快连接的方法是增加索引。当不能增加索引的时候，使全连接变快的方法是增大join_buffer_size参数。对于执行全连接的两张表，每张表都被分配一块连接内存。对于没有使用索引的多表复杂连接，需要多块连接内存。通常来说，可以将此参数在全局上设置一个较小的值，而在需要执行大连接的会话中在会话级别进行设置。默认值是256KB
十、thread_cache_size参数值：
MySQL服务缓存以重用的线程数。当客户端断开连接的时候，如果线程缓存没有使用满，则客户端的线程被放入缓存中。如果有客户端断开连接后再次连接到MySQL服务且线程在缓存中，则MySQL服务会优先使用缓存中的线程；如果线程缓存没有这些线程，则MySQL服务器会创建新的线程。如果数据库有很多的新连接，可以增加这个参数来提升性能。如果MySQL服务器每秒有上百个连接，可以增大thread_cache_size参数来使MySQL服务器使用缓存的线程。通过检查Connections和Threads_created状态参数，可以判断线程缓存是否足够。这个参数默认的值是由下面的公式来决定的：8 + (max_connections / 100)
建议将此参数设置为300~500。线程缓存的命中率计算公式为(1-thread_created/connections)*100%，可以通过这个公式来优化和调整thread_cache_size参数。
十一、query_cache_size参数值：
为查询结果所分配的缓存。默认这个参数是没有开启的。这个参数的值应设为整数的1024倍，如果设为其他值则会被自动调整为接近此数值的1024倍。这个参数最小需要40KB。建议不要将此参数设为大于256MB，以免占用太多的系统内存。
十二、query_cache_limit参数值：
query_cache_limit指定单个查询能够使用的缓冲区大小，缺省为1M。
十三、query_cache_type参数值：
设置查询缓存的类型。当这个参数为0或OFF时，则MySQL服务器不会启用查询缓存；当这个参数为1或ON时，则MySQL服务器会缓存所有查询结果（除了带有SELECT SQL_NO_CACHE的语句）；当这个参数为2或DEMAND时，则MySQL服务器只会缓存带有SELECT SQL_CACHE的语句。
十四、innodb_buffer_pool_size参数值：
innodb_buffer_pool_size默认大小为128M。最大值取决于CPU的架构。在32-bit平台上，最大值为2**32 -1,在64-bit平台上最大值为2**64-1。当缓冲池大小大于1G时，将innodb_buffer_pool_instances设置大于1的值可以提高服务器的可扩展性。大的缓冲池可以减小多次磁盘I/O访问相同的表数据。在专用数据库服务器上，可以将缓冲池大小设置为服务器物理内存的80%。
十五、innodb_read_io_threads及innodb_write_io_threads参数值：
innodb_read_io_threads和innodb_write_io_threads，取代了innodb_file_io_threads如此调整后，在Linux平台上就可以根据CPU核数来更改相应的参数值了，默认是4
假如CPU是2颗8核的，那么可以设置：
innodb_read_io_threads = 8 innodb_write_io_threads = 8
如果数据库的读操作比写操作多，那么可以设置：
innodb_read_io_threads = 10 innodb_write_io_threads = 6
也就是说，你可以根据情况加以设置。
十六、innodb_thread_concurrency参数值：
InnoDB存储引擎可以并发使用的最大线程数。当InnoDB使用的线程超过这参数的值时，后面的线程会进入等待状态，以先进先出的算法来处理。等待锁的线程不计入这个参数的值。这个参数的范围是0~1000。默认值是0。当这个参数为0时，代表InnoDB线程的并发数没有限制，这样会导致MySQL创建它所需要的尽可能多的线程。设置这个参数可以参考下面规则：
如果用户线程的并发数小于64，可以将这个参数设为0；
如果系统并发很严重，可以先将这个参数设为128，然后再逐渐将这个参数减小到96, 80, 64或其他数值，直到找到性能较好的一个数值。
十七、innodb_log_buffer_size参数值：
InnoDB写入磁盘日志文件所使用的缓存字节大小。如果innodb_page_size参数为32K，则默认值是8MB；如果innodb_page_size参数为64K，则默认值是16MB。如果日志的缓存设置较大，则MySQL在处理大事务时，在提交事务前无需向磁盘写入日志文件。建议设置此参数为4~8MB。
十八、wait_timeout参数值：
Mysql关闭非交互连接前的等待时间，单位是秒，默认是8小时，建议不要将该参数设置超过24小时，即86400
十九、max_connect_errors参数值：
max_connect_errors是一个MySQL中与安全有关的计数器值，它负责阻止过多尝试失败的客户端以防止暴力破解密码的情况。max_connect_errors的值与性能并无太大关系。
下面是针对16G内存的机器设置的6000，需要的朋友可以参考一下
max_connect_errors = 6000
#设置每个主机的连接请求异常中断的最大次数，当超过该次数，MYSQL服务器将禁止host的连接请求，直到mysql服务器重启或通过flush hosts命令清空此host的相关信息。
二十、interactive_timeout参数值：
在用mysql客户端对数据库进行操作时，打开终端窗口，如果一段时间没有操作，再次操作时，常常会报如下错误：
ERROR 2013 (HY000): Lost connection to MySQL server during query ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect...
这个报错信息就意味着当前的连接已经断开，需要重新建立连接。
那么，连接的时长是如何确认的？
其实，这个与interactive_timeout和wait_timeout的设置有关。
1> interactive_timeout针对交互式连接，wait_timeout针对非交互式连接。所谓的交互式连接，即在mysql_real_connect()函数中使用了CLIENT_INTERACTIVE选项。
说得直白一点，通过mysql客户端连接数据库是交互式连接，通过jdbc连接数据库是非交互式连接。
2> 在连接启动的时候，根据连接的类型，来确认会话变量wait_timeout的值是继承于全局变量wait_timeout，还是interactive_timeout。
总结：
1. 控制连接最大空闲时长的wait_timeout参数。
2. 对于非交互式连接，类似于jdbc连接，wait_timeout的值继承自服务器端全局变量wait_timeout。
对于交互式连接，类似于mysql客户单连接，wait_timeout的值继承自服务器端全局变量interactive_timeout。
3. 判断一个连接的空闲时间，可通过show processlist输出中Sleep状态的时间
二十一、tmp_table_size参数值：
内部内存临时表的最大内存。这个参数不会应用到用户创建的MEMORY表。如果内存临时表的大小超过了这个参数的值，则MySQL会自动将超出的部分转化为磁盘上的临时表。在MySQL 5.7.5版本，internal_tmp_disk_storage_engine存储引擎将作为磁盘临时表的默认引擎。在MySQL 5.7.5之前的版本，会使用MyISAM存储引擎。如果有很多的GROUP BY查询且系统内存充裕，可以考虑增大这个参数。
二十二、lower_case_table_names参数值：
lower_case_table_names 是mysql一个大小写敏感设置的属性
参数说明:
lower_case_table_names： 此参数不可以动态修改，必须重启数据库 lower_case_table_names = 1 表名存储在磁盘是小写的，但是比较的时候是不区分大小写 lower_case_table_names=0 表名存储为给定的大小和比较是区分大小写的 lower_case_table_names=2, 表名存储为给定的大小写但是比较的时候是小写的