个人网站做废品回收,深圳社保个人网页登录,电商型网站是否是趋势,招聘网站上找在家做查询性能优化
慢查询基础:优化数据访问
查询性能低下最基本的原因是访问的数据太多。某些查询可能不可避免地需要筛选大量数据#xff0c;但这并不场景。大部分性能低下的查询都可以通过减少访问的数据量的方式进行优化。对于低效的查询#xff0c;我们发现通过下面两个步骤…查询性能优化
慢查询基础:优化数据访问
查询性能低下最基本的原因是访问的数据太多。某些查询可能不可避免地需要筛选大量数据但这并不场景。大部分性能低下的查询都可以通过减少访问的数据量的方式进行优化。对于低效的查询我们发现通过下面两个步骤来分析总是很有效:
1.确认应用程序是否在检索大量超过需要的数据。这通常意味着访问了太多的行但有时候也可能是访问了太多的列2.确认MySQL服务器是否在分析大量超过需要的数据行
是否向数据库请求了不需要的数据。
有些查询会请求超过实际需要的数据然后这些多余的数据会被应用程序丢弃。这回给MySQL服务器带来额外的负担并增加网络开销(如果应用服务器和数据库不在同一台主机上网络开销就显得很明显了。即使在同一台服务器上仍然会有数据传输的开销)。另外也会消耗应用服务器的CPU和内存资源。下面是一些典型案例:
1.查询不需要的记录:一个常见的错误是常常误以为MySQL会只返回需要的数据实际上MySQL却是先返回全部结果集再进行计算。我们经常会看到一些了解其他数据库系统的人会设计出这类应用程序。这些开发者习惯适用这样的使用先使用SELECT语句查询大量的结果然后获取前面的N行后关闭结果集(例如在新闻网站中取出100条记录但是只是在页面上显示前面10条)。它们认为MySQL会执行查询并只返回它们需要的10条数据然后停止查询。实际情况是MySQL会查询出全部的结果集客户端的应用程序会接收全部的结果集数据然后抛弃其中大部分数据。最简单有效的解决方法就是在这样的查询后面加上LIMIT2.多表关联时返回全部列:如果你想查询所有在电影Academy Dinosaur中出现的演员千万不要按下面的写法编写查询:
mysql SELECT * FROM actor- INNER JOIN film_actor USING(actor_id)- INNER JOIN film USING(film_id)- WHERE film.titleAcademy Dinosaur;这将返回这三个表的全部数据列。正确的方式应该时像下面这样只取需要的列:
mysqlSELECT actor.* FROM actor .....3.总是取出全部列:每次看到SELECT * 的时候都需要用怀疑的眼光审视是不是真的需要返回全部的列很可能不是必需的。取出全部列会让优化器无法完成索引覆盖扫描这类优化还会为服务器带来额外的IO、内存和CPU的消耗。因此一些DBA是严格禁止SELECT * 的写法的这样做有时候还能避免某些列被修改带来的问题。当然查询返回超过需要的数据也不总是坏事。在许多案例中人们会说这种有点浪费数据库资源的方式可以简化开发因为能提高相同代码片段的复用性如果清除这样做的性能影响那么这种做法也是值得考虑的。如果应用程序使用了某种缓存机制或者有其他考虑获取超过需要的数据也可能有其他好处但不要忘记这样做的代价是什么。获取并缓存所有的列的查询相比多个独立的只获取部分列的查询可能就更有好处。4.重复查询相同的数据:如果你不太小心很容易出现这样的错误——不断地重复执行相同的查询然后每次都返回完全相同的数据。例如在用户评论的地方需要查询用户头像的URL,那么用户多次评论的时候可能就会反复查询这个数据。比较好的方案是当初次查询的时候将这个数据缓存起来需要的时候从缓存中取出这样性能显然会更好。
MySQL是否扫描额外的记录
在确定查询只返回需要的数据以后接下来应该看看查询为了返回结果是否扫描了许多的数据。对于MySQL最简单的衡量查询开销的三个指标如下: 1.响应时间 2.扫描的行数 3.返回的行数 没有哪个指标能够完美地衡量查询的开销但它们大致反映了MySQL在内部执行查询时需要访问多少数据并可以大概推算出查询运行的时间。这三个指标都会记录到MySQL的慢日志中所以检查慢日志记录是找出扫描行数过多的查询的好办法
响应时间
要记住 响应时间只是一个表面的值。这样说可能看起来和前面关于响应时间的说法有矛盾其实并不矛盾响应时间仍然是最重要的指标这有一点复杂后面细细道来。响应时间是两个部分之和:服务时间和排队时间。服务时间是指数据处理这个查询真正花了多长时间。排队时间是指服务器因为等待某些资源而没有真正执行查询的时间——可能是等待IO操作完成也可能是等待行锁等等。遗憾的是我们无法把响应时间细分到上面这些部分除非有什么办法能够逐个测量上面这些消耗不过很难做到一般最常见和重要的等待是IO和锁等待但实际情况更加复杂。所以在不同类型的应用压力下响应时间并没有什么一致的规律或者共识。诸如存储引擎的锁(表锁、行锁)、高并发资源竞争、硬件响应等诸多因素都会影响到响应时间。所以响应时间既可能是一个问题的结果也可能是一个问题的原因不同案例情况不同除非我们能深入测量出每个环节。 当你看到一个查询的响应时间的时候首先需要问问自己这个响应时间是否是一个合理的值。实际上可以使用快速上限估计法来估算查询的响应时间这是由Lahdenmaki和Mike Leach编写的Relational Database Index Design and the Optimizers一书中提到的技术。概括地说了解这个查询需要哪些索引以及它的执行计划是什么然后计算大概需要多少个顺序和随机IO再用其乘以在具体硬件条件下一次IO的消耗。最后把这些消耗都加起来就可以获得一个大概参考值来判断当前响应时间是不是一个合理得值
扫描的行数和返回的行数
分析查询时查看该查询扫描的行数时非常有帮助的。这在一定程度上能够说明该查询找到需要的数据的效率高不高。对于找出哪些糟糕的查询这个指标可能还不够完美因为并不是所有的行的访问代价都是相同的。较短的行的访问速度更快内存中的行也比磁盘中的行访问速度要快得多。理想情况下扫描得行数和返回的行数应该是相同的。但实际情况中这种美事并不多。例如在做一个管来奶查询时服务器必须要扫描多行才能生成结果集中的一行。扫描的行数对返回的行数的比率通常很小一般在1:1和10:1之间不过有时候这个值也可能非常非常大
扫描的行数和访问类型
在评估查询开销的时候需要考虑一下从表中找到某一行数据的成本。MySQL有好几种访问方式可以查找并返回一行结果。有些访问方式可能需要扫描很多行才能返回一行结果也有些访问方式可能无须扫描就能返回结果。在EXPLAIN语句中的type列反应了访问类型。访问类型有很多种从全表扫描到索引扫描、范围扫描、唯一索引查询、常数引用等。这里列的这些速度时从慢到快扫描的行数也是从多到少。你不需要记住这些访问类型但需要明白扫描表、扫描索引、范围访问和单值访问的概念.如果查询没有办法找到合适的访问类型那么解决的最好办法通常就是增加一个合适的索引。现在应该明白为什么索引对于查询优化如此重要了。索引让MySQL以最高效、扫描行数最少的方式找到需要的记录。例如我们看看示例库Sakila中的一个查询案例:
mysql SELECT * FROM film_actor WHERE film_id 1;
----------------------------------------
| actor_id | film_id | last_update |
----------------------------------------
| 1 | 1 | 2006-02-15 05:05:03 |
| 10 | 1 | 2006-02-15 05:05:03 |
| 20 | 1 | 2006-02-15 05:05:03 |
| 30 | 1 | 2006-02-15 05:05:03 |
| 40 | 1 | 2006-02-15 05:05:03 |
| 53 | 1 | 2006-02-15 05:05:03 |
| 108 | 1 | 2006-02-15 05:05:03 |
| 162 | 1 | 2006-02-15 05:05:03 |
| 188 | 1 | 2006-02-15 05:05:03 |
| 198 | 1 | 2006-02-15 05:05:03 |
----------------------------------------这个查询将返回10行数据从EXPLAIN的结果可以看到MySQL在索引idx_fk_film_id上使用了ref访问类型来执行查询:
mysql EXPLAIN SELECT * FROM film_actor WHERE film_id1\G
*************************** 1. row ***************************id: 1select_type: SIMPLEtable: film_actorpartitions: NULLtype: ref
possible_keys: idx_fk_film_idkey: idx_fk_film_idkey_len: 2ref: constrows: 10filtered: 100.00Extra: NULL
1 row in set, 1 warning (0.00 sec)EXPLAIN的结果也显示MySQL预估需要访问10行数据。换句话说查询优化器认为这种访问类型可以高效地完成查询。如果没有合适地索引会怎样呢MySQL就不得不使用一种更糟糕地访问类型下面我们来看看如果我们删除对应的索引再来运行这个查询:
mysql ALTER TABLE film_actor DROP FOREIGN KEY fk_film_actor_film;
Query OK, 0 rows affected (18.97 sec)
Records: 0 Duplicates: 0 Warnings: 0mysql ALTER TABLE film_actor DROP KEY idx_fk_film_id;
Query OK, 0 rows affected (0.03 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql EXPLAIN SELECT * FROM film_actor WHERE film_id1\G
*************************** 1. row ***************************id: 1select_type: SIMPLEtable: film_actorpartitions: NULLtype: ALL
possible_keys: NULLkey: NULLkey_len: NULLref: NULLrows: 5462filtered: 10.00Extra: Using where
1 row in set, 1 warning (0.00 sec)正如我们预测的访问类型变成了一个全表扫描(ALL)现在MySQL预估需要扫描5462条记录来完成这个查询。这里的Using Where表示MySQL将通过WHERE条件来筛选存储引擎返回的记录。一般MySQL能够使用如下三种方式应用WHERE条件从好到坏依次为:
1.在索引中使用WHERE条件来过滤不匹配的记录。这是在存储引擎层完成的2.使用索引覆盖扫描(在Extra列出现了Using index)来返回记录直接从素银中过滤不需要的记录并返回命中的结果。这是在MySQL服务器层完成的但无须再回表查询记录3.从数据表中返回数据然后过滤不满足条件的记录(在Extra列中出现Using WHere)。这在MySQL服务器层完成MySQL需要从数据表独处记录后过滤。 上面这个例子说明了好的索引多么重要。好的索引可以让查询使用合适的访问了悉尼港尽可能地只扫描需要的数据行。但也不是说增加索引就能让扫描的行数等于返回的行数。例如下面使用聚合函数COUNT()的查询:
mysql SELECT * FROM film_actor WHERE film_id 1;这个查询需要读取几千行数据但是仅返回200行结果。没有什么索引能够让这样的查询减少需要扫描的行数。不幸的是MySQL不会告诉我们生成结果实际上需要扫描多少行数据(例如关联查询结果返回的一条记录通常是由多条记录组成的)而只会告诉我们生成结果时一共扫描了多少行数据。扫描的行数中的大部分都很可能是被WHERE条件过滤掉的对最终结果集并没有贡献。在上面的例子中删除索引后看到MySQL需要扫描所有记录然后根据WHERE条件过滤最终只返回10行结果。理解一个查询需要扫描多少行和实际需要使用的行数需要先去理解这个查询背后的逻辑和思想。
如果发现查询需要扫描大量的数据但只返回少数的行那么通常可以尝试下面的技巧去优化它:
1.使用索引覆盖扫描把所有需要用的列都放到索引中这样存储引擎无须回表获取对应行就可以返回结果额2.改变库表结构。例如使用单独的汇总表3.重写这个复杂的查询让MySQL优化器能够以更优化的方式执行这个查询
