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

前不久买了一本书《收获，不止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优化的最高境界。