1、EXPLAIN 关键字
select_type ： simple 它表示简单的select,没有union和子查询
type： 访问类型 ALL 扫描全表, EXPLAIN select * from sk_user index 只查询索引, EXPLAIN select found_time from sk_user range 根据范围通过索引查询 一般查询语句最少得到这个程度, EXPLAIN select * from sk_user where found_time > '2015-10-22 00:00:00' ref 根据具体值通过索引查询, EXPLAIN select * from sk_user where found_time = '2015-10-23 14:11:02' eq_ref, const, system
possible_keys： sql可能被用到的索引
key： sql正在使用的索引
rows： 查询的记录行数
2、mysql隐式类型转换问题 如果sql中出现隐式类型转换，则查询条件不会走索引 EXPLAIN select * from sk_user where found_time > now() EXPLAIN select * from sk_user where found_time > DATE_FORMAT(now(),'%Y-%c-%d %H:%i:%s')
3、 1=1 sql在执行之前需要解析，而在mysql中 1=1这个查询条件 需要解析时判断这个语句的语义，最终忽略它， 这个是需要消耗服务器资源的，当然数据量少的时候几乎没有感知。但是有些数据库当中1=1的条件并不会被解析器优化掉。
4、count(1)和count(*) count(1) 空行会被忽略
5、明确返回列
6、关键字大写 数据库会自己把关键字转换成大写，也就是说如果在写sql时关键字都写成大写的话，sql预编译时会少一步 mysql数据库....这个数据库sql是区分大小写的，我们这里不区分 是因为我们配置数据库的时候设置了大小写不敏感
7、like问题，%在前面时， 不会走索引
8、in和exist IN适合于外表大而内表小的情况；EXISTS适合于外表小而内表大的情况，一般情况下都建议采用EXISTS。
9、避免深层嵌套 原则上嵌套查询需要控制在3层以内。
10、join和子查询 因为在mysql体系当中，有子查询时，mysql会给内层查询建立临时表，而临时表用完之后需要销毁，所以比较而言join的效率会高 在查询中尽量避免出现创建临时表的操作。
11、排序问题 减少排序数据和使用索引排序都会提高排序效率，排序字段有空数据时，排序效率下降
12、避免or 在适当的场景中 使用union all代替or会有效提高sql效率
13、优化使用频率高的sql 使用频率越高的sql，优化的优先级越高
14、is not null 查询条件中不要出现is null或者is not null
15、在查询条件中，尽量避免运算 16、尽量避免update表的全部字段
17、where的先后顺序问题 执行时，是从右往左执行。
18、DISTINCT和EXISTS 在能使用EXISTS的时候 尽量不使用DISTINCT
19、使用>= 替换 > select * from a where id >= 4 select * from a where id > 3 两者的区别在于，前者DBMS将直接跳到第一个id等于4的记录而后者将首先定位到id=3的记录并且向前扫描到第一个id大于3的记 录。
20、联合索引问题 在使用联合索引时，必须首先使用联合索引的第一个字段