0709关于mysql优化思路【何登成】
转自 http://isky000.com/database/mysql-performance-tuning-sql
- 优化目标
- 减少 IO 次数
IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段。 - 降低 CPU 计算
除了 IO 瓶颈之外,SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的数据比较运算)。当我们的 IO 优化做到一定阶段之后,降低 CPU 计算也就成为了我们 SQL 优化的重要目标
- 减少 IO 次数
- 优化方法
- 改变 SQL 执行计划
明确了优化目标之后,我们需要确定达到我们目标的方法。对于 SQL 语句来说,达到上述2个目标的方法其实只有一个,那就是改变 SQL 的执行计划,让他尽量“少走弯路”,尽量通过各种“捷径”来找到我们需要的数据,以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标
- 改变 SQL 执行计划
- 常见误区
- count(1)和count(primary_key) 优于 count(*)
很多人为了统计记录条数,就使用 count(1) 和 count(primary_key) 而不是 count(*) ,他们认为这样性能更好,其实这是一个误区。对于有些场景,这样做可能性能会更差,应为数据库对 count(*) 计数操作做了一些特别的优化。 - count(column) 和 count(*) 是一样的
这个误区甚至在很多的资深工程师或者是 DBA 中都普遍存在,很多人都会认为这是理所当然的。实际上,count(column) 和 count(*) 是一个完全不一样的操作,所代表的意义也完全不一样。
count(column) 是表示结果集中有多少个column字段不为空的记录
count(*) 是表示整个结果集有多少条记录 - select a,b from … 比 select a,b,c from … 可以让数据库访问更少的数据量【分不同的情况】
这个误区主要存在于大量的开发人员中,主要原因是对数据库的存储原理不是太了解。
实际上,大多数关系型数据库都是按照行(row)的方式存储,而数据存取操作都是以一个固定大小的IO单元(被称作 block 或者 page)为单位,一般为4KB,8KB… 大多数时候,每个IO单元中存储了多行,每行都是存储了该行的所有字段(lob等特殊类型字段除外)。
所以,我们是取一个字段还是多个字段,实际上数据库在表中需要访问的数据量其实是一样的。
当然,也有例外情况,那就是我们的这个查询在索引中就可以完成,也就是说当只取 a,b两个字段的时候,不需要回表,而c这个字段不在使用的索引中,需要回表取得其数据。在这样的情况下,二者的IO量会有较大差异。 - order by 一定需要排序操作
我们知道索引数据实际上是有序的,如果我们的需要的数据和某个索引的顺序一致,而且我们的查询又通过这个索引来执行,那么数据库一般会省略排序操作,而直接将数据返回,因为数据库知道数据已经满足我们的排序需求了。
实际上,利用索引来优化有排序需求的 SQL,是一个非常重要的优化手段
延伸阅读:MySQL ORDER BY 的实现分析 ,MySQL 中 GROUP BY 基本实现原理 以及 MySQL DISTINCT 的基本实现原理 这3篇文章中有更为深入的分析,尤其是第一篇 - 执行计划中有 filesort 就会进行磁盘文件排序
有这个误区其实并不能怪我们,而是因为 MySQL 开发者在用词方面的问题。filesort 是我们在使用 explain 命令查看一条 SQL 的执行计划的时候可能会看到在 “Extra” 一列显示的信息。
实际上,只要一条 SQL 语句需要进行排序操作,都会显示“Using filesort”,这并不表示就会有文件排序操作。
延伸阅读:理解 MySQL Explain 命令输出中的filesort,我在这里有更为详细的介绍
- count(1)和count(primary_key) 优于 count(*)
- 基本原则
- 尽量少 join
MySQL 的优势在于简单,但这在某些方面其实也是其劣势。MySQL 优化器效率高,但是由于其统计信息的量有限,优化器工作过程出现偏差的可能性也就更多。对于复杂的多表 Join,一方面由于其优化器受限,再者在 Join 这方面所下的功夫还不够,所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。但如果是简单的单表查询,这一差距就会极小甚至在有些场景下要优于这些数据库前辈。 - 尽量少排序
排序操作会消耗较多的 CPU 资源,所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL 的响应时间。
对于MySQL来说,减少排序有多种办法,比如:- 上面误区中提到的通过利用索引来排序的方式进行优化
- 减少参与排序的记录条数
- 非必要不对数据进行排序
- …
- 尽量避免 select *
很多人看到这一点后觉得比较难理解,上面不是在误区中刚刚说 select 子句中字段的多少并不会影响到读取的数据吗?
是的,大多数时候并不会影响到 IO 量,但是当我们还存在 order by 操作的时候,select 子句中的字段多少会在很大程度上影响到我们的排序效率,这一点可以通过我之前一篇介绍 MySQL ORDER BY 的实现分析 的文章中有较为详细的介绍。
此外,上面误区中不是也说了,只是大多数时候是不会影响到 IO 量,当我们的查询结果仅仅只需要在索引中就能找到的时候,还是会极大减少 IO 量的。 - 尽量用 join 代替子查询
虽然 Join 性能并不佳,但是和 MySQL 的子查询比起来还是有非常大的性能优势。MySQL 的子查询执行计划一直存在较大的问题,虽然这个问题已经存在多年,但是到目前已经发布的所有稳定版本中都普遍存在,一直没有太大改善。虽然官方也在很早就承认这一问题,并且承诺尽快解决,但是至少到目前为止我们还没有看到哪一个版本较好的解决了这一问题。 - 尽量少 or
当 where 子句中存在多个条件以“或”并存的时候,MySQL 的优化器并没有很好的解决其执行计划优化问题,再加上 MySQL 特有的 SQL 与 Storage 分层架构方式,造成了其性能比较低下,很多时候使用 union all 或者是union(必要的时候)的方式来代替“or”会得到更好的效果。 - 尽量用 union all 代替 union
union 和 union all 的差异主要是前者需要将两个(或者多个)结果集合并后再进行唯一性过滤操作,这就会涉及到排序,增加大量的 CPU 运算,加大资源消耗及延迟。所以当我们可以确认不可能出现重复结果集或者不在乎重复结果集的时候,尽量使用 union all 而不是 union。 - 尽量早过滤
这一优化策略其实最常见于索引的优化设计中(将过滤性更好的字段放得更靠前)。
在 SQL 编写中同样可以使用这一原则来优化一些 Join 的 SQL。比如我们在多个表进行分页数据查询的时候,我们最好是能够在一个表上先过滤好数据分好页,然后再用分好页的结果集与另外的表 Join,这样可以尽可能多的减少不必要的 IO 操作,大大节省 IO 操作所消耗的时间。 - 避免类型转换【通过EXPLAIN EXTENDED -SHOW WARNINGS查看】
这里所说的“类型转换”是指 where 子句中出现 column 字段的类型和传入的参数类型不一致的时候发生的类型转换:- 人为在column_name 上通过转换函数进行转换
直接导致 MySQL(实际上其他数据库也会有同样的问题)无法使用索引,如果非要转换,应该在传入的参数上进行转换 - 由数据库自己进行转换
如果我们传入的数据类型和字段类型不一致,同时我们又没有做任何类型转换处理,MySQL 可能会自己对我们的数据进行类型转换操作,也可能不进行处理而交由存储引擎去处理,这样一来,就会出现索引无法使用的情况而造成执行计划问题。
- 人为在column_name 上通过转换函数进行转换
- 优先优化高并发的 SQL,而不是执行频率低某些“大”SQL
对于破坏性来说,高并发的 SQL 总是会比低频率的来得大,因为高并发的 SQL 一旦出现问题,甚至不会给我们任何喘息的机会就会将系统压跨。而对于一些虽然需要消耗大量 IO 而且响应很慢的 SQL,由于频率低,即使遇到,最多就是让整个系统响应慢一点,但至少可能撑一会儿,让我们有缓冲的机会。 - 从全局出发优化,而不是片面调整
SQL 优化不能是单独针对某一个进行,而应充分考虑系统中所有的 SQL,尤其是在通过调整索引优化 SQL 的执行计划的时候,千万不能顾此失彼,因小失大。 - 尽可能对每一条运行在数据库中的SQL进行 explain
优化 SQL,需要做到心中有数,知道 SQL 的执行计划才能判断是否有优化余地,才能判断是否存在执行计划问题。在对数据库中运行的 SQL 进行了一段时间的优化之后,很明显的问题 SQL 可能已经很少了,大多都需要去发掘,这时候就需要进行大量的 explain 操作收集执行计划,并判断是否需要进行优化。
- 尽量少 join
0709关于mysql优化思路【何登成】的更多相关文章
- mysql优化思路
/* mysql优化思路 1.数据库设计 2.sql语句优化 3.数据库参数设置 4.恰当的硬件资源和操作系统 数据库设计 数据的3NF( ...
- 作为开发也要了解的 mysql 优化思路
作为开发人员,数据库知识掌握的可能不是很深入,但是一些基本的技能还是要有时间学习一下的.作为一个数据库菜鸟,厚着脸皮来总结一下 mysql 的基本的不能再基本的优化方法. 为了更好的说明,我假想出来了 ...
- mysql简单优化思路
mysql简单优化思路 作为开发人员,数据库知识掌握的可能不是很深入,但是一些基本的技能还是要有时间学习一下的.作为一个数据库菜鸟,厚着脸皮来总结一下 mysql 的基本的不能再基本的优化方法. 为了 ...
- 【公开课】【阿里在线技术峰会】何登成:AliSQL性能优化与功能突破的演进之路
MySQL的公开课,可能目前用不上这些,但是往往能在以后想解决方案的时候帮助到我.以下是阿里对公开课的整理 摘要: 本文根据阿里高级数据库专家何登成在首届阿里巴巴在线技术峰会上的分享整理而成.他主要介 ...
- MYSQL学习笔记——数据库范式及MYSQL优化整体思路
一.数据库范式 为了建立冗余较小.结构合理的 ...
- MySQL 查询语句优化思路
query 语句的优化思路和原则主要提现在以下几个方面:1. 优化更需要优化的Query:2. 定位优化对象的性能瓶颈:3. 明确的优化目标:4. 从 Explain 入手:5. 多使用profile ...
- 【58沈剑架构系列】mysql并行复制优化思路
一.缘起 mysql主从复制,读写分离是互联网用的非常多的mysql架构,主从复制最令人诟病的地方就是,在数据量较大并发量较大的场景下,主从延时会比较严重. 为什么mysql主从延时这么大? 回答:从 ...
- MySQL order by的一个优化思路
最近遇到一条SQL线上执行超过5s,这显然无法忍受了,必须要优化了. 首先看眼库表结构和SQL语句. CREATE TABLE `xxxxx` ( `id` ) NOT NULL AUTO_INCRE ...
- 【Mysql 优化 6】mysql优化的内容和思路
根据最近做mysql优化,以及参照的官方文档的一些知识点,总结一下,如何下手去优化mysql 数据库.PS:更多可能是我个人的笔记总结记录,仅供参考 一.优化的内容 可以优化的内容,从范围的大小,可以 ...
随机推荐
- 协议-网络-安全协议:SSH(安全外壳协议)
ylbtech-协议-网络-安全协议:SSH(安全外壳协议) SSH 为 Secure Shell 的缩写,由 IETF 的网络小组(Network Working Group)所制定:SSH 为建立 ...
- python对XML 操作
一.XML的读取. 在 NewEdit 中有代码片段的功能,代码片段分为片段的分类和片段的内容.在缺省情况下都是用XML格式保存的.下面我讲述一下,如何使用minidom来读取和保存XML文件. 下面 ...
- python大杂铺
python中continue,break,return三者之间的区别 return 会直接令函数返回,所有该函数体内的代码都不再执行了,所以该函数体内的循环也不可能再继续运行. break:跳出 ...
- 【K8s】Kubernetes架构理解
抽空学习了一下Kubernetes,感觉和大数据领域内集群的资源管理.任务调度等有异曲同工之处,简单总结一下备忘. [概念] Kubernetes是一个工业级的容器编排平台,单词有点长,常用K8s代称 ...
- python 12:list(range(...)) (转化参数列表)
numbers = list(range(1,11)) #把范围产生的数字串转化为列表储存 print(numbers) 运行结果应该是: [1,2,3,4,5,6,7,8,9,10]
- BZOJ 1914 计算几何
思路: 我们可以算不合法的 如果三个点都在同一侧 就不合法.. 用总方案数减掉就可以了 (有神奇的实现方法...) //By SiriusRen #include <cmath> #inc ...
- BZOJ 4808 二分图最大独立集
思路: 棋盘是个二分图 那就把一个可以走的白点 向所有可以走的黑点连边 跑一个最大匹配 (匹配上了就代表这两个点不能共存) 最大独立集=sum-最大匹配 //By SiriusRen #incl ...
- Spring Cloud (3) 服务消费者-Ribbon
在上一篇中使用LoadBalancerClient接口实现了获取某个服务的具体实例,并根据实例信息发起服务接口消费请求.但是这样的做法需要我们手工的区编写服务选取.连接拼接等繁琐的工作,对于开发人员来 ...
- ios -使用NSLayoutConstraint实现多个view等宽等高等间距
@interface ViewController () { UIView *firstView; UIView *secondView; UIView *thirdView; } @end @imp ...
- 三星A3、A5、A7、G7、J5、J7、S6系列等新机型的部分手机解锁 ROOT刷机
三星A3.A5.A7.G7.J5.J7.S6系列等新机型的部分手机,三星官方加了限制,需要解锁后才能刷机如果没有解锁,刷第三方recovery或者刷非官方原版固件,都会刷不进,手机跳转到提示界面,显示 ...