根据某一条件从数据库表中查询『有』与『没有』，只有两种状态，那为什么在写SQL的时候，还要SELECT count(*) 呢？

目前多数人的写法

多次REVIEW代码时，发现如下现象：
业务代码中，需要根据一个或多个条件，查询是否存在记录，不关心有多少条记录。普遍的SQL及代码写法如下。

SQL写法:

SELECT count(*) FROM table WHERE a = 1 AND b = 2

Java写法:

int nums = xxDao.countXxxxByXxx(params);
if ( nums > 0 ) {
  //当存在时，执行这里的代码
} else {
  //当不存在时，执行这里的代码
}

是不是感觉很OK，没有什么问题

优化方案

SQL写法:

SELECT 1 FROM table WHERE a = 1 AND b = 2 LIMIT 1

Java写法:

Integer exist = xxDao.existXxxxByXxx(params);
if ( exist != NULL ) {
  //当存在时，执行这里的代码
} else {
  //当不存在时，执行这里的代码
}

SQL不再使用count，而是改用LIMIT 1，让数据库查询时遇到一条就返回，不要再继续查找还有多少条了。

业务代码中直接判断是否非空即可。

总结

根据查询条件查出来的条数越多，性能提升的越明显，在某些情况下，还可以减少联合索引的创建。

为什么都说SELECT * 效率低

面试官：“小陈，说一下你常用的SQL优化方式吧。”
陈小哈：“那很多啊，比如不要用SELECT *，查询效率低。巴拉巴拉... ”

面试官：“为什么不要用SELECT * ？它在哪些情况下效率低呢？ ”
陈小哈：“SELECT * 它好像比写指定列名多一次全表查询吧，还多查了一些无用的字段。 ”

面试官：“嗯... ”
陈小哈：“emmm~ 没了 ”

陈小哈：“....??（几个意思）”

面试官：“嗯...好，那你还有什么要问我的么？ ”
陈小哈：“我问你个锤子，把老子简历还我！ ”

无论在工作还是面试中，关于SQL中不要用“SELECT *”，都是大家听烂了的问题，虽说听烂了，但普遍理解还是在很浅的层面，并没有多少人去追根究底，探究其原理。

废话不多说，本文带你深入了解一下"SELECT * "效率低的原因及场景。

不需要的列会增加数据传输时间和网络开销

用“SELECT * ”数据库需要解析更多的对象、字段、权限、属性等相关内容，在 SQL 语句复杂，硬解析较多的情况下，会对数据库造成沉重的负担。
增大网络开销；* 有时会误带上如log、IconMD5之类的无用且大文本字段，数据传输size会几何增涨。如果DB和应用程序不在同一台机器，这种开销非常明显
即使 mysql 服务器和客户端是在同一台机器上，使用的协议还是 tcp，通信也是需要额外的时间。

对于无用的大字段，如 varchar、blob、text，会增加 io 操作

准确来说，长度超过 728 字节的时候，会先把超出的数据序列化到另外一个地方，因此读取这条记录会增加一次 io 操作。（MySQL InnoDB）

失去MySQL优化器“覆盖索引”策略优化的可能性

SELECT * 杜绝了覆盖索引的可能性，而基于MySQL优化器的“覆盖索引”策略又是速度极快，效率极高，业界极为推荐的查询优化方式。

例如，有一个表为t(a,b,c,d,e,f)，其中，a为主键，b列有索引。

那么，在磁盘上有两棵 B+ 树，即聚集索引和辅助索引（包括单列索引、联合索引），分别保存(a,b,c,d,e,f)和(a,b)，如果查询条件中where条件可以通过b列的索引过滤掉一部分记录，查询就会先走辅助索引，如果用户只需要a列和b列的数据，直接通过辅助索引就可以知道用户查询的数据。
如果用户使用select *，获取了不需要的数据，则首先通过辅助索引过滤数据，然后再通过聚集索引获取所有的列，这就多了一次b+树查询，速度必然会慢很多。

由于辅助索引的数据比聚集索引少很多，很多情况下，通过辅助索引进行覆盖索引（通过索引就能获取用户需要的所有列），都不需要读磁盘，直接从内存取，而聚集索引很可能数据在磁盘（外存）中（取决于buffer pool的大小和命中率），这种情况下，一个是内存读，一个是磁盘读，速度差异就很显著了，几乎是数量级的差异。