对于 select*要时刻保持谨慎的态度

绝大多数情况，是不需要 select*的。一旦使用了这种语句，便会让优化器无法完成索引覆盖扫描这类优化，而且还会增加额外的I/O、内存和CPU的消耗。 当然，使用 select*也并不是全是坏处，合理的使用 select*可以简化开发，提高相同代码的复用性。

慎用 join操作

这算是一条禁忌吧，很多公司的互联网产品都杜绝join操作，换成先从一张表中先取出数据id，再从另外一张表中使用 wherein查询的两次单表查询操作。主要是以下几点原因：

• 让应用的缓存(redis、memcache等)更高效。例如在第一张表中查询出部分id了，如果命中了缓存，就可以省去一条where in语句了。
• 更容易应对业务的发展，方便对数据库进行拆分，更容易做到高性能和高扩展。
• 对where in中的id进行升序排序后，查询效率比join的随机关联更高效
• 减少多余的查询。在应用层中两次查询，意味着对某条记录应用只需要查询一次，而使用join可能需要重复的扫描访问一部分数据。
• 单张表查询可以减少锁的竞争。

假如非用不可，可以采用以下方式来优化：

• 确保 ON或者 using子句中的列上有索引
• 确保任何的 groupby和 orderby中的表达式只涉及到一个表中的列。

在性能要求比较高的场景中，杜绝查询中使用 临时表

MySQL的临时表示没有任何索引的，使用临时表一般都意味着性能比较低,因此在对性能要求比较高的场景中，最好不要使用带有临时表的操作：

• 未带索引的字段上的 groupby操作。
• UNION查询。
• 查询语句中的子查询。
• 部分 orderby操作，例如 distinct函数和 orderby一起使用且 distinct和 orderby同一个字段。再例如某些情况下 groupby和 orderby字段不同。

具体是否用到临时表，可以通过 explain来查看，查看 Extra列的结果，如果出现 Usingtemporary则需要注意。

count()函数优化

count()函数有一点需要特别注意：它是不统计值为NULL的字段的！所以：不能指定查询结果的某一列，来统计结果行数。即 count(xx column) 不太好。如果想要统计结果集，就使用 count(*)，性能也会很好。

尽量不使用子查询

尽量别使用子查询，尽可能的使用关联来代替