数据库优化方案

1：避免全表扫描，考虑在where及orderby涉及的列上建立索引

2: 避免where字句中对字段进行null值判断，导致引擎放弃索引而进行全表扫描

3：避免在where字句中使用 !=,>操作符，引擎放弃索引而进行全表扫描

4：避免在 where 子句中使用or 来连接条件

5：慎用in 和 not， 可以用 exists 代替 in

6：慎用 like 'XXX%'，要提高效率，可以全文检索。

7：应尽量避免在 where 子句中对字段进行表达式操作，如： select id from t where num/2=100

应改为select id from t where num=100*2

8：避免在where子句中对字段进行函数操作 select id from t where substring(name,1,3)='abc' 改为: select id from t where name like 'abc%'

9：在使用索引字段作为条件时，如果该索引是组合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。(索引的最左前缀原则)

10：并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。

11： 索引不是越多越好，索引可以提高select 的效率，同时也降低 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引。

12： 任何地方都不要使用 select * from t ，用具体的字段列表代替“*”

13：避免频繁创建和删除临时表，以减少系统表资源的消耗。

14：在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert

15：尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。 数据库中的数据在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大

16：读写分离。通过数据库配置设置， mysql复制时，产生了多个数据副本（备库），为减少服务器压力，备库用于处理读操作，主库可同时处理读写。备库的复制是异步的，无法实时同步，读写分离的主要难点也在于备库上的脏数据。通常如果使用备库进行读，一般对数据的实时性要求不能太高。

17：分库、分表。 分库：当数据库中的表太多，可以考虑将表分到不同的数据库 分表 水平分表：将一些列分到另一张表 垂直分表：将历史信息分到另一张表中，很久之前的记录少有查询

18： 利用缓存存储经常被查询的数据。利用redis、memcache