mysql优化
优化方法：
软优化：
1、查询语句优化，可以使用explain查看sql语句的执行计划，查询的结果会显示索引和查询数据读取数据条数等信息
2、优化子查询，在mysql中尽量使用join代替子查询，因为子查询需要嵌套查询，嵌套查询会遍历一张临时表，临时表的建立和删除都会有较大的系统开销，连接查询不会创建临时表
3、分解表，对于字段较多的表，如果某些字段使用频率较低，将其分解出来，形成新的表
4、使用索引，注意点
- like关键字匹配‘%’开头的字符串，不会使用索引
- or，关键字的两个字段必须都是用了索引，该查询才会使用索引，否则索引失效
- 使用多列索引必须满足最左匹配，对于组合索引mysql会一直向右匹配直到遇到范围查找>,<,between,like就停止匹配，范围大了，有索引查询也会变慢
硬优化：
- 升级硬件
- 部署多个节点
- 系统配置文件的修改
系统配置文件
linux系统最大的文件打开数量（open files）
命令：ulimit -a
open files字段就是linux系统最大的文件打开数量,可以通过配置文件修改linux系统最大的文件打开数量，open files通常设定为65535。
修改方法：
在配置文件加上以下两行：
* soft nofile 65535
* hard nofile 65535
mysql文件打开数量
show VARIABLES like 'table_open_cache'
table_open_cache：设置表高速缓存的大小，默认值是64
show global status like 'open%tables';
open_tables:打开表的数量
opened_tables:打开过的表数量
当mysql没打开一个表，都会读入一些数据到table_open_cache缓存中，当mysql在这个缓存中找不到相应的信息时，才会去磁盘上直接读取
如果opened_tables数量过大，说明配置中table_open_cache值可能过小
比较合适的值：
Open_tables / Opened_tables >= 0.85
Open_tables / table_open_cache <= 0.95
MySQL打开的文件描述符
:show VARIABLES like 'open_files_limit'
open_files_limit = 65535
MySQL打开的文件描述符的限制
当open_files_limit没有被配置的时候，比较max_connections5和ulimit -n的值，哪个值大就用哪个
当open_files_limit被配置的时候，比较open_files_limit和max_connections5的值，哪个值大就用哪个
读写进程数的配置：
show variables like 'innodb_read_io%'
innodb_read_io_threads=5 #读的进程数
show variables like 'innodb_write_io%'
innodb_write_io_threads=6 #写的进程数
作用：innodb使用后台线程处理数据页上的读写I/O（输入输出）请求，根据实际CPU核数来更改，默认是4，可以比CPU核数稍微大一点
注意：
这两个参数不支持动态改变，需要把该参数加入配置文件my.cnf里，修改完后重启MySQL服务，允许值的范围是1～64
缓存优化
query_cache优化
指定MySQL查询缓冲区的大小
show variables like '%query_cache_%';
- “have_query_cache”：该MySQL 是否支持Query Cache；按实际情况YES 或 NO
- “query_cache_limit”：Query Cache 存放的单条Query 最大Result Set ，默认1M；
- “query_cache_min_res_unit”：Query Cache 每个Result Set 存放的最小内存大小，默认4k；
- “query_cache_size”：系统中用于Query Cache 内存的大小；默认为0，表示为查询缓存预留的内存为0，则无法使用查询缓存。所以我们需要设置query_cache_size的值（256M的内存）：
- “query_cache_type”：系统是否打开了Query Cache 功能；默认为OFF
Qcache优化
show status like 'Qcache%'；
- Qcache_free_blocks：如果该值非常大，则表明缓冲区中碎片很多。
- Qcache_free_memory：Query Cache 中目前剩余的内存大小。通过这个参数我们可以较为准确的观察出当前系统中的Query Cache 内存大小是否足够，是需要增加还是过多了；
- Qcache_hits：如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓冲;
- Qcache_inserts：多少次未命中然后插入。通过“Qcache_hits”和“Qcache_inserts”两个参数我们就可以算出Query Cache 的命中率了：Query Cache 命中率= Qcache_hits / ( Qcache_hits + Qcache_inserts )；
- Qcache_lowmem_prunes：多少条Query 因为内存不足而被清除出Query Cache。
- Qcache_not_cached：因为query_cache_type 的设置或者不能被cache 的Query 的数量；
- Qcache_queries_in_cache：当前Query Cache 中cache 的Query 数量；
- Qcache_total_blocks：当前Query Cache 中的block 数量；
mysql连接数
查看mysql允许的最大连接数
show VARIABLES like 'max_connections'
查看实际达到过的最大连接数
show global status like 'Max_used_connections'
建议配置：
Max_used_connections/max_connections =0.85
项目的连接池：
/data/apache-tomcat-8.5.50/webapps/app/WEB-INF/classes
vim application.properties
jdbc.pool.maxIdle
如果在并发时达到了maxActive=40，那么连接池就必须从数据库中获取40个连接来供应用程序使用，当应用程序关闭连接后，由于maxIdle=5,因此并不是所有的连接都会归还给数据库，将会有5个连接保持在连接池种中，状态为空闲。
jdbc.pool.maxActive
表示并发情况下最大可从连接池中获取的连接数。
如果慢查询日志没有打印了，可以将配置文件的：
general_log=on
log_output=table
注释后，重启mysql
Tomcat-Jdbc-Pool配置及性能调优参考
https://blog.csdn.net/fengzhou0920/article/details/70156011
架构的优化：
back_log:
mysql能有的连接数量
back_log值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。也就是说，如果MySql的连接数达到max_connections时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即back_log，如果等待连接的数量超过back_log,就会不让连接，抛出错误信息
back_log值不能超过TCP/IP连接的侦听队列的大小
查看back_log：show VARIABLES like 'back_log'
innodb_buffer_pool_size（默认128M）：
innodb缓冲池，大的缓冲池可以减小多次磁盘I/O访问相同的表数据，在专用数据库服务器上，可以将缓冲池大小设置为服务器物理内存的80%
查看命令：show VARIABLES like 'innodb_buffer_pool_size'
建议配置：
缓冲池=innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的倍数
备注：
若缓冲池的大小不等于
innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的倍数，系统将自动将缓冲池变为
innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的倍数
innodb_log_file_size
数据日志的大小，以M为单位
innodb_log_buffer_size
确定日志文件所有的内存大小，以M为单位，建议配置1~8之间
innodb_flush_log_at_trx_commit=(0,1,2)
- 0:log buffer将每秒一次地写入log file中，并且log file的flush(刷到磁盘)操作同时进行。该模式下在事务提交的时候，不做任何操作
- 1：每次提交事务的时候，都会将log_buffer写到日志，并且刷新到磁盘中去
- 2：提交事务都会写日志，但不会执行刷新的操作，每秒定时会刷到日志文件，并不能保证100%刷新，要取决于进程的调度
利弊：
- 0：要求高性能，高并发写的日志服务器
- 1：是最安全的，但是性能是最差的
- 2：对数据的一致性和完整性要求不高，可以设置为2
主从复制的流程：
- master将改记录到二进制日志事件
- slave将master的二进制日志事件，拷贝到它的中继日志
- slave重做中继日志中的事件，将改变反映成它自己的数据
