如何获取由性能问题的SQL
1、通过用户反馈获取存在性能问题的SQL
2、通过慢查日志获取存在性能问题的SQL
3、实时获取存在性能问题的SQL
使用慢查询日志获取有性能问题的SQL
slow_query_log 启动停止记录慢查日志
为on时时开启
通过脚本定时开关
slow_query_long_file 指定慢查日志的存储路径及文件
默认情况下保存在MySQL的数据目录中
日志存储和数据存储分开存储，如果可以存在不同的磁盘分区更好
long_query_time 指定记录慢查日志SQL执行时间的阀值
记录所有符合条件的SQL，包括查询语句，数据修改语句，已经回滚的SQL
默认为10秒，建议改为0.001秒也就是1毫秒可能比较合适
log_queries_not_using_indexes 是否记录未使用索引的SQL
常用的慢查日志分析工具(mysqldumpslow)
mysqldumpslow -s r -t 10 slow-mysql.log
-s order(c,t,l,r,at,al,ar) { c:总次数，t:总时间，l：锁的时间，r：总数据行
at,al,ar:t,l,r平均数
-t top 指定取前几条作为结束输出
使用慢查询日志获取有性能问题的SQL
常用的慢查日志分析工具(pt-query-digest)
pt-query-digest
--explain h=127.0.0.1 ,u=root,p=p@ssW-rd slow-mysql.log
如何实时获取有性能问题的SQL
information_schema 数据库中 processlist表
select id,'user','host',DB,command,'time',state,info from information_schema.PROCESSLIST where time >=60 查询执行时间大于60s的sql语句
查询速度为什么会慢
MySQL服务器处理查询请求的整个过程
1、客户端发送SQL请求给服务器
2、服务器检查是否可以在查询缓存中命中该SQL
3、服务器端进行SQL解析，预处理，再由优化器生成对应的执行计划
4、根据执行计划，调用存储引擎API来查询数据
5、将结果返回给客户端
优先检查这个查询是否命中查询缓存中的数据，通过一个对大小写敏感的hash查找实现的。
hash查找只能进行全值匹配。
命中缓存后,检查用户权限 直接从缓存中返回。不会解析sql
每次从缓存查询会加锁，对于一个读写频繁的系统使用查询缓存很可能会降低查询处理的效率。
query_cache_type 设置查询缓存是否可用
可以设置为ON,OFF,DEMAND
DEMAND表示只有在查询语句中使用SQL_CACHE和SQL_NO_CACHE来控制是否需要缓存
query_cache_size 设置查询缓存的内存大小
必须为1024的整数倍
query_cache_limit 设置查询缓存可用存储的最大值
加上SQL_NO_CACHE 可以提高效率
query_cache_wlock_invalidate
设置数据表被锁后是否返回缓存中的数据
query_cache_min_res_unit 设置查询缓存分配的内存块最小单位
会造成MySQL生成错误的执行计划的原因
1、统计信息不准确
2、执行计划中的成本估算不等同于实际的执行计划的成本
Mysql服务器层并不知道哪些页面在内存中
哪些页面在磁盘上，哪些需要顺序读取，哪些页面要随机读取
3、Mysql优化器所认为的最优可能与你所认为的最优不一样
4、MySQL从不考虑其他并发的查询，这可能会影响当前查询的速度
5、MySQL有时候也会基于一些固定的规则来生成执行计划
6、MySQL不会考虑不受其控制的成本
例：存储过程，用户自定义的函数
MySQL优化器可优化的SQL类型
1、重新定义表的关联顺序
优化器会根据统计信息来决定表的关联顺序
2、将外连接转化为内连接
where条件和库表结构等
3、使用等价变换规则
(5=5 and a>5) 将被改写为a>5
4、优化count(),min(),和max()
select tables potimized away
优化器已经从执行计划中移除了该表，并以一个常数取而代之
5、将一个表达式转化为常数表达式
6、使用等价变换规则
7、子查询优化
把子查询转化为关联查询
8、提前终止查询
9、对in（）条件进行优化
如何确定查询处理各个阶段所消耗的时间
1、使用profile
set profiling=1;
启动profile 这是一个session级的配置
执行查询
show profiles;
查看每一个查询所消耗的总时间的信息
show profile for query N;
查询的每个阶段所消耗的时间
show profile cpu for query N;
查询包括cpu使用信息
已经不推荐使用profile了
2、使用performance_schema
5.6版本后建议启动这个功能
update setup_instruments set enabled='YES',TIMED='YES' where name like 'stage%';
update setup_consumers set enabled = 'YES' where name like ‘events%’
来启动所需要的监控和历史记录表的信息
启动后是全局有效的
优化SQL查询
大表的数据修改，最好要分批处理
1000万行记录的表中，删除/更新 100万行记录。一次只删除/更新5000行记录
每次修改之后 暂停几秒，给主从同步时间
如何修改大表的表结构
对表中的列的字段类型进行修改，改变字段的宽度时还是会锁表
无法解决主从数据库延迟的问题
在主服务器上创建新表，然后数据同步过去老表，然后增加触发器，增加排他锁，然后最后重命名新表，删除旧表。 缺点：操作复杂
使用pt-online-schema-change 工具
--alter='MODIFY c varchar(150) not null default '' --user=root --password=Password D=imooc,t=sbtest4 --chaset=utf8 --execute
如何优化not in 和<>查询
优化前:
select customer_id ,first_name,last_name ,email from customer where customer_id not in
(select customer_id from payment)
优化后：
select a.customer_id,a.first_name,a.last_name,a.email from customer a left join payment b on a.customer_id = b.customer_id where b.customer_id is null
使用汇总表优化查询
select count() from product_comment where product_id = 999
汇总表就是提前以要统计的数据进行汇总并记录到表中以备后续的查询使用
create table product_comment_cnt(product_id int , cnt int);
优化后
select sum(cnt) from ( select cnt from product_comment_cnt where product_id = 999 union all select count() from product_comment where product_id = 999 and timestr > DATE(now())) a
数据库如何分库分表
分库分表的几种方式
把一个实例中的多个数据库拆分到不同的实例
把一个库中的表分离到不同的数据库中
数据库分片前的准备
对一个库中的相关表进行水平拆分到不同实例的数据库中
如何选择分区键
1、分区键要能尽量避免跨分片查询的发生
2、分区键要能尽量使各个分片中的数据平均
如何存储无需分片的表
1、每个分片中存储一份相同的数据
2、使用额外的节点统一存储
如何在节点上部署分片
1、每个分片使用单一数据库，并且数据库名也相同
2、将多个分片存储在一个数据库中，并在表名上加入分片号后缀
3、在一个节点中部署多个数据库，每个数据库包含一个分片
如何分配分片中的数据
1、按分区键的Hash值取模来分配分片数据
2、按分区键的范围来分配分片数据
3、利用分区键和分片的映射表来分配分片数据
如何生成全局唯一ID
1、使用auto_increment_increment和auto_increment_offset参数
2、使用全局节点来生成ID
3、在redis等缓存服务器中创建全局ID
数据库监控：
数据库稳定性在一定程度上决定了系统的稳定性。
对什么进行监控：
1、对数据库服务可用性进行监控
数据库进程或是端口存在并不意味着数据库就是可用的
通过网络链接到数据库并且确定数据库是可以对外提供服务的
2、对数据库性能进行监控
QPS、TPS、并发线程
3、对主从复制进行监控
主从复制链路状态的监控
主从复制延迟的监控
定期的确认主从复制的数据是否一致
4、对服务器资源的监控
磁盘空间
服务器磁盘空间大并不意味着MySQL数据库服务能使用的空间就足够大
CPU的使用情况，内存的使用情况，Swap分区的使用情况以及网络IO的情况等。
