1.避免
select *
消耗cpu，io，内存，带宽；
count(1)和count(primary_key) 优于 count(*)
很多人为了统计记录条数，就使用 count(1) 和 count(primary_key) 而不是 count(*) ，他们认为这样性能更好，其实这是一个误区。对于有些场景，这样做可能性能会更差，应为数据库对 count(*) 计数操作做了一些特别的优化。
2.union all 替代 union
union 和 union all 的差异主要是前者需要将两个(或者多个)结果集合并后再进行唯一性过滤操作，这就会涉及到排序，增加大量的 CPU 运算，加大资源消耗及延迟。
3.避免类型隐式转换
4.避免where子句中进行函数操作
这将导致引擎放弃使用索引而进行全表扫描。
例：查询138开头手机号
SELECT phone FROM guide_phone_info WHERE SUBSTR(phone,1,3) = '138'
执行计划：
优化语句
SELECT * FROM guide_phone_info WHERE phone LIKE '138%'
同样的问题（不在索引做列运算）：
select id where age +1 = 10
修改为
select id where age = 9
5. OR改写为IN
in和or所在列有索引或者主键的话，or和in没啥差别，执行计划和执行时间都几乎一样。如果in和or所在列没有索引的话，性能差别就很大了。在没有索引的情况下，随着in或者or后面的数据量越多，in的效率不会有太大的下降，但是or会随着记录越多的话性能下降非常厉害，从第三中测试情况中可以很明显地看出了，基本上是指数级增长。
因此在给in和or的效率下定义的时候，应该再加上一个条件，就是所在的列是否有索引或者是否是主键。如果有索引或者主键性能没啥差别，如果没有索引，性能差别不是一点点！
