Sql查询优化
如何获取有性能问题的SQL
通过用户反馈获取存在性能问题的SQL
通过慢查日志获取存在性能问题的SQL
实时获取存在性能问题的SQL
慢查询日志：主要开销为磁盘IO和存储日志所需要的磁盘空间、存储日志要占据很大的内存
·slow_query_log 是否开启慢查询日志
·slow_query_log_file 指定慢查询日志的存储路径及文件
日志存储和数据存储是分开存储的
·slow_query_time 指定记录慢查询日志SQL执行的时间的伐值、
·slow_queries_not_using_indexes 是否记录未使用索引的SQL
慢查询日志中记录的内容：
1.用户信息
2.SQL执行的时间
3.锁的时间
4.SQL返回的数据行数
5.SQL扫描数据的的行数
6.以时间戳形式展示SQL执行的时间
7.执行的SQL
慢查询日志在很短的时间内就会生成大量的日志。因此人为的去检查慢查询日志是不现实的，所以我们必须要借助工具
常用的慢查询日志分析工具：
·mysqldumpslow
·pt-query-digest
通过慢查日志获取存在性能问题:
Information_schema数据库下水位processlist表
为什么查询会比较慢？
SQL的解析预处理及生成执行计划–SQL处理查询请求的整个过程
·客户端发送SQL请求给服务器
·服务器检查是否可以在查询缓存中命中该SQL
如果查询缓存是打开的：
1.优先检查这个查询是否命中查询缓存中的数据–通过一个对大小写敏感的hash查找实现的—hash查找只能进行全值匹配
2.检查用户权限，如何符合调剂而直接从缓存中拿到结果
如果查询缓存未启用或者未命中-----mysql依照这个执行计划和存储引擎进行交互
·服务器端进行SQL解析，预处理，在由优化器生成队形的执行计划
·根据执行计划，调用存储引擎API来查询数据
·将结果返回给客户端
会造成mysql生成错误的执行计划的原因
·统计信息不准确
·执行计划中的成本估算不等与实际的执行计划的成本
Mysql服务器层并不知道那些页面在内存中
那些页面在磁盘上 那些需要顺序读取
那些页面需要随机读取
·mysql优化器所认为的最优可能与你所认为的最优不一样
·mysql从不会考虑并发的查询，这可能影响当前的查询速度
·mysql有时候也会基于一些固定的规则来生成一些执行计划
·mysql不会考虑不受其控制的成本，存储过程，用户自定义的函数
Mysql优化器可优化的SQL类型：
·重新定义表的关联顺序
优化器会根据统计信息来决定表的关联顺序
·将外连接转化成内连接
where条件和库表结构等
·使用等价变化
·优化count(),min(),max()
select tables optimized away
优化器已经从执行计划中移除了该表，并以一个常数取而代之
·将一个表达式转化为常数表达式
·使用等价变化原则
·子查询进行优化
·提前终止查询
·对in()条件进行优化