共计 4009 个字符，预计需要花费 11 分钟才能阅读完成。
最近我在公司优化过几个慢查问接口的性能，总结了一些心得体会拿进去跟大家一起分享一下，心愿对你会有所帮忙。
咱们应用的数据库是 Mysql8，应用的存储引擎是Innodb。这次优化除了 优化索引 之外，更多的是在优化count(*)。
通常状况下，分页接口个别会查问两次数据库，第一次是获取具体数据，第二次是获取总的记录行数，而后把后果整合之后，再返回。
查问具体数据的 sql，比方是这样的：
select id,name from user limit 1,20;它没有性能问题。
但另外一条应用 count(*)查问总记录行数的 sql，例如：
select count(*) from user;却存在性能差的问题。
为什么会呈现这种状况呢？
1 count(*)为什么性能差？
在 Mysql 中，count(*)的作用是统计表中记录的总行数。
而 count(*) 的性能跟存储引擎有间接关系，并非所有的存储引擎，count(*)的性能都很差。
在 Mysql 中应用最多的存储引擎是：innodb和myisam。
在 myisam 中会把总行数保留到磁盘上，应用 count(*)时，只须要返回那个数据即可，无需额定的计算，所以执行效率很高。
而 innodb 则不同，因为它反对事务，有MVCC（即多版本并发管制）的存在，在同一个工夫点的不同事务中，同一条查问 sql，返回的记录行数可能是不确定的。
在 innodb 应用 count(*)时，须要从存储引擎中一行行的读出数据，而后累加起来，所以执行效率很低。
如果表中数据量小还好，一旦表中数据量很大，innodb 存储引擎应用 count(*)统计数据时，性能就会很差。
2 如何优化 count(*)性能？
从下面得悉，既然 count(*) 存在性能问题，那么咱们该如何优化呢？
咱们能够从以下几个方面着手。
2.1 减少 redis 缓存
对于简略的 count(*)，比方：统计浏览总次数或者浏览总人数，咱们能够间接将接口应用 redis 缓存起来，没必要实时统计。
当用户关上指定页面时，在缓存中每次都设置成 count = count+ 1 即可。
用户第一次拜访页面时，redis 中的 count 值设置成 1。用户当前每拜访一次页面，都让 count 加 1，最初从新设置到 redis 中。
这样在须要展现数量的中央，从 redis 中查出 count 值返回即可。
该场景无需从数据埋点表中应用 count(*)实时统计数据，性能将会失去极大的晋升。
不过在高并发的状况下，可能会存在缓存和数据库的数据不统一的问题。
但对于统计浏览总次数或者浏览总人数这种业务场景，对数据的准确性要求并不高，容忍数据不统一的状况存在。
2.2 加二级缓存
对于有些业务场景，新增数据很少，大部分是统计数量操作，而且查问条件很多。这时候应用传统的 count(*)实时统计数据，性能必定不会好。
如果在页面中能够通过 id、name、状态、工夫、起源等，一个或多个条件，统计品牌数量。
这种状况下用户的组合条件比拟多，减少联结索引也没用，用户能够抉择其中一个或者多个查问条件，有时候联结索引也会生效，只能尽量满足用户应用频率最高的条件减少索引。
也就是有些组合条件能够走索引，有些组合条件没法走索引，这些没法走索引的场景，该如何优化呢？
答：应用 二级缓存。
二级缓存其实就是内存缓存。
咱们能够应用 caffine 或者 guava 实现二级缓存的性能。
目前 SpringBoot 曾经集成了 caffine，应用起来十分不便。
只需在须要减少二级缓存的查询方法中，应用 @Cacheable 注解即可。
@Cacheable(value = "brand", , keyGenerator = "cacheKeyGenerator")
public BrandModel getBrand(Condition condition) {return getBrandByCondition(condition);
}而后自定义 cacheKeyGenerator，用于指定缓存的 key。
public class CacheKeyGenerator implements KeyGenerator {
@Override
public Object generate(Object target, Method method, Object... params) {return target.getClass().getSimpleName() + UNDERLINE
+ method.getName() + ","
+ StringUtils.arrayToDelimitedString(params, ",");
}
}这个 key 是由各个条件组合而成。
这样通过某个条件组合查问出品牌的数据之后，会把后果缓存到内存中，设置过期工夫为 5 分钟。
前面用户在 5 分钟内，应用雷同的条件，从新查问数据时，能够间接从二级缓存中查出数据，间接返回了。
这样可能极大的提醒 count(*)的查问效率。
然而如果应用二级缓存，可能存在不同的服务器上，数据不一样的状况。咱们须要依据理论业务场景来抉择，没法实用于所有业务场景。
2.3 多线程执行
不晓得你有没有做过这样的需要：统计无效订单有多少，有效订单有多少。
这种状况个别须要写两条 sql，统计无效订单的 sql 如下：
select count(*) from order where status=1;统计有效订单的 sql 如下：
select count(*) from order where status=0;但如果在一个接口中，同步执行这两条 sql 效率会非常低。
这时候，能够改成成一条 sql：
select count(*),status from order
group by status;应用 group by 关键字分组统计雷同 status 的数量，只会产生两条记录，一条记录是无效订单数量，另外一条记录是有效订单数量。
但有个问题：status 字段只有 1 和 0 两个值，反复度很高，区分度非常低，不能走索引，会全表扫描，效率也不高。
还有其余的解决方案不？
答：应用多线程解决。
咱们能够应用 CompleteFuture 应用两个 线程 异步调用统计无效订单的 sql 和统计有效订单的 sql，最初汇总数据，这样可能晋升查问接口的性能。
2.4 缩小 join 的表
大部分的状况下，应用 count(*)是为了实时统计总数量的。
但如果表自身的数据量不多，但 join 的表太多，也可能会影响 count(*)的效率。
比方在查问商品信息时，须要依据商品名称、单位、品牌、分类等信息查问数据。
这时候写一条 sql 能够查出想要的数据，比方上面这样的：
select count(*)
from product p
inner join unit u on p.unit_id = u.id
inner join brand b on p.brand_id = b.id
inner join category c on p.category_id = c.id
where p.name='测试商品' and u.id=123 and b.id=124 and c.id=125;应用 product 表去 join 了 unit、brand 和 category 这三张表。
其实这些查问条件，在 product 表中都能查问出数据，没必要 join 额定的表。
咱们能够把 sql 改成这样：
select count(*)
from product
where name='测试商品' and unit_id=123 and brand_id=124 and category_id=125;在 count(*)时只查 product 单表即可，去掉多余的表 join，让查问效率能够晋升不少。
2.5 改成 ClickHouse
有些时候，join 的表切实太多，没法去掉多余的 join，该怎么办呢？
比方下面的例子中，查问商品信息时，须要依据商品名称、单位名称、品牌名称、分类名称等信息查问数据。
这时候依据 product 单表是没法查问出数据的，必须要去join：unit、brand 和 category 这三张表，这时候该如何优化呢？
答：能够将数据保留到ClickHouse。
ClickHouse 是基于 列存储 的数据库，不反对事务，查问性能十分高，号称查问十几亿的数据，可能秒级返回。
为了防止对业务代码的嵌入性，能够应用 Canal 监听 Mysql 的binlog日志。当 product 表有数据新增时，须要同时查问出单位、品牌和分类的数据，生成一个新的后果集，保留到 ClickHouse 当中。
查问数据时，从 ClickHouse 当中查问，这样应用 count(*)的查问效率可能晋升 N 倍。
须要特地揭示一下：应用 ClickHouse 时，新增数据不要太频繁，尽量批量插入数据。
其实如果查问条件十分多，应用 ClickHouse 也不是特地适合，这时候能够改成 ElasticSearch，不过它跟 Mysql 一样，存在 深分页 问题。
3 count 的各种用法性能比照
既然说到 count(*)，就不能不说一下 count 家族的其余成员，比方：count(1)、count(id)、count(一般索引列)、count(未加索引列)。
那么它们有什么区别呢？
- count(*)：它会获取所有行的数据，不做任何解决，行数加 1。
- count(1)：它会获取所有行的数据，每行固定值 1，也是行数加 1。
- count(id)：id 代表主键，它须要从所有行的数据中解析出 id 字段，其中 id 必定都不为 NULL，行数加 1。
- count(一般索引列)：它须要从所有行的数据中解析出一般索引列，而后判断是否为 NULL，如果不是 NULL，则行数 +1。
- count(未加索引列)：它会全表扫描获取所有数据，解析中未加索引列，而后判断是否为 NULL，如果不是 NULL，则行数 +1。
由此，最初 count 的性能从高到低是：
count(*) ≈ count(1) > count(id) > count(一般索引列) > count(未加索引列)
所以，其实 count(*) 是最快的。
意不意外，惊不惊喜？
千万别跟select * 搞混了
