MySQL踩过的那些坑 mysqld

一、SQL执行顺序

1. from

2. join

3. on

4. where

5. group by(开始使用select中的别名，后面的语句都可以使用)

6. avg sum(聚合函数)

7. having

8. select

9. distinct

10. order by

11. limit

从这个顺序不难发现，所有的查询语句都是从from开始执行的，在执行过程中，每个步骤都会为下一个步骤生成一个结果集，这个结果集将作为下一个执行步骤的输入。

二、LEFT JOIN中，on和where条件的区别

1. on条件是在生成临时表时使用的条件，它不管on后所带的条件是否为真，都会返回做表中的记录

2. where条件是先生成临时表后，再对临时表进行过滤的条件。这时已经没有LEFT JOIN的含义了，条件不为真就全部过滤掉。

三、INNER JOIN中，on和where条件的区别

使用join时，过滤条件写在on或者where之后，返回的结果是一样的，那么他们的执行效率哪个更高，还是一样的？

四、ORDER BY与LIMIT一起使用的陷阱

MySql在执行limit的时候不会查询到所有的结果集，而是找到符合条件的行后立刻返回。Order by排序的时候，如果排序字段值相同，那么这些相同值所在的记录的顺序是随机的，但对于同一个结果集，其顺序也是固定的。因此当limit与order by一起使用时，如果遇到相同的排序字段值，加上limit的取值不同，会导致排序不稳定，出现在第一页的记录可能会出现在第二页。

五、MySQL函数的使用

1. DATE_FORMAT函数中，时间格式应为标准时间格式，否则返回null

2. CONCAT函数中，如果有一个值是null，则返回null

3. FIND_IN_SET函数中，如果有一个值是null，则返回false

六、UNION和NUION ALL的使用

1. 都是对两个结果集进行并集操作，上下SQL语句中查询的字段要相同

2. UNION对两个结果集进行并集操作，不包括重复行，同时进行默认规则排序，默认规则为查询的第一个字段的升序。

3. UNION ALL对两个结果集进行并集操作，包括重复行，不进行排序

4. 可以在最后一个结果集中指定order by子句改变排序方式

七、SQL编写注意事项

⑴、做连接查询的时候，连接字段的字符集应相同，否则会导致索引失效。

⑵、应尽量避免在where子句中使用!=或<>操作符，否则引擎将放弃使用索引而进行全表扫描。

⑶、对查询进行优化，应尽量避免全表扫描，首先考虑在where及order by涉及的列上建立索引。

⑷、应尽量避免在where子句中字段进行null值判断，否则引擎将放弃使用索引而进行全表扫描。

⑸、OR前后两个条件都要有索引整个SQL才会使用索引，只要有一个条件没索引整个SQL就不适用索引。

⑹、MySQL将IN()列表中的数据先进行排序，然后通过二分查找的方式来确定列表中的值是否满足条件，这是一个O(log n)复杂度的操作，等价地转换成OR查询的复杂度为O(n)，对于IN()列表中大量取值的时候，MySQL的处理速度将会更快。

⑺、左模糊查询将导致全表扫描。

⑻、不要在where子句中对字段进行函数、表达式操作，这样将导致全表扫描。

⑼、在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，应尽可能的让字段顺序与索引顺序一致。

⑽、避免隐式类型转换，如字符串应加单引号，否则会导致全部扫描。

⑾、任何地方都不要使用select * from t，用具体的字段列表代替“*”，不要返回用不到的任何字段，这样会导致回表。

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

⒀、尽量避免大事务操作，提高系统并发能力。