MySQL最佳实践(二)
不可太多，多了反而会拖慢更新速度。
4. ORDER BY created DESC的优化
时间排序是应用中比较常见的需求。细想，这时间不是自增长的嘛？那跟ID自增长不是一回事儿嘛？ 所以说，在ORDER BY 时，用自增长的主键ID，会比用created，省一个FILE SORT操作。快很多的。
5. Count(1), count(*), count(owner)的区别
count(1)等同于count(*)，等同于count(任何一个NOT NULL的字段)
count(owner)：若owner是可NULL的，则数出来的数跟上面的三种情况会少的。少的正好是那些owner is null的个数。
6. Don`t JOIN ON 不同数据类型
A表user_id作为B表的外键，这种很常见。此时，需注意user_id字段的类型，在两张表里都要保持一致。这样节省不必要的开支，比如，数据库替你做类型转换等。
7. 不要用全文索引(full-text index)
当前只有MyISAM才支持全文索引。而且，不太好用，可自定义性比较差，所以完全无视它即可。若真需要做全文索引，还是考虑用Lucene, Solr, ElasticSearch, Sphinx, Groonga, Xapian等吧。个个都是行家里手，功能齐全，可定义性强，随你搞。
8. Limit n,m 慢，慎用
大部分人翻页，可能都是靠这个的。数据量大时，这显然会很慢。网上有人推荐说，第一次查出来后，记住当前页的最后一个ID，然后，在查询下一页时，把这个ID做为限制条件加进去，然后取limit pagesize。
诸如此类，若细想，应该是能想出点儿可行之策的我觉的。其实，当数据量很大时，你可以换个角度想，如继续在limit n,m上做文章能还是直接换个查询方式，如用搜索引擎等。
9. 多字段索引
这个无需多说吧，道理应该是司空见惯了。
CREATE INDEX idx_col123 ON t (col1,col2,col3);
用法则：
where col1='' and col2=''
where col1=''
where col1='' and col3='' (col1时用索引，col3时一行行验证过滤的)
你想想B Tree啥样就知道了。（
mysql里应该是B+Tree, 查询时，逻辑相仿，区别不大）
10. 一 SELECT能否用多 索引？
可以。Mysql高一点的版本推出了merge optimization，支持的就是这功能。
11. JOIN vs. EXISTS 哪个更快？
1）没有定论，主要看JOIN的表大小，和one/many – to – one/many关联关系.
2) 需要明确的是：EXIST相比JOIN的优势在于 first match就返回，JOIN是能match的全部match.
3) JOIN相对于EXIST的优势在于可以根据实际情况选择执行的顺序(join order)，MySQL5.6之前，如果where中有EXISTS 执行顺序总是从外道内,现在好像变得更智能了。
4）小表JOIN大表时，用EXISTS可能更快。
A a JOIN B b ON （a.id=b.aid) WHERE a.owner='aaa' and b.cat='bbb';
执行顺序如下：
（取出A表内所有满足条件owner='aaa' 的记录）
JOIN ＝ 两个for内一一匹配
（取出B表内所有满足条件cat='bbb'的记录）
A a WHERE owner='aaa' and EXISTS
(SELECT 1 from B where cat='bbb' and a.id=aid)
执行顺序如下：
for (取出A表内所有满足条件owner='aaa' 的记录)
for (取出B表内所有满足条件cat='bbb'的记录)
check if a.id=b.aid
说明一点：里面的for，若无索引，得一条条全读一遍B表的数据。若有索引，则只需读一条对应记录即可。
根据上面执行逻辑，外加表大小和关联关系，你可以推导出用哪个更好，再测几次，看看执行计划啥的，大体就有定论了。