Sql查询优化数据库索引使用及优化

ゝ一世哀愁。 2022-03-06 19:16 344阅读 0赞

## 可能导致查询缓慢的原因 ##

*  数据量过大
 *  表设计不合理
 *  sql语句写得不好
 *  没有合理使用索引

## SQL查询语句的优化 ##

*  查询语句中不要使用 \*
 *  尽量减少子查询，使用关联查询（left join,right join,inner join）替代
 *  减少使用IN或者NOT IN ,使用exists，not exists或者关联查询语句替代
 *  or 的查询尽量用 union或者union all 代替  
    (在确认没有重复数据或者不用剔除重复数据时，union all会更好)
 *  合理的增加冗余的字段（减少表的联接查询）
 *  增加中间表进行优化（这个主要是在统计报表的场景，  
    后台开定时任务将数据先统计好，尽量不要在查询的时候去统计）
 *  建表的时候能使用数字类型的字段就使用数字类型（type,status…），数字类型的字段作为条件查询比字符串的快
 *  那些可以过滤掉最大数量记录的条件必须写在WHERE子句的最末尾

## 索引的优化 ##

在数据库中索引是管理数据排序的一种数据结构，相当于是数据的目录，用于协助数据查询，常见的索引实现有B-tree和B+tree

### 索引的类型 ###

*  主键索引
 *  唯一索引
 *  组合索引
 *  普通索引

### 什么时候索引不生效 ###

*  使用like关键字模糊查询时，% 放在前面索引不起作用，只有“%”不在第一个位置，索引才会生效（like ‘%文’–索引不起作用）
 *  使用联合索引时，只有查询条件中使用了这些字段中的第一个字段，索引才会生效
 *  使用OR关键字的查询，查询语句的查询条件中只有OR关键字，且OR前后的两个条件中的列都是索引时，索引才会生效，否则索引不生效。
 *  尽量避免在where子句中使用!=或<>操作符,避免使用in和not in操作，否则引擎将放弃使用索引而进行全表扫描。
 *  对查询进行优化，应尽量避免全表扫描，首先应考虑在where以及order by涉及的列上建立索引。
 *  应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：  
    　　select id from t where num/2=100  
    　　应改为:  
    　　select id from t where num=100 \* 2
 *  尽量避免在where子句中对字段进行函数操作,将导致引擎放弃使用索引而进行全表扫描。
 *  不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
 *  并不是所有的索引对查询都有效，sql是根据表中的数据来进行查询优化的，当索引列有大量数据重复时，sql查询不会去利用索引，如一表中有字段sex，male，female几乎各一半，那么即使在sex上建立了索引也对查询效率起不了作用。
 *  索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一般一个表的索引数最好不要超过6个。
 *  尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会 逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
 *  mysql查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作，尽量不要包含多个列的排序，如果需要最好给这些列建复合索引。
 *  order by 索引 ，不起作用的问题（除了主键索引之外）：
    
     *  如果select 只查询索引字段，order by 索引字段会用到索引，要不然就是全表排列；
     *  如果有where 条件，比如where vtype=1 order by vtype asc . 这样order by 也会用到索引！