《收获，不止SQL优化》前言阅读小记

摘要: nothing

前不久买了一本书《收获，不止SQL优化》，那是因为经过金融服务那块的时候，看到有这么一本书，看着封面和目录还是酷酷的，回去我也买了一本，发现是以Oracle数据库来讲的，很多无法下手呀，其实我当时以为是一本讲sql语言的，然后已经放下这本书很久了，看不下去呀。

但是这个前言讲的故事还是挺有趣的“前言与意识，从优化方法到全书脉络，传说：一入IT深似海，从此菜鸟泪成河”。

下面简单梳理一下书中前言中讲的故事：

故事一：某天小王被告知系统的某个菜单访问非常慢，于是他负责介入优化，通过观察发现某条sql的执行计划访问某张表的时候没有走索引，觉得应该表应该加一个索引，他花了1个小时发现这个问题非常兴奋，于是动手开始建立索引，花了几分钟建立索引，随后发现sql走索引了，并且真的快了很多。

故事二：小王正在明明得意的时候不久，就被运营告知虽然这个菜单变快了，但是刚才持续几分钟时间出现访问该菜单一直报错的情况，随后正常。？？？为什么程序会出错，怎么又恢复了？

故事三：当天下午小王又接到电话，被告知菜单访问又变慢了。小王吃了一惊。于是登录检查，还真的变慢了，sql执行计划是正常走索引的，小王很郁闷。正在他素手无策的时候，小王接到电话，该菜单又变快了。晕，可是他什么都没有干。这是怎么回事？当晚，小王辗转反侧，无心睡眠。第二天。小王又接到电.....他奔溃了。

故事四：小王崩溃后无法正常工作，然后领导把这个问题给了别的同事处理，小王又满血复活地投入战斗。几天后下网迎来一个新任务，项目组中有一条sql很慢，希望可以优化一下。小王看了一眼觉得歪瓜裂枣的写的很不舒服，于是挽起袖子决定重写SQL，改改改。小王对新写完的sql一运行，发现比之前的sql慢很多，可怜的小王又崩溃了。

故事五：在小王再度崩溃之前，公司的sql优化大师正好经过，他分析了之后，建议将sql语句设计的某标的外键加上索引。后来大家发现真的变快了，他告诉小王，优化前可通过各种手段观察sql设计的表结构，索引等，看有没有不合理的地方，急于动手改造太盲目了，没有抓木矛盾的要点，而且改代码要测试预发，上线。小王频频点头

故事六：老王成长了，一周之后，小王又面对一条sql优化，这次他不动手改了，尝试加了索引，又尝试了调整表结构，结果效果都不明显。然后呢，崩溃了.......好在sql优化大师又出现了，这次没有修改表结构，而是和开发人员进行了半小时交谈，然后对sql进行重写，然后sql就变得飞快了。小王傻眼了，不是说尽量不着急动手改sql吗？悲催呀,怎么改才是对的？更让小王悲催的是，优化后的sql并不复杂，那是怎么变快的？

一入SQL深似海，从此菜鸟泪成河！！！

书中后面继续分析了这里的每一个故事出现的原因，太长了，我稍微摘录一点。小王的还是掌握了预定的sql优化基础技能的，但是因为经验少，同时也缺乏由经验转换成做事的方法论。

小王接到电话就开始优化了，难道不应该多问一句这是一直存在的问题，还是今天突然出现的。如果事突然出现的，那要看昨天晚上发布了什么，因为这次发布引起的故障可能性比较大，于是目标就清晰了。而如果是经常出现的故障，那应该同事已经处理过，那么获取他们之前的分析成果和经验，或者收集之前的日志与现在作比较，难道没有帮助吗？

故事三中，加了索引变快又变慢，系统复杂了，可能性是很多的。有可能也是这样一种情况，此时整个系统或者依赖的系统都非常慢，根本不只是这个菜单慢。 求助者没有提出其他模块慢或许她平时只用这个菜单模块。还有数据库所在的主机耗尽了cpu，内存等资源。忽快忽慢的，也可能是有坑人程序在。

故事二的几分钟失败可能是建索引的时候，锁了全表，导致更新数据失败。所以在业务高峰做DDL操作，严重影响了生产。

故事四吧小王动手改改改，效果差差差。解决问题要有目的性，不能没找到问题就动手。你觉得sql写的不好，实际上应该看慢在什么地方。

故事五，优化大师只是加了索引就变快了，有时候不需要改写sql就可以，改写的代价比较高，需要测试，预发，上线等。

故事六是小王没有生搬硬套了，他根本没有找到问题的本质。需要更具业务需求，砍掉多余的逻辑。

作者写了做事要有方法论，先整体后局部，解决问题要注重效率，先尽量考虑不该改写的优化，再考虑改写的优化。不改写的优化靠的是体系结构知识的沉淀，而改写则要考虑逻辑等价改写和业务改写两大思路，其中业务改写是sql优化的最高境界。