数据库优化SQL优化之SELECT优化 ——避免全表扫描

在数据库操作中，一个全表扫描(full table scan)可能是整个应用的瓶颈，因此，我们尽量

要避免不必要的全表扫描。而如果你发现一条sql是全表扫描，一般的解决步骤是：

        1、运行执行计划获得具体的sql语句查询分析：

                   方法：explain sql;

                   分析：至少能或得这些信息，1、表的join顺序(按计划的上到下join)， 2、是否

                               使用索引，3、可能会使用的索引

        2、添加对应的索引，或是重写查询sql，或更换join顺序等

        3、如果查询对当前的结构不满意，可以考虑重建表

下面分别说一下全表扫描可能发生的情形：

         1、在on或者where字句中,使用的列没有索引，可以考虑加一个索引

         2、表很小，大约少于10行，这个没有什么危害，因为即使你有索引，优化器也会判断

                在边读索引边取数据时，直接全表扫描快些

         3、你在一个where字句中使用含有索引的列，但这个列的值很集中化，比如字段 gender,

                这个的值就两个值male 和 female，如果使用索引反而会慢些，不使用索引会更快，这

                 种情况不用担心

         4、这个跟第三条类似，就是当你的一个索引，他的每个键对应多个值，即基数很低

               (low cardinality)，因此可能会选择全表扫描

下面说一下对与避免发生全部扫描的时间:

         1、对于使用or查询的语句，这种查询可能会产生全表扫描，他的策略是以一个一个比较

                如果符合要求，则选出来，但这样的操作会很慢，我们可以用union来做这样的查询，

                当然union要快的前提是，你对两个条件都有索引，如：

select * from table1 where key1 < 10 or key2 > 60

                 可以更改为：

select * from table1 where key1 < 10 union select * from table1 where key2 >60

         2、对于使用memory引擎的，建立索引时，默认是hash索引，这个的支出的访问单行数据很快，

                但如果你有类似的范围操作如>= , <= , between 时，可以考虑建立索引用btree类型的，方法为:

create index index_name on table(col_name) using btree;

         3、当你分析确定必须使用某个索引，但执行计划却不使用该索引，可以使用force index,方法为:

select * from table_name force index index_name where clause

         4、使用analyze table table_name来更新索引的键的分布，这个会影响jion表的顺序