sql优化案例

A. 22 六种常见sql场景及其在TDH中的优化策略

//
Transwarp - 新闻详情
http://www.transwarp.io/news/detail?id=161

在《 Hadoop平台中SQL优化的四个思路 》一文中，我们对Hadoop平台中的SQL优化思路做了简单介绍，为的是让读者能对SQL优化有一个宏观掌握。
本文将针对Transwarp Data Hub（TDH）中的常见SQL的场景，继续深入讨论如何对不同类型SQL选择不同的优化策略。根据SQL特性以及数据特性，本文把TDH中涉及的SQL场景分为以下六类，分别对它们的优化方法进行分析。

分析数据。获取每个表的各行各列的特性，比较分析是否存在记录行数很大的表、表与表的特点差异和记录行数量级的差距。

分析执行计划。明确是否应该用MapJoin，是否应调整JOIN顺序，是否需要谓词下推。

分析过滤率。计算过滤率，核对JOIN顺序并做出调整，先JOIN数据量少过滤率高的表。

对SQL分类，选择典型，重点分析。从最影响性能且容易改善的部分开始，不断优化、迭代，直至得到满意效果。

Step5：最终把选用的优化手段按类型应用到其他语句上。
对SQL优化进行实践的过程中，需要读者不仅仅只是理解这些优化思想，更重要的是在足够多的案例中去累积经验，多尝试多比较，提高对特征SQL的敏锐度，将充裕的理论转化为价值，将了解的事物变成属于自己的东西。

B. 如何用SQL分析电商用户行为数据（案例）

        

本文以“淘宝用户行为数据集”的分析全过程为例，展示数据分析的全过程

——使用工具：MySQL，Excel，Navicat，PowerBI

——分析类型：描述分析，诊断分析

——分析方法：漏斗分析，用户路径分析，RFM用户价值分析，活跃/存留分析，帕累托分析，假设验证分析。

（考虑到阅读体验文章中只放了SQL截图，如需PDF版本，再公众号后台回复“用户行为分析”领取）

（目录如下）

       

1.分析流程和方法

当没有清晰的数据看板时我们需要先清洗杂乱的数据，基于分析模型做可视化，搭建描述性的数据看板。

然后基于描述性的数据挖掘问题，提出假设做优化，或者基于用户特征数据进行预测分析找规律，基于规律设计策略。简单来说：

——描述性分析就是：“画地图”

——诊断性分析就是：“找问题”

——预测性分析就是 ：“找规律”

在数据分析中有两个典型的场景：

一种是有数据，没有问题：需要先整体分析数据，然后再根据初步的描述分析，挖掘问题做诊断性分析，提出假设，设计策略解决问题。

 

另一种是已经发现了问题，或者已经有了假设，这种做数据分析更偏向于验证假设。

 

2.淘宝用户行为分析

本次是对“淘宝用户行为数据集”进行分析，在分析之前我们并不知道有什么问题，所以需要先进行描述性分析，分析数据挖掘问题。

我们首先来看下这个数据集的元数据：

       

根据以上数据字段我们可以拿用户行为为主轴从纵深方向提出一些问题，然后再从数据中找答案

       

纵向：

——这个数据集中用户的日活跃和周活跃时间有什么规律吗？

——在当日活跃的用户次日，三日，四日……还有多少活跃？

深向：

——用户从浏览到购买的整体转化率怎么样？

——用户从浏览到购买的路径是怎么样子的？ 

——平台主要会给用户推送什么商品？

——用户喜欢什么类目？喜欢什么商品？ 

——怎么判断哪些是高价值用户 ？ 

 

 

下面是叮当整理的常用分析方法：      

我们可以给前面的问题匹配一下分析方法，便于后面的分析：

为了便于后面的数据分析，在分析之前我们需要先对做一下清洗

看元数据（字段解释，数据来源，数据类型，数据量……）初步发现问题为之后的处理做准备。

       

确定缺失值范围，去除不需要字段，填充缺失内容    

根据元数据格式和后续分析需要的格式对数据进行处理

  

去除重复值，异常值

——去除重复值：并把用户ID,商品ID，时间戳设置为主键

——异常值处理：查询并删除2017年11月25日至2017年12月3日之外的数据

     

查询并删除小于2017-11-25的

——验证数据：      

——分析思路：

——SQL提数：

       

       

——Excel可视化：

       

活跃曲线整体为上升状态，同为周六日，12月2号，3号相比11月25日，26日活跃度更高。

用户在周六周日相比其他时间更活跃（周六周日为休息日，用户有更多时间）

      

一天内用户活跃的最高峰期为21点（用户在这个时间段空闲较多）

 

——分析思路：

——SQL提数：

列出每用户每天及当天后面又活跃的日期，并创建“活跃时间间隔表”用于后面求次日存留，三日存留……

       

对“活跃时间间隔表视图”引用进行分组统计，计算每日存留人数并创建视图

对存留人数表进行计算，统计活跃用户留存率

——Excel可视化：

       

——分析思路：

——SQL提数：

-把各种用户行为分离出来并创建视图方便后续查询用户行为数据

查询整体数据漏斗

——Excel可视化：

       

用户从浏览到购买整体转化率2.3%，具体主要在哪个环节流失还需要再细分用户路径分析

 

——分析思路：

       

——SQL提数：

——PowerBI可视化：

       

用户从浏览到购买的路径主要有4条，路径越长转化率越底

路径1：浏览→购买：转化率1.45%

路径2：浏览→加购物车→购买：转化率0.33

路径3：浏览→收藏→购买：转化率0.11%

路径4：浏览→收藏→加购物车→购买：转化率0.03%

——分析思路：

——SQL提数：

——Excel可视化：

       

——描述性分析：

浏览量top100的商品浏览量呈阶梯分布，越靠前的阶梯之间的落差相对越大在这个阶梯中的商品越少，越靠后商品浏览量阶梯之间的落差相对越小，同阶梯内的商品越多。

浏览量TOP100的商品所属类目中，4756105，3607361，4357323三个类目浏览量远超其他类目。

——分析思路：

——SQL提数：

查询计算商品转化率，升序排列，取前100个

       

——Excel可视化：

       

——描述性分析：

从商品看：有17款商品转化率超过了1。

从类目看：这些商品所属类目分布均匀，除965809，4801426，2735466，2640118，5063620，4789432，2945933这7个类目之外，其他类目都只有一个商品在转化率TOP100的商品中。

——分析思路：

用户价值分析常用的分析方式是RFM模型

       

本次分析中的R,F,M具体定义（仅用于演示分析方法，无实际业务参考价值）：

 

——SQL取数与分析：

1）建立打分标准：先计算R,F的值，并排序，根据R,F值最大值和最小值得区间设计本次得打分标准

-查询并计算R，F值创建视图

       

-引用RF数值表，分别查询R,F的最大值和最小值

       

       

-结合人工浏览的建立打分标准      

2）给R，F按价值打分

3）计算价值的平均值

       

4）用平均值和用户分类规则表比较得出用户分类   

     

——Excel可视化      

 

通过描述性分析得到可视化的数据后我们一般会先看一下是否符合业务常识

如果符合常识接下来我们会通过与行业平均数据和本产品的同比环比对比看是否正常，如果不正常就要找原因，设计解决方案，如果正常那就看是否有可以优化的地方。

       

我们首先来看一下这些描述性分析是否符合业务常识和指标是否正常：

       

1.活跃曲线整体为上升状态，同为周六日，12月2号，3号相比11月25日，26日活跃度更高。

2.用户在周六周日相比其他时间更活跃

3.一天内用户活跃的最高峰期为21点

4.从2017年11月15日致2017年12月3日，活跃用户新增38%

5.从2017年11月15日致2017年12月3日，活跃用户次日留存增长18.67%，当日的活跃用户留存也在快速增长，第七日留存比次日留存高18.56%。

6.用户从浏览到购买整体转化率2.3%

7.用户从浏览到购买的路径主要有4条，路径越长转化率越低。

8.浏览量top100的商品浏览量呈阶梯分布，越靠前的阶梯之间的落差相对越大在这个阶梯中的商品越少，越靠后商品浏览量阶梯之间的落差相对越小，同阶梯内的商品越多。

9.浏览量TOP100的商品所属类目中，4756105，3607361，4357323三个类目浏览量远超其他类目。

10.从商品看：有17款商品转化率超过了1。

11.从类目看：这些商品所属类目分布均匀，除965809，4801426，2735466，2640118，5063620，4789432，2945933这7个类目之外，其他类目都只有一个商品在转化率TOP100的商品中。

根据以上诊断分析我们梳理出了以下假设，做假设验证。

       

 

假设1：这些商品中有高转化率的爆款商品

       

 

对比浏览量TOP5的商品，发现这些商品转化率在同一类目下并不高，假设不成立

 

假设2：4756105，3607361，4357323三个类目属于高频刚需类目

-创建类目购买频次表

       

-计算类目购买频次平均值

       

-查询4756105，3607361，4357323三个类目的购买频次       

4756105，3607361，4357323三个类目的用户购买频次明显高于平均值，假设成立

 

假设3：有部分用户是未点击商详直接从收藏和购物车购买的。

       

用户不是直接从收藏和购物车购买的，只是后续复购未点击商详，假设不成立

 

假设4：淘宝推荐的商品主要是“同一类目下的高转化商品”

       

用Excel对浏览量TOP100的商品ID和转化率TOP100的商品ID进行去重，结果无重复值，假设不成立

3.结论：

1）用户活跃：用户活跃曲线整体呈上升趋势，在一周中周六，周日活跃度比平时更高，在一天中用户活跃曲线从凌晨4点开始往上升，在中午12点和下午5~6点有两个小低谷（吃饭），到晚上9点时活跃度达到顶峰。

 

2）用户留存：从2017年11月15日致2017年12月3日的用户留存数据来看，淘宝的用户留存数据较好，活跃用户次日留存增长18.67%，当日的活跃用户留存也在快速增长，第七日留存比次日留存高18.56%。

 

3）用户转化：整体转化2.3%，用户从浏览到购买的路径主要有4条，路径越长转化率越低。

4）平台推荐与用户偏好：从数据集中的数据来看，排除用户兴趣偏好标签，淘宝给用户用户推送的商品主要是高频刚需的类目，促使用户复购，流量回流平台。

 

以上结论受数据量和数据类型的影响，并不一定准确，仅用来练习数据分析方法。

（考虑到阅读体验文章中只放了SQL截图，如需PDF版本，再公众号后台回复“用户行为分析”领取）

C. 如何使OQWT定位和分析SQL性能问题

封面报道
如何使用 IBM Optim Query Workload Tuner 定位和分析 SQL 性能问题 作者：秦玮, 刘铭, 赵国斌
IBM Optim Query Workload Tuner ( 简称 OQWT)， 是面向数据库管理人员和应用开发人员的新一代 SQL 性能调优产品，它可以对单个或者一组 SQL 查询语句进行性能分析和调优，包括 SQL 查询语句的定位、图形化的性能分析、多种的优化建议、验证优化方案等等。它提供了丰富的功能可以快速的从各种常用源找到有潜在性能问题的 SQL 语句。下面详细介绍如何使用 OQWT 快速定位问题 SQL 语句。

社区讨论精彩回顾：您如何看待使用数据库工具对DBA技术成长的影响?
本次讨论主要就以下几个问题进行了探讨：1、您如何看待使用数据库图形工具对DBA以及开发人员技术成长的影响? 2、您认为DBA们最常用的数据库工具是什么？ 3、您认为DBA们应该如何使用数据库工具才能高效的成长？

安装配置
AIX DB2 V8升级到DB2 V9.5的步骤 作者：DB2开发与应用社区 lijiantang
本文分操作系统升级与环境确认、停止相关系统应用、安装DB9数据库程序、备份相关配置文件等十个步骤向大家详细介绍了DB2数据库升级步骤。

性能调优
“三方演义”与性能优化 作者：DB2开发与应用社区 王飞鹏
本文作者自己实际的体会探讨了性能优化为什么这么难？并重点分析了某银行性能优化的真实案例。

故障诊断
对 DB2 远程 SQL 复制应用中的常见错误分析及处理 作者：黄湘平,张蕾
本文深入分析和刨析 SQL 复制的运行机制，列举出常见错误的处理方法，使 DB2 开发和管理人员能缩短处理问题的时间，提高他们在系统中应用 SQL 复制的效率。

博客精选
浅谈影响DB2高可用性的各种因素 作者：DB2开发与应用社区 sunyangnj
DB2数据库本身的设计和操作对高可用影响非常大。所以本文着重从DB2本身出发谈谈做好高可用应该注意的方面。

教程推荐
本栏目提供了DB2数据库的实用教程。

D. 慢sql治理经典案例分享

作者 | 如期
来源 | 阿里技术公众号

菜鸟供应链金融慢sql治理已经有一段时间，自己负责的应用持续很长时间没有慢sql告警，现阶段在推进组内其他成员治理应用慢sql。这里把治理过程中的一些实践拿出来分享下。

在分页查询治理的文章里已经介绍过我们系统旧的分页查询逻辑，上面的查询sql明显就是分页查询获取总记录数，通过XXX_rules表的分页查询接口溯源，找到发起调用的页面是我们小二后台的一个操作商家准入的页面，页面打开后直接调用分页查询接口，除了分页参数，不传入其他任何查询参数，导致扫描全表。

灵魂拷问：为什么要扫描全表？全表数据展示到页面，花里胡哨的数据有用吗？

调研：和经常使用这个页面的运营聊后了解到，打开页面查询出的全表数据对运营是没有用的，他们根本不看这些数据。运营的操作习惯是拿到商家id，在页面查询框中输入商家id，查到商家数据后进行操作。

由此优化方案就很明朗了：打开页面时不直接查询全量数据，等运营输入商家id后，将商家id作为参数进行查询。XXX_rules表中，商家id这一常用查询条件设置为索引，再结合分页查询优化，全表扫描慢sql得以解决。

优化后的小二后台页面如下：

打开页面时未查询任何数据，查询条件商家账户为必填项。

优化后的sql为:

执行EXPLAIN得到结果如下：

可以看到命中了索引，扫描行数为3，查询速度明显提高。

扫描全表治理简单来说就是加入查询条件，命中索引，去除全表扫描查询，虽然有些粗暴，但并不是没有道理。实际业务场景中，很少有要扫描全表获取全部数据的情况，限制调用上游必须传入查询条件，且该查询条件能命中索引，能很大程度上避免慢sql。

另外，再引申下，XXX_rules初始的用意是准入表，记录金融货主维度的准入情况，最多也就几千条数据，但是很多同事将这张表理解为规则表，写入很多业务相关规则，导致这个表膨胀到一百多万条数据，表不clean了。这就涉及到数据表的设计使用，明确表的使用规范，不乱写入数据，能给后期维护带来很大的便利。

除了时间、操作人字段，XXX_rules表就rule_name、rule_value、status、proct_code四个字段，表的索引对这四个字段做各种排列组合。存在如下问题：

1、rule_name离散度不高，放在索引首位不合适；

2、前三个索引重合度很高；

显然是对索引的命中规则不够了解。XXX_rules表很多业务有定时任务对其写入删除，索引多、混乱，对性能有很大的影响。

高性能的索引有哪些，再来回顾下：

1、独立的列：索引列不能是表达式的一部分；

2、选择区分度高的列作为索引；

3、选择合适的索引列顺序：将选择性高的索引列放在最前列；

4、覆盖索引：查询的列均在索引中，不需要回查聚簇索引；

5、使用索引扫描来做排序;

6、在遵守最左前缀的原则下，尽量扩展索引，而不是创建索引。

但凡记得第3和6规则，也不至于把索引建成这样。

对索引进行整合如下：

系统中有很多任务拉取整个产品下的准入记录，然后进行处理，所以将区分度较高的proct_code放在索引首位，然后添加rule_name、status字段到索引里，进一步过滤数据，减少扫描行数，避免慢sql。针对常用的rule_value查询条件，可以命中UK，因此不用单独建立索引。

很多业务逻辑中，需要拉取满足某个条件的记录列表，查询的sql语句带有order by，记录比较多的情况，排序代价往往很大，但是查询出来的记录是否有序对业务逻辑没有影响，比如分页治理里讨论的count语句，只需要统计条数，order by对条数没有影响，再比如查出记录列表后，不依赖记录的顺序遍历列表处理数据，这时候order by多此一举。

查询sql无limit语句，且业务处理逻辑不依赖于order by后列表记录的顺序，则去除查询sql中的order by语句。

业务中有很多定时任务，扫描某个表中某个产品下所有数据，对数据进行处理，比如：

三个查询条件都是区分度不高的列，查出的数据有27W条，加索引意义也不大。

实际业务量没那么大，顶多几千条数据，表里的数据是从上游同步过来的，最好的办法是让上游精简数据，但是由于业务太久远，找上游的人维护难度太大，因此只能想其他的办法。

这个定时任务目的是拉出XXX_rules表的某些产品下的数据，和另一张表数据对比，更新有差异的数据。每天凌晨处理，对时效性没有很高的要求，因此，能不能转移任务处理的地方，不在本应用机器上实时处理那么多条数据？

数据是离线任务odps同步过来的，首先想到的就是dataWork数据处理平台。

建立数据对比任务，将定时任务做的数据对比逻辑放到dataWork上用sql实现，每天差异数据最多几百条，且结果集含有区分度很高的列，将差异数据写入odps表，再将数据回流到idb。

新建定时任务，通过回流回来的差异数据中区分度高的列作为查询条件查询XXX_rules，更新XXX_rules，解决了慢sql问题。

这个方法的前提是对数据实效性要求不高，且离线产出的结果集很小。

explain上述查询语句，得到结果如下：

XXX_white_list表有将biz_id作为索引，这里查询XXX_white_list表有传入biz_id作为查询条件，为啥explain结果里type为ALL，即扫描全表？索引失效了？索引失效有哪些情况？

索引失效场景

1、OR查询左右有未命中索引的；

2、复合索引不满足最左匹配原则；

3、Like以%开头；

4、需要类型转换；

5、where中索引列有运算；

6、where中索引列使用了函数；

7、如果mysql觉得全表扫描更快时（数据少时）

上述查询语句第8行，customer_id为XXX_level_report表字段，未命中XXX_white_list表索引，导致索引失效。

这个语句用condition、枚举、join花里胡哨的代码拼接起来的，改起来好麻烦，而且看起来“OR customer_id LIKE CONCAT(t.biz_id, '@%')”这句不能直接删掉。最后重构了该部分的查询语句，去除or查询，解决了慢sql。

E. SQL优化万能公式：5 大步骤 + 10 个案例

在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的SQL就是整个系统性能的瓶颈。

1、通过慢查日志等定位那些执行效率较低的SQL语句

2、explain 分析SQL的执行计划

type由上至下，效率越来越高

Extra

3、show profile 分析

了解SQL执行的线程的状态及消耗的时间。默认是关闭的，开启语句“set profiling = 1;”

4、trace

trace分析优化器如何选择执行计划，通过trace文件能够进一步了解为什么优惠券选择A执行计划而不选择B执行计划。

5、确定问题并采用相应的措施

案例1、最左匹配

索引

SQL语句

查询匹配从左往右匹配，要使用order_no走索引，必须查询条件携带shop_id或者索引( shop_id , order_no )调换前后顺序

案例2、隐式转换

索引

SQL语句

隐式转换相当于在索引上做运算，会让索引失效。mobile是字符类型，使用了数字，应该使用字符串匹配，否则MySQL会用到隐式替换，导致索引失效。

案例3、大分页

索引

SQL语句

对于大分页的场景，可以优先让产品优化需求，如果没有优化的，有如下两种优化方式， 一种是把上一次的最后一条数据，也即上面的c传过来，然后做“c < xxx”处理，但是这种一般需要改接口协议，并不一定可行。另一种是采用延迟关联的方式进行处理，减少SQL回表，但是要记得索引需要完全覆盖才有效果，SQL改动如下

案例4、in + order by

索引

SQL语句

in查询在MySQL底层是通过n*m的方式去搜索，类似union，但是效率比union高。in查询在进行cost代价计算时（代价 = 元组数 * IO平均值），是通过将in包含的数值，一条条去查询获取元组数的，因此这个计算过程会比较的慢，所以MySQL设置了个临界值(eq_range_index_pe_limit)，5.6之后超过这个临界值后该列的cost就不参与计算了。因此会导致执行计划选择不准确。默认是200，即in条件超过了200个数据，会导致in的代价计算存在问题，可能会导致Mysql选择的索引不准确。

处理方式，可以( order_status , created_at )互换前后顺序，并且调整SQL为延迟关联。

案例5、范围查询阻断，后续字段不能走索引

索引

SQL语句

范围查询还有“IN、between”

案例6、不等于、不包含不能用到索引的快速搜索。（可以用到ICP）

在索引上，避免使用NOT、!=、>、!、NOT EXISTS、NOT IN、NOT LIKE等

案例7、优化器选择不使用索引的情况

如果要求访问的数据量很小，则优化器还是会选择辅助索引，但是当访问的数据占整个表中数据的蛮大一部分时（一般是20%左右），优化器会选择通过聚集索引来查找数据。

查询出所有未支付的订单，一般这种订单是很少的，即使建了索引，也没法使用索引。

案例8、复杂查询

如果是统计某些数据，可能改用数仓进行解决；如果是业务上就有那么复杂的查询，可能就不建议继续走SQL了，而是采用其他的方式进行解决，比如使用ES等进行解决。

案例9、asc和desc混用

desc 和asc混用时会导致索引失效

案例10、大数据

对于推送业务的数据存储，可能数据量会很大，如果在方案的选择上，最终选择存储在MySQL上，并且做7天等有效期的保存。那么需要注意，频繁的清理数据，会照成数据碎片，需要联系DBA进行数据碎片处理。

F. sql 如何用临时表优化性能

InnoDB 类型的临时表存在的潜在问题

尽管使用 InnoDB 是性能最佳的，但可能会出现新的潜在问题。在某些特定情况下，您可能会出现磁盘耗尽和服务器中断。

与数据库中的任何其他 InnoDB 表一样，临时表具有自己的表空间文件。新文件与通用表空间一起位于数据目录中，名称为 ibtmp1。它存储所有 tmp 表。不运行手动运行 OPTIMIZE TABLE，表空间文件就会不断增长。如果你不能使用 OPTIMIZE，那么唯一能将 ibtmp1 大小缩小为零的方法，就是重新启动服务器。幸运的是，即使文件无法减小，在执行查询后，临时表也会自动删除，表空间可回收使用。现在，我们想一想以下情境：

• 存在未优化的查询，需要在磁盘上创建非常大的的临时表

• 存在优化的查询，但他们正在磁盘上创建非常大的临时表，因为你正在对此数据集进行计算（统计，分析）

• 高并发连接时，运行相同的查询，伴随临时表的创建

• 没有很多可用空间

• 在这些情况下，文件 ibtmp1 大大增加，很容易耗尽可用空间。这种情况每天发生几次，并且必须重启服务器才能完全缩小 ibtmp1 表空间。使用不可收缩的文件可以轻松耗尽磁盘空间！

那么，如何避免磁盘耗尽和中断呢？




简单的解决方案：使用更大的磁盘

• 虽然可以暂时解决问题，但这不是最佳解决方案。实际上，您可以通过逐步增加磁盘大小，来猜测具体需要的空间。如果环境位于云中，或者在非常大的虚拟平台，这很容易实现。但是使用这种解决方案，您可能会面临不必要的开支。您还可以通过设置以下配置变量将 ibtmp1 文件移动到专用大型磁盘上： [mysqld] innodb_temp_data_file_path = ../../tmp/ibtmp1:12M:autoextend



需要重启 MySQL 。注意，必须将路径指定为相对于数据目录。

设置 ibtmp1 大小的上限

• 例如： [mysqld] innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:10G



在这种情况下，文件不能超过 10GB。可以降低宕机概率，但也是一个危险的解决方案。当数据文件达到最大值时，会查询失败并显示一个错误，提示表已满。



• 退回 MyISAM 将临时表存储在磁盘上

这个解决方案似乎违反直觉，但它可能是快速避免中断的最佳方法，并保证使用所有需要的临时表。

• internal_tmp_disk_storage_engine = MYISAM


• 由于变量是动态的，您也可以在运行时设置它： SET GLOBAL internal_tmp_disk_storage_engine = MYISAM;


• 回到 MyISAM，您将大大降低写满磁盘空间的可能性。实际上，临时表将创建到不同的文件中，并在查询结束时立即删除。

虽然总是有可能看到相同的问题，以防你可以在同一时间运行查询或非常接近。在我的实际案例中，这是避免所有中断的解决方案。

优化你的查询

• 在将存储引擎退回到 MyISAM 以减轻中断发生后，必须花时间分析查询。目标是减小磁盘上临时表的大小。本文的目的不是解释如何调查查询，而是可以依赖慢速日志，像 pt-query-digest 和 EXPLAIN 这样的工具。一些技巧：

• 在表上创建缺少的索引

• 如果不需要，可以在查询中添加更多过滤条件以更少收集的数据

• 重写查询以优化执行计划

• 可以在应用程序中使用队列管理器来序列化它们的执行或减少并发性

但希望在所有优化之后，您可以返回将临时存储引擎设置为 InnoDB 以获得更好的性能。

结论

有时这些改进会产生意想不到的副作用。用于磁盘上临时表的 InnoDB 存储引擎是一个很好的改进，但在某些特定情况下，例如，如果您有未优化查询和很少的可用空间，则可能因“磁盘已满”错误而中断。将 tmp 存储引擎退回到 MyISAM 是避免中断的最快方法，但是为了返回到 InnoDB，查询的优化是更重要的事情。更大或专用的磁盘也可能有所帮助。但这是一个微不足道的建议。

G. 数据分析课程笔记 - 19 - HiveSQL 常用优化技巧

大家好呀，这节课学习 HiveSQL 的常用优化技巧。由于 Hive 主要用来处理非常大的数据，运行过程由于通常要经过 MapRece 的过程，因此不像 MySQL 一样很快出结果。而使用不同方法写出来的 HiveSQL 语句执行效率也是不一样的，因此为了减少等待的时间，提高服务器的运行效率，我们需要在 HiveSQL 的语句上进行一些优化。

本节课的主要内容 ：

引言
1、技巧一：列裁剪和分区裁剪
（1）列裁剪
（2）分区裁剪
2、技巧二：排序技巧——sort by代替order by
3、技巧三：去重技巧——用group by来替换distinct
4、技巧四：聚合技巧——grouping sets、cube、rollup
（1）grouping sets
（2）cube
（3）rollup
5、技巧五：换个思路解题
6、技巧六：union all时可以开启并发执行
7、技巧七：表连接优化
8、技巧八：遵循严格模式

Hive 作为大数据领域常用的数据仓库组件，在平时设计和查询时要特别注意效率。影响Hive效率的几乎从不是数据量过大，而是数据倾斜、数据冗余、job 或 I/O 过多、MapRece 分配不合理等等。对 Hive 的调优既包含对HiveSQL 语句本身的优化，也包含 Hive 配置项和 MR 方面的调整。

列裁剪就是在查询时只读取需要的列。当列很多或者数据量很大时，如果select 所有的列或者不指定分区，导致的全表扫描和全分区扫描效率都很低。Hive中与列裁剪优化相关的配置项是 hive.optimize.cp ，默认是 true 。

分区裁剪就是在查询时只读需要的分区。Hive中与分区裁剪优化相关的则是 hive.optimize.pruner ，默认是 true 。

HiveSQL中的 order by 与其他 SQL 语言中的功能一样，就是将结果按某个字段全局排序，这会导致所有map端数据都进入一个 rece 中，在数据量大时可能会长时间计算不完。

如果使用 sort by ，那么就会视情况启动多个 recer 进行排序，并且保证每个 recer 内局部有序。为了控制 map 端数据分配到 rece 的 key，往往还要配合 distribute by 一同使用。如果不加 distribute by 的话，map 端数据就会随机分配给 recer。

这里需要解释一下， distribute by 和 sort by 结合使用是如何相较于 order by 提升运行效率的。

假如我们要对一张很大的用户信息表按照年龄进行分组，优化前的写法是直接 order by age 。使用 distribute by 和 sort by 结合进行优化的时候， sort by 后面还是 age 这个排序字段， distribute by 后面选择一个没有重复值的均匀字段，比如 user_id 。

这样做的原因是，通常用户的年龄分布是不均匀的，比如20岁以下和50岁以上的人非常少，中间几个年龄段的人又非常多，在 Map 阶段就会造成有些任务很大，有些任务很小。那通过 distribute by 一个均匀字段，就可以让系统均匀地进行“分桶”，对每个桶进行排序，最后再组合，这样就能从整体上提升 MapRece 的效率。

取出 user_trade 表中全部支付用户：

原有写法的执行时长：

优化写法的执行时长：

考虑对之前的案例进行优化：

注意： 在极大的数据量（且很多重复值）时，可以先 group by 去重，再 count() 计数，效率高于直接 count(distinct **) 。

如果我们想知道用户的性别分布、城市分布、等级分布，你会怎么写？

通常写法：

缺点 ：要分别写三次SQL，需要执行三次，重复工作，且费时。

那该怎么优化呢？

注意 ：这个聚合结果相当于纵向地堆在一起了（Union all），分类字段用不同列来进行区分，也就是每一行数据都包含 4 列，前三列是分类字段，最后一列是聚合计算的结果。

GROUPING SETS() ：在 group by 查询中，根据不同的维度组合进行聚合，等价于将不同维度的 group by 结果集进行 union all。聚合规则在括号中进行指定。

如果我们想知道用户的性别分布以及每个性别的城市分布，你会怎么写？

那该怎么优化呢？

注意： 第二列为NULL的，就是性别的用户分布，其余有城市的均为每个性别的城市分布。

cube：根据 group by 维度的所有组合进行聚合

注意 ：跑完数据后，整理很关键！！！

rollup：以最左侧的维度为主，进行层级聚合，是cube的子集。

如果我想同时计算出，每个月的支付金额，以及每年的总支付金额，该怎么办？

那应该如何优化呢？

条条大路通罗马，写SQL亦是如此，能达到同样效果的SQL有很多种，要学会思路转换，灵活应用。

来看一个我们之前做过的案例：

有没有别的写法呢？

Hive 中互相没有依赖关系的 job 间是可以并行执行的，最典型的就是
多个子查询union all。在集群资源相对充足的情况下，可以开启并
行执行。参数设置： set hive.exec.parallel=true;

时间对比：

所谓严格模式，就是强制不允许用户执行3种有风险的 HiveSQL 语句，一旦执行会直接报错。

要开启严格模式，需要将参数 hive.mapred.mode 设为 strict 。

好啦，这节课的内容就是这些。以上优化技巧需要大家在平时的练习和使用中有意识地去注意自己的语句，不断改进，就能掌握最优的写法。