首先对于SQL优化的概念大家都会有一种潜意识的错觉，那就是创建索引，对于业务同学来说，就会产生一种不好的使用习惯，比如有一张数据表test,有5个字段,业务同学也不知道后续怎么去更好的使用，干脆建五个索引好了，毫无疑问，这是不建议的，我们希望SQL优化的内容能够尽可能从一个更加宏观的角度来看待，而不是仅仅从索引的角度去考虑。
所以我希望从下面的几个角度来简单的说一下。
- SQL优化的一些技能点
- 什么样的SQL最优
- SQL优化小结和展望
- SQL优化的一些技能点
对于SQL优化的技能点，因为涉及的内容实在是太多了，我们就捡几个点来做下抛砖引玉。
1）.key_len的计算方法
2）.派生表
3）.半连接
4）.反连接
5）.优化器高级特性
6）.事务降维
我们做SQL优化，执行计划是必须要搞明白的，但是相反，很多同学对于执行计划的理解是有误的，比如如下的SQL语句：
其实我们可以看到type是index,其实在这种情况下SQL语句的索引使用代价是最高的，即全索引扫描。
而里面有一个指标key_len是大家相对容易忽略的，它是有一套自己的计算法则，比如根据数据类型，是否允许为null,如果是varchar类型，需要额外补充2个字节，那么如果字段为depart_id int(11),depart_name varchar(20),字符集为gbk,则key_len为5是4+1的结果，而如果选择了字段depart_name则是20*2+1+2=43
而对于派生表，半连接和反连接，其实对于很多开发同学来说会感觉比较陌生，其实对于大多数业务使用来说是比较常见的，这是因为这些术语看起来比较专业，会造成一种技术的隔阂。
至于优化器高级特性，我们可以认为是一种设计思路，它主要是基于辅助索引层面来做的优化，常见的ICP，BKA,MRR等特性看着这些简称很容易被唬住，但是了解了实现原理之后就会发现，这是优化器层面很必要的工作，而从使用来说，仅仅体现为一个数据库优化参数的开关。
对于事务降维策略，有如下的几个策略可供参考，也是在这些年的工作总结中摸索到的。
降维策略1：存储过程调用转换为透明的SQL调用
降维策略2：Drop 操作转换为可逆的DDL操作
降维策略3：Truncate操作转换为安全的DDL操作
降维策略4：DDL操作转换为DML操作
降维策略5：Update操作转换为Insert操作
在我们对接业务进行整体优化的时候，我们需要问自己和业务同学一个问题，我们的这个业务一定需要事务吗，对于很多业务来说，其实从OLTP,OLAP的角度去衡量是不够准确的，我们可以做事务降维，从而达到一种可控可逆的操作模式。
2) 什么样的SQL最优
这是一个说起来简单做起来难的问题，
对于我来说，我认为SQL首先要符合规范，不是符合国际标准的部分，而是贴近业务场景的规范，比如一个表的字段数控制在20个以内，表中最多包含5个索引，不允许线上业务drop和truncate操作，这些是国际标准做不了的事情，一定是在业务层面不断沉淀和梳理得到的一些经验数据。
很多好的SQL其实都是足够简洁，很清晰的，就如同开发同学写代码一样，那些优秀的开源代码都是很简洁，很清晰的。所以从这个层面来说SQL审核就尤为重要了。
另外一个层面就是SQL的生命周期管理，比如一条SQL产生了性能问题，那么我们想知道它的执行频率和细节，在整个负载中所占到的比例，如何优化和改进，执行计划是怎样的，优化这条SQL是否会影响其他的SQL语句等，这些是我们在业务接入的过程中需要明确的问题和边界。
而对于优秀的SQL我们应该开绿灯，那就是通过服务来提升这种优越感，我们可以通过数字化可视化的方式，比如对SQL语句打分等机制来进行管理，会使得规范的过程更加的平滑。
3.SQL优化小结和展望
对于优化我今年的一大感受就是简单，简单其实可以解决很多问题，比如我们对一个业务系统通过事务降维，把存储过程逻辑改造为SQL形式，整体的复杂度降低了近100倍。
所以我们所说的优化需要换一种思路，不是要做更多，而是可以做更少，做的更加高效，在执行的过程中同时做到一种平衡，这是资源和时间的平衡。
而对于很多业务同学来说，如果能够在索引层面进行更加深入的理解，无意是一种更好的方式，所以行业内的索引自动化已经初见端倪，从本质上来说，索引是对于数据来说具有侵入性的，能够在索引层面做到一些更加高效的管理，是一种理想的优化方式。
版权申明：本站文章均来自网络，如有侵权，请联系01056159998 邮箱：itboby@foxmail.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有
