调整不一致的用语

(SQL)优化分析与方法.md

@@ -2,7 +2,7 @@
 
 -- 王雷 2019年1月24日 --
 
-> **前言**：要做好 sql 优化，我们先聊一聊在编写 sql 时要经常用到的一些关键词，看看这些关键词的用途，以及应该如何使用；然后讨论下，一条 SQL 是如何被执行的，再根据 SQL 的执行规范说一说应该怎么写出高效的 SQL，最后拿出一个栗子，来分析下应该如何对问题 SQL 进行优化。
+> **前言**：要做好 SQL 优化，我们先聊一聊在编写 SQL 时要经常用到的一些关键词，看看这些关键词的用途，以及应该如何使用；然后讨论下，一条 SQL 是如何被执行的，再根据 SQL 的执行规范说一说应该怎么写出高效的 SQL，最后拿出一个栗子，来分析下应该如何对问题 SQL 进行优化。
 
 #### 一、先说一说什么是 SQL
 
@@ -20,7 +20,7 @@
 
   **我们常说的优化，大部分所指的就是对使用数据查询语言编写的 SQL 在执行效率方面进行优化。**
 
-  当然，sql 优化也不单单只有 DQL 优化，有时，为了满足效率预期，我们也需要对其他方面进行调整。
+  当然，SQL 优化也不单单只有 DQL 优化，有时，为了满足效率预期，我们也需要对其他方面进行调整。
 
 #### 二、名词解释
 
@@ -34,7 +34,7 @@
 5. ***left join***：左外连接，也可简称左连接，当使用 left join 进行关联时，处于 left join 后方的数据来源如果不存在满足条件的数据记录，但其他数据来源存在相关记录，则返回除此来源外的其他数据项，此来源数据项返回 null
 6. right join：右外连接，也可简称右连接，数据返回情况如 left join 相似，但区别是只要 right join 后方的数据来源存在符合条件的记录即返回数据；
 7. full join：可以看做是 left join ∪ right join，也就是只要有满足条件的数据，就会返回，这个用的比较少；
-8. where：条件起始关键字，跟随在 where 关键字后的就是数据查询条件，我看大家在写 sql 经常会在 where 后面跟一个 1=1，貌似是方便了查询条件的拼写，但是，这个在某些数据库或者引擎下是会影响执行效率的，应该尽量避免；
+8. where：条件起始关键字，跟随在 where 关键字后的就是数据查询条件，我看大家在写 SQL 经常会在 where 后面跟一个 1=1，貌似是方便了查询条件的拼写，但是，这个在某些数据库或者引擎下是会影响执行效率的，应该尽量避免；
 9. in：一般用在一个数据项符合多个条件时，但是，in 操作很慢，如果可能的话，还是写 exists 子查询比较好，还有，如果要使用的 in 条件选项很多的情况，jdbc 可能是无法执行的，如 1000 个以上，这时就要考虑其他方法了；
 10. ***like***：做模糊查询时使用，使用左右 “%” 来进行匹配，如果使用左侧 % ，查询的时候用不上索引；
 11. group by：数据项分组，一般配合聚合函数，如 sum avg 等使用，如果需要对分组结果在进行筛选的话，需要配合 having 关键字；
@@ -102,7 +102,7 @@ limit
 7. 如果要参与比对的条件需要用到函数，则尽量避免在数据列上使用，这样会造成索引失效，而形成全表扫描，增加数据量；
 8. 如果查询条件中对同一个数据列有多个选项，不要使用 or 进行条件关联，而是使用 in；
 9. 如果查询条件中是一个变量可能符合多个数据列，可以将 in 反过来写，如，订单表中，想要查找 **未交费** 或 **未开票** 或 **未发货** 的数据，则条件可以写为 ```where 'N' in (pay_status, invoice_status, send_status)```；
-10. 如果查询条件包含较多的 or，可以使用 union all 来分解为多个 and 条件的 sql，避免因为使用 or 关系造成索引失效；
+10. 如果查询条件包含较多的 or，可以使用 union all 来分解为多个 and 条件的 SQL，避免因为使用 or 关系造成索引失效；
 11. 避免不必要的分组和排序；
 12. 如非必要，减少 like 的使用，like 比较在大部分情况下无法利用到索引；
 13. 从我了解到的资料看，MySQL 在解析 from 中的表和 Where 中的条件时基本都是采用自左向右的方式进行处理，因此我们在写跨表查询和多条件查询时，要尽量将可以大量过滤数据的条件写在前面，将可以利用索引的条件写在前面；
@@ -163,7 +163,7 @@ group by ss.id
 order by ss.sssq_z desc, ss.c_id, ss.id
 limit 15
 ```
-  这个 sql 的业务是查询符合条件税种申报、缴款情况，并返给用户查看，在发生问题的时刻，这个 sql 涉及的数据表行数如下表：
+  这个 SQL 的业务是查询符合条件税种申报、缴款情况，并返给用户查看，在发生问题的时刻，这个 SQL 涉及的数据表行数如下表：
 
 | 序号 | 数据表名称 | 数据行数 |
 |---|---|---|
@@ -173,7 +173,7 @@ limit 15
 | 4 | employee_info | 2630 |
 | 5 | sb_sbxx_bbmx | 179635 |
 
-  我们可以看到其中数据量最多的 sb_sbxx 表，不过有 25 万行记录，但在发生问题的时刻，这条 sql 语句执行耗时却达到了惊人的 200s，以至于造成数据库服务器 CPU 占用率过高（95%），进而引发数据库服务对外停止服务，造成大面积线上事故。
+  我们可以看到其中数据量最多的 sb_sbxx 表，不过有 25 万行记录，但在发生问题的时刻，这条 SQL 语句执行耗时却达到了惊人的 200s，以至于造成数据库服务器 CPU 占用率过高（95%），进而引发数据库服务对外停止服务，造成大面积线上事故。
 
 
   让我们使用 EXPLAIN 关键字来查询这条 SQL 的执行计划，如果使用 Navicat 工具，可以在查询窗口上点 “解释” 按钮，来获取执行计划：