如何书写高效的MySQL查询？

• How to write efficient MySQL query statements
  • WHERE子句中的书写注意事项
  • 模糊查询(like)时须要注意的事项
  • 索引
  • 字段类型
  • 表链接时的注意事项
  • 其余注意事项

WHERE子句中的书写注意事项

• 首先应考虑在 where 及 order by 涉及的列上创建索引。

• 下列操做会致使引擎放弃使用索引而进行全表扫描，是应尽可能避免的。

  • 1).在where 子句中使用!=或<>操做符

  • 2).在where子句中对字段进行null值判断
    如：

    select id from t where num is null;

    能够在num上设置默认值0，确保表中num列没有null值，而后这样查询：

    select id from t where num=0;

  • 3).在where子句中使用 or 来链接条件
    如：

    select id from t where num=10 or num=20;

    能够这样查询：

    select id from t where num=10
    union all
    select id from t where num=20;

  • 4).in 和 not in 也要慎用
    如：

    select id from t where num in(1,2,3);

    对于连续的数值，能用between就不要用in
    如：

    select id from t where num between 1 and 3;

    不少时候能够用exists代替in
    如：

    select num from a where num in(select num from b);

    用下面的语句替换：

    select num from a where exists(select 1 from b where num=a.num);

  • 5).在where子句中使用参数
    由于SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时，它必须在编译时进行选择。
    若是在编译时创建访问计划，变量的值仍是未知的，于是没法做为索引选择的输入项。
    以下面语句将进行全表扫描：

    select id from t where num=@num;

    能够改成强制查询使用索引：

    select id from t with(index(索引名)) where num=@num

  • 6).在where子句中对字段进行函数、算术运算或其余表达式运算
    如：

    select id from t where num/2=100;
    select id from t where date(createdate)>='2016-07-01';

    应改成:

    select id from t where num=100*2
    select id from t where createdate>='2005-11-30 00:00:00';

模糊查询(like)时须要注意的事项

• 左右都须要模糊匹配时，会致使全表扫描；

  select id from t where tablename like '%abc%'

• 若要提升效率，可从如下三点着手：

  • a.不以"%"开始，如：select id from t where tablename like 'abc%'。

  • b.若是必须使用like "%xxx" 的sql，可基于REVERSE()函数来建立一个函数索引。

    参考：http://blog.csdn.net/wangjunjun2008/article/details/52131668

  • c.能够考虑全文检索。
    首先若是表默认是innoDB,这种表的类型不支持全文检索，因此要先改变其类型为MyISAM。

    alter table song engine=MyISAM;

    而后要在对应的要进行查找的字段上面创建全文检索的索引：

    alter table add fulltext index(songname);

    若是要同时对多个字段进行检索能够这样:

    alter table add fulltext index(songname,singername);

    完成以上步骤后，就能够对表进行全文检索了。
    例如:

    select * from song where match(singername) against('周杰伦') ;

    或者多字段:

    select * from song where match(singername,songname) against('风雨');

    MYSQL目前可能只支持英文字符的全文搜索，如需使用全文检索须要把中文转化为拼音。
    能够在表里面为须要检索的字段添加一个拼音字段，检索的时候直接对拼音进行检索。
    参考：http://blog.sina.com.cn/s/blog_7865b0830101ach4.html

索引

• 复合索引
  在使用索引字段做为条件时，若是该索引是复合索引，那么必须使用到该索引中的第一个字段做为条件才能保证系统使用该索引，而且应尽量的让字段顺序与索引顺序相一致。

• 当索引列有大量数据重复时，SQL查询可能不会去利用索引
  并非全部索引对查询都有效，SQL是根据表中数据来进行查询优化的；
  如一表中有字段sex[male|female]几乎各一半，那么即便在sex列上建了索引也对查询效率起不了做用。

  这个时候能够用ENUM(枚举类型)，而不是VARCHAR，并对表结构进行优化(select column from table_name procedure analyse();)

  例如：

  SELECT loan_period FROM cbs_bsns_loan PROCEDURE ANALYSE();

• 索引并非越多越好
  索引当然能够提升相应的select的效率，但同时也下降了insert及update的效率；
  由于insert或update时有可能会重建索引，因此怎样建索引须要慎重考虑，视具体状况而定。
  原则上，一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

• 尽量的避免更新clustered索引数据列
  clustered索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将致使整个表记录的顺序的调整，会耗费至关大的资源。
  若应用系统须要频繁更新clustered索引数据列，那么须要考虑是否应将该索引建为clustered索引。

  MySQL InnoDb中的索引分为 Clustered Index (聚簇索引)和 Secondary Index (二级索引)；
  Clustered Index：每个InnoDB表都有一个特殊的索引，叫作clustered index，一般来说，clustered index和plrimary key是同一个意思。

  InnoDB选择clustered index原则以下：
  ①若是表上定义了primary key，则使用primary key做为clustered index。
  ②若是没有定义primary key，选择第一个非空的UNIQUE索引做为clustered index。因此，若是表只有一个非空的UNIQUE索引，那么InnoDB就把它看成主健了。
  ③若是即没有primary key,也没有合适的UNIQUE索引，InnoDB内部产生一个隐藏列，这个列包含了每一行的row ID, row ID随着新行的插入而单调增长。而后在这个隐藏列上创建索引做为clustered index。

  Secondary Index：除了Clustered Index以外的索引都是Secondary Index，每个Secondary Index的记录中除了索引列的值以外，还包含主健值。经过二级索引查询首先查到是主键值，而后InnoDB再根据查到的主键值经过主键/聚簇索引找到相应的数据块。

字段类型

• 尽可能使用数字型字段
  若只含数值信息的字段尽可能不要设计为字符型，这会下降查询和链接的性能，并会增长存储开销。
  由于引擎在处理查询和链接时会逐个比较字符串中每个字符，而对于数字型而言只须要比较一次就够了。
  好比，咱们的表不少是用字符串来作主键或链接字段，这里其实能够用字符串做为业务主键，但使用自增id作主键和链接字段；

• 尽量的使用 varchar/nvarchar(指定长度) 代替 char/nchar
  首先变长字段存储空间小，能够节省存储空间；
  其次对于查询来讲，在一个相对较小的字段内搜索效率显然要高些。

• 对于少数枚举值的字段使用 ENUM 而不是 VARCHAR 枚举类型，限定值的取值范围，好比性别（男，女，未知）等。
  ENUM 类型是很是快和紧凑的，其保存的是 TINYINT，但外表上显示为字符串。这样一来，用这个字段来作一些选项列表变得至关的完美。

  若是你有一个字段，好比“性别”，“国家”，“民族”，“状态”或“部门”，你知道这些字段的取值是有限并且固定的，那么，你应该使用 ENUM 而不是 VARCHAR。

  注意：不推荐在mysql中设置某一字段类型为enum，可是存的值为数字，好比‘0’，‘1’，‘2’；

  表结构优化建议

  select column from table_name procedure analyse();

表链接时的注意事项

• 尽可能用 inner join
  避免 LEFT JOIN 和 NULL；

• 尽可能将条件写到on中，而不是都写到where中
  on与where的执行顺序：
  ON条件（A LEFT JOIN B ON条件表达式中的ON）用来决定如何从 B 表中检索数据行。
  仅在匹配阶段完成之后，WHERE子句条件才会被使用，它将从匹配阶段产生的数据中检索过滤。
  因此在使用链接时，尤为是 left join（或right join）时，必定要在先给出尽量多的匹配知足条件，以减小须要匹配的数据量，并减小Where的执行。

  关于链接的用法参考：http://www.cnblogs.com/BeginMan/p/3754322.html

其余注意事项

• 任何地方都不要使用 select * from t ，而应用具体的字段。

• 尽可能使用表变量来代替临时表。
  若是表变量包含大量数据，请注意索引很是有限（只有主键索引）。

• 避免频繁建立和删除临时表，以减小系统表资源的消耗。

• 在新建临时表时，若是一次性插入数据量很大，那么可使用 select into 代替 create table，避免形成大量 log ，以提升速度；若是数据量不大，为了缓和系统表的资源，应先create table，而后insert。

• 若是使用到了临时表，在存储过程的最后务必将全部的临时表显式删除，先 truncate table ，而后 drop table ，这样能够避免系统表的较长时间锁定。

• 尽可能避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

• 千万不要 ORDER BY RAND()。