RejectedExecutionHandler、MySQL性能优化

RejectedExecutionHandler类型

RejectedExecutionHandler            特性及效果
1.AbortPolicy：线程池默认的策略，如果元素添加到线程池失败，会抛出RejectedExecutionException异常

2.DiscardPolicy：如果添加失败，则放弃，并且不会抛出任何异常

3.DiscardOldestPolicy：如果添加到线程池失败，会将队列中最早添加的元素移除，再尝试添加，如果失败则按该策略不断重试

4.CallerRunsPolicy：如果添加失败，那么主线程会自己调用执行器中的execute方法来执行改任务

5.自定义：如果觉得以上几种策略都不合适，那么可以自定义符合场景的拒绝策略。需要实现
自定义义的RejectedExecutionHandler接口，并将自己的逻辑写在rejectedExecution方法内。

 

 

MySQL性能优化
学习目标:
●了解MySQL优化
●了解常见的优化思路
●了解查询优化
●了解索引优化
●了解存储优化
●了解数据库结构优化
●了解查询缓存等缓存优化

优化介绍
在进行优化讲解之前,先请大家记住不要听信你看到的关于优化的"绝对真理”,而应该是在实际的业务场景下通过测试来验证你关于执行计划以及响应时间的假设。本课程只是给大家提供一些优化方面的方向和思路 ,而具体业务场景的不同,使用的MySQL服务版本不同,都会使得优化方案的制定也不同。

MySQL介绍
MySQL凭借着出色的性能、低廉的成本、丰富的资源,已经成为绝大多数互联网公司的首选关系型数据库。可以看到Google , Facebook, Twitter, 百度，新浪，腾讯,淘宝,网易，久游等绝大多数互联网公司数据库都是用的MySQL数据库,甚至将其作为核心应用的数据库系统。

虽然性能出色,但所谓好马配好鞍”,如何能够更好的使用它,已经成为开发工程师的必修课,我们经常会从职位描述上看到诸如”精通MySQL". "SQL语句优化"、"了解数据库原理"等要求。我们知道一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,所以查询语句的优化显然是重中之重。

我们将这里进行一个较为全面的分析 ,让大家了解到MySQL的性能到底与哪些地方有关,以便于让大家寻找出其性能问题的根本原因,而尽可能清楚的知道该如何去优化自己的数据库。

优化要考虑的问题
注意:优化有风险,涉足需谨慎!

优化可能带来的问题
●优化不总是对一个单纯的环境进行,还很可能是一个复杂的已投产的系统!
●优化手段有很大的风险,一定要意识到和预见到!
●任何的技术可以解决一 个问题.但必然存在带来一个问题的风险!
●对于优化来说调优而带来的问题,控制在可接受的范围内才是有成果。
●保持现状或出现更差的情况都是失败!

优化的需求
●稳定性和业务可持续性，通常比性能更重要!
●优化不可避免涉及到变更。变更就有风险!
●优化使性能变好,维持和变差是等概率事件!
●优化应该是各部门协同,共同参与的工作,任何单一 部门都不能对数据库进行优化!
所以优化工作,是由业务需要驱使的! ! !

优化由谁参与
在进行数据库优化时，应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员、应用程序开发人员、硬件及系统管理员、存储管理员等，业务相关人员共同参与。

 
优化的思路
优化的方向
在数据库优化上有两个主要方向：即安全与性能。

              安全 ---> 数据安全性
              性能 ---> 数据的高性能访问
(主要是在性能优化方向进行介绍)

优化的维度
我们把数据库优化分为四个纬度：硬件，系统配置，数据库表结构，SQL及索引

1.硬件： CPU、内存、存储、网络设备等

2.系统配置： 服务器系统、数据库服务参数等

3.数据库表结构： 高可用、分库分表、读写分离、存储引擎、表设计等

4.Sql及索引： sql语句、索引使用等

从优化成本进行考虑：硬件>系统配置>数据库表结构>SQL及索引
从优化效果进行考虑：硬件<系统配置<数据库表结构<SQL及索引

数据库使用优化思路
本课程尽可能的全面介绍数据库的调优思路，但是在多数时候，我们进行调优不需要进行这么全面、大范围的调优，一般情况下，我们进行数据库层面的优化就可以了，那我们该如何调优的呢？

应急调优的思路：

针对突然的业务办理卡顿，无法进行正常的业务处理！需要立马解决的场景！
1.show processlist（查看链接session状态）
2.explain(分析查询计划)，show index from table（分析索引）
3.通过执行计划判断，索引问题（有没有、合不合理）或者语句本身问题
4.show status like '%lock%'; # 查询锁状态
5.SESSION_ID; # 杀掉有问题的session

常规调优的思路：

针对业务周期性的卡顿，例如在每天10-11点业务特别慢，但是还能够使用，过了这段时间就好了。

1.查看slowlog(慢查询日志)，分析slowlog，分析出查询慢的语句。
2.按照一定优先级，进行一个一个的排查所有慢语句。
3.分析top sql(影响最大的查询语句)，进行explain调试，查看语句执行时间。
4.通过结果调整索引或语句本身。

查询优化
MySQL查询流程
我们该如何进行sql优化呢， 首先我们需要知道，sql优化其实主要是解决查询的优化问题，所以我们先从数据库的查询开始入手，下面这幅图显示了查询的执行路径：

　① 客户端将查询发送到服务器；

　② 服务器检查查询缓存，如果找到了，就从缓存中返回结果，否则进行下一步。

　③ 服务器解析，预处理。

　④ 查询优化器优化查询

　⑤ 生成执行计划，执行引擎调用存储引擎API执行查询

　⑥服务器将结果发送回客户端。

1.查询缓存： 在解析一个查询语句之前，如果查询缓存是打开的，那么MySQL会优先检查这个查询是否命中查询缓存中的数据，如果命中缓存直接从缓存中拿到结果并返回给客户端。这种情况下，查询不会被解析，不用生成执行计划，不会被执行。

2.语法解析和预处理器： MySQL通过关键字将SQL语句进行解析，并生成一棵对应的“解析树”。MySQL解析器将使用MySQL语法规则验证和解析查询。

3.查询优化器： 语法书被校验合法后由优化器转成查询计划，一条语句可以有很多种执行方式，最后返回相同的结果。优化器的作用就是找到这其中最好的执行计划。

4.查询执行引擎： 在解析和优化阶段，MySQL将生成查询对应的执行计划，MySQL的查询执行引擎则根据这个执行计划来完成整个查询。最常使用的也是比较最多的引擎是MyISAM引擎和InnoDB引擎。mysql5.5开始的默认存储引擎已经变更为innodb了。

 

查询优化
sql是我们和数据库交流最重要的部分，所以我们在调优的时候，需要花费的大量时间就在sql调优上面。常见的分析手段有慢查询日志，EXPLAIN分析查询，通过定位分析性能的瓶颈，才能更好的优化数据库系统的性能。

慢查询
    1.慢查询日志开启
在配置文件my.cnf或my.ini中在[mysqld]一行下面加入两个配置参数
(my.cnf : linux操作系统的配置文件    my.ini : windowx操作系统的配置文件)
    log-slow-queries=/data/mysqldata/slow-query.log
    long_query_time=5
(log-slow-queries参数:为慢查询日志存放的位置，一般这个目录要有mysql的运行帐号的可写权限，一般都将这个目录设置为mysql的数据存放目录；
long_query_time=5 : 中的5表示查询超过五秒才记录；)

还可以在my.cnf或者my.ini中添加log-queries-not-using-indexes参数，表示记录下没有使用索引的查询。

2.慢查询分析
我们可以通过打开log文件查看得知哪些SQL执行效率低下 ，从日志中，可以发现查询时间超过5 秒的SQL，而小于5秒的没有出现在此日志中。

如果慢查询日志中记录内容很多，可以使用mysqldumpslow工具（MySQL客户端安装自带）来对慢查询日志进行分类汇总。mysqldumpslow对日志文件进行了分类汇总，显示汇总后摘要结果。

#进入log的存放目录，运行：
    [root@mysql_data]# mysqldumpslow slow-query.log
    Reading mysql slow query log fromslow-query.log
    Count: 2 Time=11.00s (22s) Lock=0.00s (0s)Rows=1.0 (2), root[root]@mysql
    select count(N) from t_user; 

#mysqldumpslow命令：/path/mysqldumpslow -s c -t 10/database/mysql/slow-query.log
    1.这会输出记录次数最多的10条SQL语句，其中：
    2.-s, 是表示按照何种方式排序，c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序，ac、at、al、ar，表示相应的倒叙
    3.-t, 是top n的意思，即为返回前面多少条的数据；
    4.-g, 后边可以写一个正则匹配模式，大小写不敏感的；

例如：

1./path/mysqldumpslow -s r -t 10/database/mysql/slow-log
得到返回记录集最多的10个查询。

2./path/mysqldumpslow -s t -t 10 -g “leftjoin” /database/mysql/slow-log
得到按照时间排序的前10条里面含有左连接的查询语句。

PS：使用mysqldumpslow命令可以非常明确的得到各种我们需要的查询语句，对MySQL查询语句的监控、分析、优化是MySQL优化非常重要的一步。开启慢查询日志后，由于日志记录操作，在一定程度上会占用CPU资源影响mysql的性能，但是可以阶段性开启来定位性能瓶颈。