接触SQL蛮久了，自觉对里面的优化是最感兴趣的，接触的项目都比较大，很多表都是几千万数量级的，同时又要求系统对这些表能进行高效的读写，身边的同事都比较怕这块，一有锁表或者其他优化上的问题大都束手无策，很多时候我只能自己动手解决问题了，也积累一些经验。这里写的很多都是自己的观点，甚至是猜测和实践得出的结论，供看官们参考。第一篇是基础，优化大师们可以跳过啦。
先说下基本概念：下图书上都有很多，我自己稍微把结构又整理了下，里面有很多误区，先说下基本，后面几篇会继续展开说
SQL 优化的目的其实就是对实现某次查询或修改的时间更短，这个短说实话是没有极限的，当某些语句执行的比较频繁时，1秒的时间都要想办法去优化，当然笔者的建议一般情况是不要对5秒以下的语句做优化。回到上图，影响SQL语句效率的地方主要有三个。
一、查询优化器，就是SQL自动的去选择最高效找出结果的方法的工具，这里就有个误区，很多人以为这个需要时间么？其实是要的，SQL尽管智能，还是需要一个理解语句，和完成查询/修改的时间。我的建议是语句写的通俗易懂，一次查询关联的表小于6个，因为查询优化器可能会产生非常多的预估计划，N个表关联，最少需要分析N！次，最多可能达到（2n-2）！/（n-1）！次，从中寻找出最好的那个是非常费时的。还有一点需要说明的是，查询优化器的结果是找出资源使用最少的，而不是最快的。
二、执行计划，生成一个执行计划是需要耗费时间的，如果里面的语句能被重用将降低这个时间，这个时候相同的语句中的大小写保持一致都能提升性能。否则SQL会生成两个执行计划。
上图是执行计划中，其中红字部分是预估的查询行数，如果和最终的结果有很大的出入，说明这里需要在语句上做优化。
三、I\O,查看读写可以知道我们的语句是否有自身的问题语句前后加入下面这个命令，可以知道到语句对数据库的读写情况
降低读写很多时候要和执行计划做配合，增加好的索引也会降低读写，提示速度。
第一篇就先写这么多吧，后面会用具体案例展开说明优化的步骤，其实有些方法非常简单哦。