《高性能mysql》笔记-查询性能优化总结

高性能mysql-查询性能优化-笔记

image

衡量查询性能的三个指标

  1. 返回的行数:意思是select返回的列数以及行记录数。
  2. 扫描的行数:查询所需要扫描的行数。
  3. 相应的时间:执行sql时间以及等待(sleep等待连接,lock等待锁的时间)

返回的行数

案例
1. 查询不需要的记录即多余的记录
2. 查询多余的列。很多时候为了方便直接select *,这样造成有些字段是不需要的也查询出来了。建议只查询出所需的字段。减少返回数据的大小,降低IO的压力
3. 重复查询相同的数据

优化方法
1. 采用索引覆盖以及延时索引
2. 重写查询

  • 采用复杂查询还是简单查询

  • 切分查询:将大的查询切分成小的查询。例如,delete数据多时,会造成锁住很多数据,占满了事务日志,造成后续的查询等待锁时间过长。如果切分成小的查询,减少了锁的竞争以及减少了对性能的影响。

  • 分解关联查询:将关联查询分解成多条简单查询。在过去会认为客户端连接性能较低,且解析优化的过程较长,所以一般会把多条简单的查询写成关联查询。但现在随着连接性能提高以及缓存效率的提高,将关联查询分解成多条简单查询,未尝不是件好事。分解后的优势在于:1.增加利用查询的缓存。2.减少了锁竞争。3.减少冗余数据的查询。4.扩展性提高

3.更改库表结构:
例如:采用单独的汇总表


扫描的行数

案例
1. 减少扫描的行数:例如当只查询一条数据记录时,若没有提示存储引擎,则扫描到了对应的记录数据后,还会继续扫描知道结束。解决办法是加上limit 1,提示只需要一条数据记录,就不会对继续扫描多余的行数。


响应时间

响应时间由等待时间和执行时间组成。要想了解时间都用在哪里,首先要知道执行语句过程中有哪些步骤。根据mysql逻辑结构分成三层,第一层是客户端与数据库的连接,第二层是服务器层,有解析、缓存、优化,第三层是存储引擎,负责数据的存储与读取。接下来会根据三层结构分析执行查询中有哪些步骤?

image

查询流程

image

  1. 客户端与服务区进行连接通信
  2. 服务器检查是否有缓存,缓存如果命中则,直接返回缓存中的结构。否则进行下一步
  3. 对sql进行解析预处理,再由优化器生成执行计划
  4. 根据执行计划,服务器调用存储引擎的API查询
  5. 得到数据则缓存并返回给客户端

查询状态

对于一个mysql连接,或者说一个县城,任何时刻都一个状态,该状态表示MYSQL当前正在做什么。有很多方式能查看当前的状态,最简单的是SHOW FULL PORCESSLIST命令。

  • Sleep
    线程等待客户端发送新的请求
  • Query
    线程正在查询或者正在将结果发给客户端
  • Locked
    线程等待锁释放
  • Analyzing and statistics
    线程正在收集存储引擎的统计信息
  • Copying to tmp table
    线程正在执行查询,并且将其结果集都复制到一个临时表中,这种状态一般要么是在做Group By操作,要么是文件排序操作,或者是UNION操作。若后面还有on disk标记,则表示临时表放在磁盘中
  • Sorting result
    线程正在对结果进行排序
  • Sending data
    表示多种情况,可能在多个状态之间发传输数据,或者在生成结果集,或者在向客户端返回数据

优化特定的查询

优化COUNT()查询

很多认为MYISAM存储引擎中的count(*)肯定比INNODB存储引擎中的count(*)快,其实不一定,当在无where条件的情况下,MYISAM中存储了count(*)的总数据数,所以这种时候MYISAM比INNODB快。但是在有where条件下的时候,可以是统计某个列值的数量时,MYISAM的COUNT()与其他引擎没有什么不同。
如果当要统计某个列值的数量时,建议直接count(*),而不是count(列字段)。这样的好处在于直接告诉存储引擎忽略所有列而直接统计所有行数。
使用近似值,如果总记录数不要求完全精确的话,比如统计网站当前活跃用户数以及搜索引擎的总条数。这样我们可以利用explain中的rows行数进行代替。

image

关联查询

  • 优化关联查询,要确保ON或者USING子句中的列上有索引
  • 建立索引时需要考虑到关联的顺序。通常来说,只需要在关联顺序中的第二个表的相应列上创建索引。例如,当表A和表B用列c关联的时候,假设关联的顺序是B、A,那么就不需要在B表的c列上建立索引。没有用到的索引只会带来额外的负担。
  • 确保任何的GROUP BY和ORDER BY中的表达式只涉及到一个表中的列,这样才能使用索引来优化这个过程

子查询

优化的建议尽可能的使用关联查询代替子查询

GROUP BY 和 DISTINCT

  • 对关联字段做分组效率高
  • WITH ROLLUP转移到应用程序中进行处理

LIMIT分页

当翻页到非常靠后页面的时候,偏移量会非常大,这是LIMIT的效率是非常差的。例如查询第50000,50020记录时,需要扫描50020条记录后返回结果,这样的效率是非常低的。优化方法如下:  
  • 利用上一页最后的主键做偏移。例如上述的例子,必须满足的是主键是连续且
SELECT * FROM sakila.rental where rental_id > 50000 DESC LIMIT 20;
  • 延时关联。利用索引覆盖先查找出主键,在通过主键查找对应的记录。尽可能的减少扫描的页面
SELECT film.film_id, film.description FROM sakila.film
INNER JOIN 
(SELECT film_id FROM sakila.film ORDER BY title LIMIT 50000,20) AS lim
USING(film_id);

返回的记录总数

  • 将总数替换成下一页按钮。假设每页显示20条记录,每次查询就增多一条即21条记录,如果有21条记录,则显示下一页,否则就说明没有更多的数据,无须显示下一页按钮
  • 将指定数量的数据缓存
  • 利用执行计划explain中的row

UNION查询

除非确实需要服务器消除重复的行,否则一定要使用UNION ALL。如果没有ALL关键字,MySql会给临时表加上DISTINCT选项,这会导致对整个临时表的数据做唯一性检查。这样做的代价非常高。

猜你喜欢

转载自blog.csdn.net/Yoga0301/article/details/81432183
今日推荐