SQL优化思路整理
说明：本文章建立在有一定的数据库基础，只说明sql的优化思路，具体问题细节大家可以去网上找找资料。
个人思路sql的优化分三个方面：
1.程序员经验不足，sql写的太烂，这里就不多说了
2.表设计的缺陷，或者是二次开发增强了一些业务造成的join太多【这是无法避免的，但是设计库表的同时尽量向三范式靠拢，它能最大限度的合理处理数据，当然死死的遵循也是不可取的，必要的时候也是考虑反三范式的，完了，好话坏话都被我说了，那就分析一下他们吧】
三范式【三大特性】：
原子性：无重复的列,一列只能包含一个字段
不符合原子性：在校信息可拆分多个单位列
| 学号 | 姓名 | 在校信息 |
| 1 | 张三 | 读研，研一 |
| 2 | 李四 | 本科，大四 |
符合原子性：不能再次拆分多个单位列
| 学号 | 姓名 | 学历 | 年级 |
| 1 | 张三 | 读研 | 研一 |
| 2 | 李四 | 本科 | 大四 |
唯一性：主键约束，一行只能被唯一标识
不符合唯一性：只通过张三不确定是某一个学生
| 姓名 | 学历 | 年级 |
| 张三 | 读研 | 研一 |
| 李四 | 本科 | 大四 |
| 张三 | 本科 | 大三 |
| 王五 | 本科 | 大三 |
符合唯一性：通过学号可以确定某一个学生
| 学号 | 姓名 | 学历 | 年级 |
| 1 | 张三 | 读研 | 研一 |
| 2 | 李四 | 本科 | 大四 |
| 3 | 张三 | 本科 | 大三 |
| 4 | 王五 | 本科 | 大三 |
依赖性：非主键字段要严格依赖于主键字段
不符合依赖性：
| 学号 | 姓名 | 年级 | 辅导员编号 | 辅导员名称 | 辅导员性别 | 辅导员年龄 |
| 1 | 张三 | 研一 | 110 | 张飞 | 男 | 39 |
| 2 | 李四 | 大四 | 120 | 李白 | 男 | 40 |
符合依赖性：
| 学号 | 姓名 | 年级 | 辅导员编号 |
| 1 | 张三 | 研一 | 110 |
| 2 | 李四 | 大四 | 120 |
| 辅导员编号 | 辅导员名称 | 辅导员性别 | 辅导员年龄 |
| 110 | 张飞 | 男 | 39 |
| 120 | 李白 | 男 | 40 |
优势：没有冗余字段，增删改效率较高
劣势：join表太多，查询效率低，索引优化较难
反三范式【和三范式相反，这里就做过多说明】：
优势：查询效率高，索引优化相对简单
劣势：存在冗余字段，增删改效率较低
3.索引优化
a.什么是索引
索引是一种数据结构，它会持久化到硬盘，可以提高查询效率，你可以把它理解为排序好的可快速查找的数据。
b.什么情况下适合创建索引
主键自带索引
经常被查询的字段适合添加索引
外键适合添加索引
排序字段适合添加索引
分组字段适合添加索引
c.什么情况下不适合创建索引
不被查询的字段不适合创建索引
增删改比较频繁的表不适合创建索引
表数据较少的表不适合创建索引
表重复率比较高的字段不适合创建索引
d.如何避免索引失效
全值索引匹配
最左匹配原则
select * 有可能会造成索引失效
字符串查询的时候不加单引号会造成索引失效
sql上进行函数，计算，类型转换会造成索引失效
范围查找范围右边的字段查询会造成索引失效
like以通配符查询所有会生效
is null is not null or 不等号会造成索引失效
e.如何进行线上排查【只说流程哦】
首先是运营人员或者测试人员发现产品页面很慢
前后端人员确定是后端问题
后端人员确定不是代码逻辑问题，是sql问题
由项目组长或者项目经理告诉运维人员开启数据库阈值，进行慢sql查询
等个两到三天获取到慢sql
对获取的慢sql执行explan计划，可以看到sql的查询类型，
如：
是否是单表或者是子查询，或者产生临时表
查询是否是全表扫描或者是范围扫描等
sql索引及sql实际使用索引等
一般就是这些了，在实际中我们项目中表是设计都是采用单表，在执行计划中看看索引是否被使用等信息在进行优化
包括慢sql查询我们这边也是不使用的，我们这边整合了阿里云的Druid插件，它不仅提供了数据库连接的一下信息和sql的访问次数，成功次数及sql代码，最重要的是它提供了可视化页面，这点非常的好！