prefacio
Recientemente, he optimizado el rendimiento de varias interfaces de consulta lenta en la empresa. He resumido algunas experiencias y las he compartido con ustedes. Espero que les sea útil.
La base de datos que usamos es Mysql8, el motor de almacenamiento que usamos es Innodb. Además de esta optimización 优化索引, se trata más de optimización count(*).
En circunstancias normales, la interfaz de paginación generalmente consulta la base de datos dos veces, la primera vez es para obtener datos específicos, la segunda vez es para obtener el número total de filas de registros y luego devolver el resultado después de integrar los resultados.
Consulta el sql de datos específicos, como este:`
select id,name from user limit 20;
复制代码No tiene problemas de rendimiento.
Pero otro sql que usa count (*) para consultar el número total de filas, por ejemplo:
select count(*) from user;
复制代码Pero hay un problema de bajo rendimiento.
¿Por qué pasó esto?
1 recuento(*) ¿Por qué el rendimiento es bajo?
En Mysql, count(*)la función es contar el número total de filas registradas en la tabla.
El count(*)rendimiento de los motores de almacenamiento está directamente relacionado con los motores de almacenamiento, no todos los motores de almacenamiento count(*)tienen un rendimiento deficiente.
Los motores de almacenamiento más utilizados en Mysql son: innodby myisam.
En myisam, el número total de filas se guardará en el disco. Al usar count (*), solo necesita devolver esos datos sin cálculos adicionales, por lo que la eficiencia de ejecución es muy alta.
InnoDB es diferente, porque admite transacciones, existe MVCC(es decir, la existencia de control de concurrencia de múltiples versiones), en diferentes transacciones en el mismo punto de tiempo, la cantidad de filas devueltas por la misma consulta SQL puede ser incierta.
Cuando innodb usa count (*), necesita leer los datos fila por fila del motor de almacenamiento y luego sumarlos, por lo que la eficiencia de ejecución es muy baja.
Está bien si la cantidad de datos en la tabla es pequeña, pero una vez que la cantidad de datos en la tabla sea grande, el rendimiento será bajo cuando el motor de almacenamiento de innodb use estadísticas de conteo (*).
2 ¿Cómo optimizar el rendimiento del conteo (*)?
De lo anterior, dado count(*)que hay problemas de rendimiento, ¿cómo podemos optimizarlo?
Podemos partir de los siguientes aspectos.
2.1 Aumentar caché 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 * 搞混了。
最后说一句(求关注，别白嫖我)
如果这篇文章对您有所帮助，或者有所启发的话，帮忙扫描下发二维码关注一下，您的支持是我坚持写作最大的动力。
求一键三连：点赞、转发、在看。
关注公众号：【苏三说技术】，在公众号中回复：面试、代码神器、开发手册、时间管理有超赞的粉丝福利，另外回复：加群，可以跟很多BAT大厂的前辈交流和学习。