点选下方 红色文本
温情提示信息：责任编辑约莫 3000 字，写作须要 5 两分钟。
领到几段须要强化的慢查阅sql，许多人都觉得难上加难。
只不过SQL强化是有基本功与拳法的，写作完责任编辑你将专业委员会那些强化拳法，让你正式成为自己眼里的资料库剑客！
推论难题SQL
推论SQL与否有难题时能透过三个虚无展开推论：
控制系统等级虚无CPU耗用轻微IO等候轻微网页响应天数太长应用领域的笔记再次出现延时等严重错误能采用 sar指示，top指示查看现阶段控制系统状况。
也能透过 Prometheus、Grafana等监视辅助工具检视伺服器状况。（钟爱的能翻阅我以后的该文）
乏味的SQL都好认知，几段SQL太长写作性的确Sitapur，所以再次出现难题的振幅的确会更高。再进一步推论SQL难题就得从继续执行方案侧发力，如下表所示右图：
继续执行方案告诉我们本次查阅走了全表扫描 Type=ALL，rows非常大(9950400)基本能推论这是几段”有味道”的SQL。
MySQL慢查阅笔记测试辅助工具loadrunnerPercona公司的ptquery等辅助工具OracleAWR报告测试辅助工具loadrunner等相关内部视图如v、session_wait等GRID CONTROL监视辅助工具达梦资料库AWR报告测试辅助工具loadrunner等达梦性能监视辅助工具（dem）相关内部视图如v、session_wait等SQL编写基本功
SQL编写有以下几个通用的基本功：
• 合理采用索引
索引少了查阅慢；
索引多了占用空间大，继续执行增删改句子的时候须要动态维护索引，影响性能 选择率高（重复值少）且被where频繁引用须要建立B树索引；
一般join列须要建立索引；
复杂文档类型查阅采用全文索引效率更好；
索引的建立要在查阅和DML性能之间取得平衡；
复合索引创建时要注意基于非前导列查阅的情况• 采用UNION ALL替代UNION
UNION ALL的继续执行效率比UNION高，UNION继续执行时须要排重；
UNION须要对数据展开排序• 避免select * 写法
继续执行SQL时强化器须要将 * 转成具体的列；
每次查阅都要回表，不能走覆盖索引。• JOIN字段建议建立索引
一般JOIN字段都提前加上索引
• 避免复杂SQL句子
提升可写作性；避免慢查阅的概率；
能转换成多个短查阅，用业务端处理• 避免where 1=1写法
• 避免order by rand()类似写法
RAND()导致数据列被多次扫描
SQL强化
继续执行方案
完成SQL强化一定要先读继续执行方案，继续执行方案会告诉你哪些地方效率低，哪里能须要强化。我们以MYSQL为例，看看继续执行方案是什么。（每个资料库的继续执行方案都不一样，须要自行了解）explain sql
接下来我们用几段实际强化案例来说明SQL强化的过程及强化基本功。
强化案例
表结构
CREATE TABLE `a`
(
`id` int(11) NOT NULLAUTO_INCREMENT,
`seller_id` bigint(20) DEFAULT NULL,
`seller_name` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`gmt_create` varchar(30) DEFAULT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE `b`
(
`id` int(11) NOT NULLAUTO_INCREMENT,
`seller_name` varchar(100) DEFAULT NULL,
`user_id` varchar(50) DEFAULT NULL,
`user_name` varchar(100) DEFAULT NULL,
`sales` bigint(20) DEFAULT NULL,
`gmt_create` varchar(30) DEFAULT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE `c`
(
`id` int(11) NOT NULLAUTO_INCREMENT,
`user_id` varchar(50) DEFAULT NULL,
`order_id` varchar(100) DEFAULT NULL,
`state` bigint(20) DEFAULT NULL,
`gmt_create` varchar(30) DEFAULT NULL,
PRIMARY KEY (`id`)
);
查阅要求
三张表关联，查阅现阶段用户在现阶段天数前后10个小时的订单情况，并根据订单创建天数升序排列，具体SQL如下表所示select a.seller_id,
a.seller_name,
b.user_name,
c.state
from a,
b,
c
where a.seller_name = b.seller_name
and b.user_id = c.user_id
and c.user_id = 17
and a.gmt_create
BETWEEN DATE_ADD(NOW(), INTERVAL – 600 MINUTE)
AND DATE_ADD(NOW(), INTERVAL 600 MINUTE)
order by a.gmt_create；
查阅数据量
原继续执行天数
原继续执行方案
初步强化思路
SQL中 where条件字段类型要跟表结构一致，表中user_id 为varchar(50)类型，实际SQL用的int类型，存在隐式转换，也未添加索引。将b和c表 user_id 字段改成int类型。因存在b表和c表关联，将b和c表user_id创建索引因存在a表和b表关联，将a和b表 seller_name字段创建索引利用复合索引消除临时表和排序初步强化SQL
alter table b modify `user_id` int(10) DEFAULT NULL;
alter table c modify `user_id` int(10) DEFAULT NULL;
alter table c add index `idx_user_id`(`user_id`);
alter table b add index `idx_user_id_sell_name`(`user_id`,`seller_name`);
alter table a add index `idx_sellname_gmt_sellid`(`gmt_create`,`seller_name`,`seller_id`);
查阅强化后继续执行天数
查阅强化后继续执行方案
查阅warnings信息
继续强化
alter table a modify “gmt_create” datetime DEFAULT NULL;查阅继续执行天数
查阅继续执行方案透过检视执行方案，到了这一步已经不再须要强化！
强化总结
总结一下完成几段SQL强化的思路与过程：
1、查阅继续执行方案 explain
2、如果有告警信息，查阅告警信息 show warnings;
3、查阅SQL涉及的表结构和索引信息
4、根据继续执行方案，思考可能的强化点
5、按照可能的强化点继续执行表结构变更、增加索引、SQL改写等操作
6、查阅强化后的继续执行天数和继续执行方案
7、如果强化效果不明显，重复第四步操作总结
这篇该文首先让你了解慢查阅的虚无，让你能透过一些辅助工具识别出慢查阅句子；
然后告诉你SQL强化的一些常用拳法基本功，掌握那些拳法基本功至少能解决80%的SQL强化难题；
最后透过一个示例从分析开始一步一步完成慢查阅句子的强化，其中查阅继续执行方案是强化过程中最终要的操作，大家一定要掌握。如果责任编辑对你有帮助，别忘记三连啊，点赞、转发、评论。咱们下期见！End
干货分享
即可获得百度网盘地址，无拳法领取！001：《程序员必读书籍》002：《从无到有搭建中小型互联网公司后台服务架构与运维架构》003：《互联网企业高并发解决方案》004：《互联网架构教学视频》006：《SpringBoot实现点餐控制系统》007：《SpringSecurity实战视频》008：《Hadoop实战教学视频》009：《腾讯2019Techo开发者大会PPT》
010： 微信交流群
近期热文top5
我就知道你“在看”
 fill=%23FFFFFF%3E%3Crect x=249 y=126 width=1 height=1%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E "数据库优化技巧 – SQL语句优化13")
