一、
（1）负向条件查询不能使用索引 例如：！= / not in /not exists
（2）前导模糊查询不能使用索引 例如： like "%sk"
（3）数据区分度不大的字段不宜使用索引 例如： 性别
（4）在属性上进行计算不能命中索引
（5）如果明确知道只有一条结果返回，limit 1能够提高效率
（6）把计算放到业务层而不是数据库层，除了节省数据的CPU，还有意想不到的查询缓存优化效果。
select * from order where date < = CURDATE()这不是一个好的SQL实践，
应该优化为：$curDate = date('Y-m-d');$res = mysql_query( 'select * from order where date < = $curDate');
（7）隐式类型转换走不到索引，全是数字的字符串类型需要加上""（双引号）
二、SQL语句中IN包含的值不应过多，对于连续的数值，能用 between 就不要用 in 了
三、如果排序字段没有用到索引，就尽量少排序
四、尽量用union all代替union
union和union all的差异主要是前者需要将结果集合并后再进行唯一性过滤操作，这就会涉及到排序，增加大量的CPU运算，加大资源消耗及延迟。
当然，union all的前提条件是两个结果集没有重复数据。
五、区分in和exists， not in和not exists
区分in和exists主要是造成了驱动顺序的改变（这是性能变化的关键），如果是exists，那么以外层表为驱动表，先被访问，
如果是IN，那么先执行子查询。所以IN适合于外表大而内表小的情况；EXISTS适合于外表小而内表大的情况。
六、使用合理的分页方式以提高分页的效率
select id,name from table_name limit 866613, 20
使用上述sql语句做分页的时候，可能有人会发现，随着偏移量的增加，直接使用limit分页查询会越来越慢。
优化的方法如下：可以取前一页的最大行数的id，然后根据这个最大的id来限制下一页的起点。比如此列中，上一页最大的id是866612。sql可以采用如下的写法：
select id,name from table_name where id> 866612 limit 20七、建索引的几大原则
1.最左前缀匹配原则，非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。
2.=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式。
3.尽量选择区分度高的列作为索引，区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录。
4.索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’)。
5.尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。
八、关于JOIN（尽量少用）
-
LEFT JOIN 左表为驱动表
-
INNER JOIN MySQL会自动找出那个数据少的表作用驱动表
-
RIGHT JOIN 右表为驱动表
- 使用建议：
-
合理利用索引
被驱动表的索引字段作为on的限制字段。
利用小表去驱动大表