序文
最近、社内のいくつかの遅いクエリ インターフェイスのパフォーマンスを最適化しました.いくつかの経験をまとめて共有しました.それがあなたの役に立てば幸いです.
使用するデータベースはMysql8
、使用するストレージ エンジンは ですInnodb
。この最適化に加えて优化索引
、それは最適化に関するものcount(*)
です。
通常の状況では、ページング インターフェイスは通常、データベースに対して 2 回クエリを実行します。1 回目は特定のデータを取得するため、2 回目はレコード行の総数を取得するためであり、結果を統合した後に結果を返します。
次のような特定のデータの sql をクエリします。
select id,name from user limit 20;
复制代码
パフォーマンスの問題はありません。
ただし、 count(*) を使用して行の総数を照会する別の sql です。たとえば、次のようになります。
select count(*) from user;
复制代码
しかし、パフォーマンスが悪いという問題があります。
なぜこれが起こるのですか?
1 count(*) なぜパフォーマンスが悪いのですか?
Mysql ではcount(*)
、関数はテーブルに記録された行の総数をカウントすることです。
ストレージ エンジンのcount(*)
パフォーマンスはストレージ エンジンに直接関係しており、すべてのストレージ エンジンのcount(*)
パフォーマンスが低いわけではありません。
Mysql で最も使用されているストレージ エンジンは、innodb
とmyisam
です。
myisam では総行数がディスクに保存されますが、count(*) を使用すると、追加の計算なしでそのデータを返すだけでよいため、実行効率が非常に高くなります。
InnoDB が異なるのは、トランザクションをサポートしているMVCC
(つまり、複数バージョンの同時実行制御の存在) ため、同じ時点の異なるトランザクションでは、同じクエリ SQL によって返される行数が不確実な場合があることです。
innodb が count(*) を使用する場合、ストレージ エンジンから 1 行ずつデータを読み込んで加算する必要があるため、実行効率が非常に低くなります。
テーブル内のデータ量が少なくても問題ありませんが、テーブル内のデータ量が大きくなると、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 *
搞混了。
最后说一句(求关注,别白嫖我)
如果这篇文章对您有所帮助,或者有所启发的话,帮忙扫描下发二维码关注一下,您的支持是我坚持写作最大的动力。
求一键三连:点赞、转发、在看。
关注公众号:【苏三说技术】,在公众号中回复:面试、代码神器、开发手册、时间管理有超赞的粉丝福利,另外回复:加群,可以跟很多BAT大厂的前辈交流和学习。