mysql查询语句优化

联表查询:

1️⃣SELECT ta.sid, ta.instance_id, ta.user_id, *******

FROM t_action ta, t_instance ti

WHERE    ta.status = 3 *******

AND ta.instance_id = ti.sid

ORDER BY ta.sid DESC

LIMIT 10

 这句explain的结果就是: ta:Using index; Using temporary; Using filesort    ti:Using where

 

说明:这里的ta和ti表 关联查询 ta表的instance_id和 ti的sid字段关联,再经过SID排序

由于ta表里是没有game_id的 因此order by的时候 会把ti表的结果给缓存起来

但由于ti表要缓存的数据不少,最后多出的又要放进磁盘内存中,因此就有了using filesort,最后再把磁盘的一并释放掉;每次查询都如此往复,天然而然查询会慢下来.

 

解决方案:将这个查询语句拆分红两句去查询或者在ta表中野加一个game_id字段 

 

2️⃣SELECT COUNT(sid)

 

FROM T_***

WHERE sid > 0

由于公司数据库mysql用的是InnoDB而不是myisam, 若是是myisam数据库就会很快,而InnoDB须要全盘扫描会很慢; 

二者区别: 

对于count()查询来讲MyISAM更有优点

由于MyISAM存储了表中的行数记录，执行SELECT COUNT() 的时候能够直接获取到结果，而InnoDB须要扫描所有数据后获得结果。

可是注意一点：对于带有WHERE 条件的 SELECT COUNT()语句两种引擎的表执行过程是同样的，都须要扫描所有数据后获得结果

 

解决方案:不要一会儿给出结果,进行定时任务缓存处理,当对该表进行修改操做时将缓存删除; 

 

 

另一些优化的例子:

1)尽可能少用负条件查询;

假设咱们有一个Order表，表中有一个字段是Status，这个字段有4个值，分别是0=待支付、1=待发货、2=待收货、3=已完成。

这时，咱们要查询全部已经支付的订单，不少人就会写这样的SQL：

select * from Order where Status != 0

这就是一个很差的习惯了。负向条件查询（例如：!=、not in、not exists）都是不能使用索引的，当Order表中的数据到达必定量级时，这个查询的效率会急剧的降低。因此，正确的写法应该是：

select * from Order where Status in (1,2,3)

2)尽可能少用前导模糊查询;

假设咱们如今要根据用户的订单号（OrderNo）查询用户的订单，若是是直接经过SQL查询的话，尽可能不要使用前导模糊查询，也就是：

select * from Order where OrderNo like '%param'

或者

select * from Order where OrderNo like '%param%'

由于，前导模糊查询是没法命中索引的，因此，会整个数据库去检索，效率至关的差，而非前导模糊查询则是可使用索引的。

所以，咱们尽可能不要把通配符放在前面，改为下面这样：

select * from Order where OrderNo like 'param%'

3)尽可能不要在条件字段上加运算;

假设，如今有一个需求，是要查询2018年整年的订单数据，咱们就须要经过建立时间（CreateTime）来进行检索，可是，有些程序员就喜欢这样写SQL：

select * from Order where Year(CreateTime)=2018

而后，每次执行时就会发现，查询的速度异常的慢，致使了大量的请求挂起甚至超时。这是由于，咱们即便在CreateTime上创建了索引，可是，若是使用了运算函数，查询同样会进行全表的检索。

因此，咱们能够改为这样：

select * from Order where CreateTime > '2018-1-1 00:00:00'

4)当查询容许null的列值时,须要特别注意;

咱们在建立表的字段时，若是这个字段须要做为索引时，尽可能不要容许Null。由于，单列索引不会存Null值，复合索引不存全部索引列都为Null的值，因此若是列容许为Null，可能会获得“不符合预期”的结果集。

例如：咱们有一个User表，其中有UserName字段记录了用户的名字，而且添加了索引。

如今咱们执行了这样一个查询：

select * from User where UserName != '小倩'

但结果是这样的

 那位UserName为Null的数据并无能包括进来。所以，若是咱们想要包含这个用户的话，最好可以设置一个默认值。

5)复合索引使用时须要注意顺序;

登陆，确定是咱们使用得最多的一个查询了，为了保证效率，咱们为LoginID和Password加上了复合索引。

当咱们使用

select * from User where LoginID = '{LoginID}' and Password = '{Password}'
select * from User where Password = '{Password}' and LoginID = '{LoginID}'

查询时，都是可以准备的命中索引。当咱们使用：

select * from User where LoginID = '{LoginID}' 

查询时，也是可以命中索引的。可是，当咱们使用

select * from User where Password = '{Password}' 

查询时，确没法命中索引，这是什么缘由呢？

这是因为，复合索引对于查询的顺序是很是的铭感的，因此，符合索引中包含了几种规则，其中就有全列匹配和最左前缀匹配。

当全部列都可以匹配时，虽然查询的顺序上有不一样，可是查询优化器会将顺序进行调整，以知足适合索引的顺序，因此，顺序的颠却是没有问题的。

可是，若是全部列不能匹配时，就必须知足最左前缀匹配了，也就是，必须按照从左到右的顺序进行排列。所以，当咱们创建是索引是<LoginID, Password>时，where Password = '{Password}' 就不知足最左前缀规则，没法命中索引了。

 6)结果惟一时别愣着;

 

一般，咱们设计User表时，并不会把LoginID做为主键，可是，LoginID确会在业务逻辑中验证惟一性，所以，若是使用

 

select * from User where LoginID = '{LoginID}'

查询时，结果必定只有一条。可是，数据库是不知道的，即便找到了这惟一的一条结果，他也会一直继续，直到扫描完全部的数据。

所以，在执行这样的查询时，咱们能够优化一下，改为：

select * from User where LoginID = '{LoginID}' limit 1

这样，当查询到结果时，就不会再继续了。

OVER!