mysql死磕30天第二天

索引优化单独放到后面讲。

查询性能优化

设计最优的库表结构,建立最好的索引,这些对于高总能来说是必不可少的,但是这些还不够,还需要合理的设计查询。

查询优化,索引优化,库表结构优化需要起头并进,一个不落。在活动编写mysql查询经验的同时,也将学习到如何为高效率的查询设计表和索引。同样也可以学习到在优化库表结构时会影响到哪些类型的查询。

6.1为什么查询速度会慢

查询时候真正重要的是响应时间。如果把查询看作是一个任务,那么它由一系列子任务组成,每个子任务都会消耗一定的时间。如果要优化查询,实际上要优化其子任务,要么消除子任务,要么减少子任务的执行次数,要么让子任务运行的更快。

6.2满查询基础:优化数据访问

查询性能地下的最基本的原因是访问的数据太多。对于低效的查询,我们常常可以采取一下2个步骤来分析

1确认应用程序是否在检索大量超过需要的数据,这通常意味着访问了太多的行,但有时候也可能是访问了太多的列。

2确认mysql服务器是否在分析大量超过需要的数据航。

6.2.1是否向数据库请求了不需要的数据

有些查询会请求超过实际需要的数据,然后这些多余的数据会被应用程序丢弃,这会给mysql服务求带来额外的负担,并增加网络开销,另外也会消耗应用服务器的cpu和内存资源。

6.2.2 mysql是否在扫描额外的记录

再确定查询只返回需要的数据以后,接下来应该看看为了返回结果是否扫描了过多的数据。对于mysql 最简单的衡量查询开销的三个指标如下

响应时间

扫描行数

返回行数

这三个指标都会记录在mysql的慢日志中,所以检查慢日志记录是找出扫描行数过多的查询的好办法。

6.4重构查询的方式

6.3.1 一个复杂查询还是多个简单查询

6.3.2切分查询

有时候对一个大查询我们需要分而治之,将大查询分成下查询,每个查询功能完全一样,只完成一小部分,每次只返回小部分查询结果。