SQL审核的一些规则

                                           SQL审核的一些规则

      SQL Review是一个项目的重要过程，也是DBA提前介入项目，发现问题的好时机。
避免把有问题的SQL带到生产环境上而引发性能问题.不管是使用SQL Review工具还是人工审
核SQL MAP之类的文件，都有需要准守一些基本的规则,笔者就在实际的工作碰到的情况
做一个总结:

1,有没有不带WHERE条件的表SQL;对于大多数业务系统来说全表扫描都是有性能风险的
操作,可以和相关人员确认相关模块是主要业务模块还是偶尔使的模块.再决定是不是
这种方式合适.

2,带WHERE条件的SQL语句是否有合适的索引; 带WHERE条件的sql尽量在选择率高的字段
上增加索引，把结果限定到最小的范围.

3,带WHERE条件的索引列是不是有引发不使用索引的一些因素.这些是最容易引起问题的
一个点，经常有出现类型不匹配之类的问题，引发索引无效而走全扫描.其他的比如在
左边的索引列上使用函数操作等等。

4,DELETE和UPDATE操作是不是有带WHERE条件;对于不带WHERE条件的或是WHERE条件的范围
比较大的SQL要极度小心，Innodb由于锁的关系，对于这种语句是否WHERE条件上的索引是否合适，
会不会引起Gap Lock,最好的办法就是这种操作都要带上主键或是唯一索引.

5,是否存在有DDL操作;业务系统应该不要带有DDL操作，一般的系统带有DDL 操作都会引起很
严重的锁问题。如果必须要有类似的操作，考虑现有的实现方式是不是合适。

6,表连接条件的内表列上是否有合适的索引字段;对于mysql这种数据库只有NEST LOOP链接算法
来说，内表的列上有索引变得十分重要，避免对内表数据引起多次全表扫描.

7, 列上有一些常量计算和表达式计算;一些很明显或是已知的知道尽量不要写在SQL里，可以使用
手工计算结果，对于一些括号之类的操作可以考虑是否合适等等类似的情形.

8,复杂的SQL是否有进一步优化的余地;比如我们在子查询上，是不是可以改写成连接操作。开发的
同事比较喜欢写成子查询的方法，而改成连接的方式效率会更高，在实现相同的语义情况下.其他的
比如有时候连接是不是有存在的必要,针对具体问题再具体分析.