阿里云数据库专家玄惭的“武功”全记录之性能优化篇
本篇通过12个例子列举12种mysql优化相关技术,详情请见正文。
来源 云栖社区(ID:yunqiinsight)
作者 玄 惭
文章简介
玄惭,真名罗龙九,阿里云DBA专家,负责阿里云RDS线上稳定以及专家服务团队。他经历过阿里历年双11实战考验,积累了7年对阿里云数据库用户的运维、调优、诊断等丰富DBA经验。本专题集结了玄惭排查经验、性能优化心得、最佳实践以及其他思考。
以下12篇文章只提取了摘要部分,文章详细内容请点击【阅读原文】进入查看。
性能优化
1. 性能测试:自建数据库对比RDS中应当注意的地方(适用于MySQL,SQL SERVER,MongoDB)
常常很多用户对比测试自建数据库和RDS的性能差异,其测试结果往往是RDS不如ECS自建,用户往往怀疑难道我花了那么多的钱买的RDS难道还不如自己在ECS上搭建吗?从数据库测试的角度来看,测试首先必须是的公平的进行,其结果才具有说服力。
详情:https://yq.aliyun.com/articles/71232
2. 一个价值“千万”的秒杀场景参数优化
秒杀最早来自天猫双11各种商品的促销活动中,现在已经有很多业务场景在使用,比如抢红包,抢票等。其特点有三高:瞬时并发高,数据一致性高,热点更新频度高。这样三高的场景下往往给数据库造成极大的压力,大量更新数据库中的同一行,这样必然会产生锁等待,导致数据库的性能急剧下降的问题,很容出现雪崩效应。面对秒杀业务的场景,数据库成为了底层系统中最重要的瓶颈点,阿里经过几年的沉淀也诞生了很多的技术手段来进行优化,这里我们就重点讲一下底层数据所做的优化。
详情:https://yq.aliyun.com/articles/46353
3. 复杂关联SQL的优化
昨天处理了一则复杂关联SQL的优化,这类SQL的优化往往考虑以下四点:
1).查询所返回的结果集,通常查询返回的结果集很少,是有信心进行优化的;
2).驱动表的选择至关重要,通过查看执行计划,可以看到优化器选择的驱动表,从执行计划中的rows可以大致反映出问题的所在;
3).理清各表之间的关联关系,注意关联字段上是否有合适的索引;
4).使用straight_join关键词来强制表之间的关联顺序,可以方便我们验证某些猜想;
详情:https://yq.aliyun.com/articles/9048
4. 化繁为简-优化sql
这里有一段对话取自于和用户的一段旺旺聊天记录,在征得用户的同意后,放到我的blog中,希望更多的人能够看见,分享是一件快乐的事情;同时也想借此来说明一些问题,有时候试图用一条sql完成所有的业务逻辑可能会遇到麻烦,需要对复杂的sql进行一些拆分,可能会得到更好的效果。
详情:https://yq.aliyun.com/articles/9060
5. MySql sql优化之order by desc/asc limit M
Order by desc/asc limit M是我在mysql sql优化中经常遇到的一种场景,其优化原理也非常的简单,就是利用索引的有序性,优化器沿着索引的顺序扫描,在扫描到符合条件的M行数据后,停止扫描。看起来非常的简单,但是我经常看到很多性能较差的SQL没有利用这个优化规律,这里将结合一些实际的案例来分析说明。
详情:https://yq.aliyun.com/articles/9063
6. mysql sql优化之straight_join
在mysql中就有之对应的straight_join,由于mysql只支持nested loops的连接方式,所以这里的straight_join类似oracle中的use_nl hint。mysql优化器在处理多表的关联的时候,很有可能会选择错误的驱动表进行关联,导致了关联次数的增加,从而使得sql语句执行变得非常的缓慢,这个时候需要有经验的DBA进行判断,选择正确的驱动表,这个时候straight_join就起了作用了,下面我们来看一看使用straight_join进行优化的案例。
详情:https://yq.aliyun.com/articles/9064
7. 浅谈mysql的子查询
mysql的子查询的优化一直不是很友好,一直有受业界批评比较多,也是我在sql优化中遇到过最多的问题之一,你可以点击这里 ,这里来获得一些信息,mysql在处理子查询的时候,会将子查询改写,通常情况下,我们希望由内到外,也就是先完成子查询的结果,然后在用子查询来驱动外查询的表,完成查询,但是恰恰相反,子查询不会先被执行;今天希望通过介绍一些实际的案例来加深对mysql子查询的理解。
详情:https://yq.aliyun.com/articles/9070
8. SQL优化的一些总结
SQL的优化是DBA日常工作中不可缺少的一部分,我们可以按照 T=S/V(T代表时间,S代表路程,V代表速度)的思路来进行优化。
详情:http://hidba.org/
9. mysql explain 中key_len的计算
今天丁原问我mysql执行计划中的key_len是怎么计算得到的,当时还没有注意,在高性能的那本书讲到过这个值的计算,但是自己看执行计划的时候一直都没有太在意这个值,更不用说深讨这个值的计算了: ken_len表示索引使用的字节数,根据这个值,就可以判断索引使用情况,特别是在组合索引的时候,判断所有的索引字段都被查询用到。
详情:https://yq.aliyun.com/articles/17087
10. loose index scan 优化distinct
有这样的一个需求:select count(distinct nick) from user_access_xx_xx;这条sql用于统计用户访问的uv,由于单表的数据量在10G以上,即使在user_access_xx_xx上加上nick的索引,通过查看执行计划,也为全索引扫描,sql在执行的时候,会对整个服务器带来抖动。
详情:https://yq.aliyun.com/articles/17090
11. 使用伪’loose index scan’优化max
有时候我们会遇到以下的应用场景:
SELECT MAX(log_time)
FROM log_table
WHERE log_machine IN ($machines)
CREATE TABLE log_table
(id INT NOT NULL PRIMARY KEY,
log_machine VARCHAR(20) NOT NULL,
log_time DATETIME NOT NULL)
ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE INDEX ix_log_machine_time ON log_table (log_machine, log_time);
我们建立的索引为:(log_machine,log_time),当我们传入单个machine的时候,速度很快,但是当我们传入多个machines的时候,查询速度会一下子就降下来。
详情:https://yq.aliyun.com/articles/17091
12. mysql批量提交的优化
Java应用排量写入MySQL的优化,使用ewriteBatchedStatements=true参数,对批量操作,性能有较大提高,从官方解释上看,对普通操作没有。
详情:https://yq.aliyun.com/articles/17092
更多推荐
所有评论(0)