查询慢的原因
网络 CPU IO 上下文切换 生成统计信息 锁等待时间
优化数据访问
- 查询性能低下的主要原因是访问的数据太多，某些查询不可避免的需要筛选大量的数据，我们可以通过减少访问数据量的方式进行优化
- 确认应用程序是否在检索大量超过需要的数据
- 确认mysql服务器层是否在分析大量超过需要的数据行
- 是否向数据库请求了不需要的数据
- 查询不需要的记录（我们常常会误以为mysql会只返回需要的数据，实际上mysql却是先返回全部结果再进行计算，在日常的开发习惯中，经常是先用select语句查询大量的结果，然后获取前面的N行后关闭结果集。优化方式是在查询后面添加limit）
- 多表关联时返回全部列
- 总是取出全部列（在公司的企业需求中，禁止使用select *,虽然这种方式能够简化开发，但是会影响查询的性能，所以尽量不要使用）
- 重复查询相同的数据（如果需要不断的重复执行相同的查询，且每次返回完全相同的数据，因此，基于这样的应用场景，我们可以将这部分数据缓存起来，这样的话能够提高查询效率）
查询缓存
在解析一个查询语句之前，如果查询缓存是打开的，那么mysql会优先检查这个查询是否命中查询缓存中的数据，如果查询恰好命中了查询缓存，那么会在返回结果之前会检查用户权限，如果权限没有问题，那么mysql会跳过所有的阶段，就直接从缓存中拿到结果并返回给客户端
查询优化处理
语法解析器和预处理
mysql通过关键字将SQL语句进行解析，并生成一颗解析树，mysql解析器将使用mysql语法规则验证和解析查询，例如验证使用使用了错误的关键字或者顺序是否正确等等，预处理器会进一步检查解析树是否合法，例如表名和列名是否存在，是否有歧义，还会验证权限等等
查询优化器
在很多情况下mysql会选择错误的执行计划，原因如下：
统计信息不准确（InnoDB因为其mvcc的架构，并不能维护一个数据表的行数的精确统计信息）
执行计划的成本估算不等同于实际执行的成本
（有时候某个执行计划虽然需要读取更多的页面，但是他的成本却更小，因为如果这些页面都是顺序读或者这些页面都已经在内存中的话，那么它的访问成本将很小，mysql层
面并不知道哪些页面在内存中，哪些在磁盘，所以查询之际执行过程中到底需要多少次IO是无法得知的）
mysql的最优可能跟你想的不一样（mysql的优化是基于成本模型的优化，但是有可能不是最快的优化）
mysql不考虑其他并发执行的查询
mysql不会考虑不受其控制的操作成本（执行存储过程或者用户自定义函数的成本）
优化器的优化策略
静态优化：直接对解析树进行分析，并完成优化
动态优化：动态优化与查询的上下文有关，也可能跟取值、索引对应的行数有关
mysql对查询的静态优化只需要一次，但对动态优化在每次执行时都需要重新评估
优化器的优化类型
重新定义关联表的顺序（数据表的关联并不总是按照在查询中指定的顺序进行，决定关联顺序是优化器很重要的功能）
将外连接转化成内连接，内连接的效率要高于外连接
使用等价变换规则，mysql可以使用一些等价变化来简化并规划表达式
优化count(),min(),max() （索引的列是否可以为空通常可以帮助mysql优化这类表达式：例如，要找到某一列的最小值，只需要查询索引的最左端的记录即可，不需要全文扫描比较）
预估并转化为常数表达式，当mysql检测到一个表达式可以转化为常数的时候，就会一直把该表达式作为常数进行处理
索引覆盖扫描，当索引中的列包含所有查询中需要使用的列的时候，可以使用覆盖索引
子查询优化
等值传播
若有收获，就点个赞吧
0 人点赞
