一个mysql优化就难住了？别怕，来看这张思维导图
前言：之前写过一篇mysql基础的思维导图的文章，感觉好像帮到了好多人，今天的，又整理一篇mysql调优的，希望能帮到大家
最近，周围的同事离职的越来越多，身边的小伙伴好像也有动作了，找他聊聊。
“咋了，你也要走？”
小伙伴：”现在的工作太枯燥，缺少成就感，想换一个，有技术挑战的那种“
”你现在不挺好么，leader对你也不错，也挺器重，感觉你前途一片光明“
小伙伴：”这叫不错？这叫器重？我这种边缘项目，一没技术难度、二没流量、三没数据量，更别谈高并发了，天天做不完的需求，修不完的BUG，在这里就感觉温水煮青蛙，我就是那只呱呱呱，我得去外面看看“
"..."
看来积怨已深，我只能打住，说了一些恭维的话，结束了交流。
这几天，感觉小伙伴的气压比较低，我猜是面试受打击了，于是又找他聊。
“最近咋了？情况不对啊”
小伙伴：“上次去面试，面试官问我，项目中用了那些SQL优化，我一下就懵了，没回答上来...”
“懵啥？”
小伙伴：“我这种天天接需求，写的SQL只关心查出来的数据正确与否 ，哪有需要做优化？”
“这...”
小伙伴：“只能怪自己，这破项目，SQL随便写写也不会出问题“
小伙伴：”最后出问题的是自己，我废了。”
小伙伴：“对了，常见的SQL优化有哪些？”
“行，我给你整理下。”
“其实大部分主要对查询进行优化，最重要的是尽量避免全表扫描”
- 适当的创建索引，考虑在 where 及 order by 涉及的列上建立索引
- 尽量避免在 where 子句中对字段进行 null 值判断、使用!=或<>操作符、使用 or 来连接条件、对字段进行函数操作等
- in 和 not in 也要慎用，否则可能会导致全表扫描
- 很多时候用 exists 代替 in 是一个好的选择
- 尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。
- 尽可能的使用 varchar 代替 char ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
SQL优化手段还有很多，大多数都是摸打滚爬的经验积累，只有自己碰到了，才有深刻的理解和体会。
这么说可能没什么特别的，那如果刚才的那些话这样看呢？
总图
分图
篇幅原因，只展示一部分，需要完整架构图的，点赞支持一下，然后私信“资料”即可
怎么样，这样话是不是就很体系了
但是这个只是解决方案，还真的不是我今天的重点，重点在于和同事聊天的那最后一句话：这破项目，随便写写SQL就解决了，出问题是我，我废了
大家应该都听过或正在经历：面试造航母，工作拧螺丝
但是，我想说，难道工作拧螺丝你就是个螺丝工了吗？难道你觉得你比一个在学校的大学生差嘛？不要为自己的偷懒找理由，可能这个时候会有人出来反驳我，每天工作加班累的要死，哪有时间。。。。吧啦吧啦，类似这样的话，当你说出这句话的时候，其实你就应该知道为什么同样是做程序员，有的人年薪8W，有的人80W了，最大的原因其实就是你已经放弃学习了，而程序员这么个随时在更替技术的行业，可能明天技术就会更新一轮，如果你忘记了学习，可能短时间不会有什么问题，但是时间一长呢？
比如说：
以前：会个ssm就能找工作 现在：微服务、分布式、源码、调优。。。
以前：会个大数据集群就可以 现在：参数调优、推荐系统。。。
兄弟，这才几年啊，jdk都已经14了，你又去了解过多少？spring源码看过多少？jvm调优又理解过多少？
最近，小编公众号后台有好多人私聊我说面试好难啊，现在面试都要什么人啊？小编想说，真的不是面试官再为难你，而是要求变高了，对于项目编码的要求也不是可以实现功能就行得了，所以对于人才的质量要求也高了，没得办法，你在说什么都不好使，什么crud是基础，其他的都是辅助，什么那家公司能不做crud，我想说：这算是你安慰自己觉得问题不大的借口吗？如果不是最好，如果是，那为什么还不行动起来呢？你还在犹豫什么呢？
不信，看一个大学生的笔记吧
基础：
消息队列：
后来者都如此努力，我们作为先行者，怎么可以不努力
最后，小编整理了一套技术资料不仅能精准消除技术盲点、累计面试经验，更可以攻克JVM、Spring、分布式、微服务等技术难题。这里也就不展示了，有需要的
关注公众号：Java架构师联盟，每日更新技术好文
