为什么要使用 99+,记一次 sql 优化(消息数量显示优化)

2024-05-27 07:32

本文主要是介绍为什么要使用 99+,记一次 sql 优化(消息数量显示优化),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

http://www.tuicool.com/articles/6fIbEvQ

一般在设计通知中心时,都会在入口处显示一个未读消息数,这样不仅可以醒目地告知用户有未读消息,还能让用户更容易从众多小图标中区分出通知中心的入口。比如 ucloud 控制台的顶栏:

我们网站的通知中心也一样,在入口同样加上了未读消息数的显示。

上线后平稳运行,以为可以就这样一直美下去。程序只要有人用,总会有出 bug 的那一天,最近高峰期经常会出现来自通知表的慢查询语句,仔细一查,原来就是统计未读消息数的语句,而且都是来自几个大用户。我们通知里分了多个组,每个组都有自己的一个未读数,sql 语句差不多是下面这样:

SELECT groupID, count(0) unreadCount FROM notification WHERE userID=xxx AND hasRead=0 GROUP BY groupID;

notification 表中已建立未读索引 unreads: userID + hasRead + groupID 的组合键。

由于我们网站大多是批量异步操作,即使做了消息合并,一天产生几十上百条通知也很正常,而且有的用户就是不喜欢标记通知为已读,这样日积月累,有的用户未读数已经上十万了。假设总记录行有 20 万,如果未读数为 50,建立一个未读的索引,效率会非常显著;但是未读数为 15 万,这时索引的意义也不大了。所以这个性能问题直到现在才暴露出来。

当未读数比较小时:结果集:

groupID | unreadCount  
0 | 23  
4 | 16

Explain:

id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra  
1 | SIMPLE | notification | ref | unreads | unreads | 5 | const,const | 39 | Using where; Using index

耗时:0.4ms(测试数据)

当未读数比较大时:结果集:

groupID | unreadCount  
0 | 23  
1 | 103234  
3 | 3032  
4 | 16

Explain:

id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra  
1 | SIMPLE | notification | ref | unreads | unreads | 4 | const | 69886 | Using where; Using index

耗时:38.9ms(测试数据)

由上可以看出,未读的记录行数直接影响该语句的性能。

问题出现总归要解决的,如何解决呢?最直接的办法就是看看其他产品是怎么做的。LG 同学提出,可以优化成像 QQ 未读消息数那样显示 99+ 呀。QQ 上有几个群,每天都有人在里面吹水斗表情,消息一会不看就 99+ 了。当初以为这样只是为了排版美观,或者避免特别大的数字给用户造成很大的心理负担,再者也不会有人关心未读的消息是 101 还是 102,所以索性显示 99+。即告诉用户有很多未读消息,又不会因显示一个特别大的数字吓到用户,这样一举两得。但这样似乎只是对用户更友好,对性能然并卵。这时他再次提出可以把 sql 语句拆开来写,一开始我是拒绝的,按照过往经验,多条语句查出结果合并肯定没有单条语句 GROUP BY 来的快。有时经验也会害死人,于是 LG 给出了下面的语句:

SELECT 0 AS groupID, count(1) AS unreadCount FROM (SELECT 1 FROM notification WHERE userID=xxx AND hasRead='0' AND groupID = 0 LIMIT 100) AS a  
UNION  
SELECT 1 AS groupID, count(1) AS unreadCount FROM (SELECT 1 FROM notification WHERE userID=xxx AND hasRead='0' AND groupID = 1 LIMIT 100) AS a  
UNION  
SELECT 2 AS groupID, count(1) AS unreadCount FROM (SELECT 1 FROM notification WHERE userID=xxx AND hasRead='0' AND groupID = 2 LIMIT 100) AS a  
UNION  
SELECT 3 AS groupID, count(1) AS unreadCount FROM (SELECT 1 FROM notification WHERE userID=xxx AND hasRead='0' AND groupID = 3 LIMIT 100) AS a  
UNION  
SELECT 4 AS groupID, count(1) AS unreadCount FROM (SELECT 1 FROM notification WHERE userID=xxx AND hasRead='0' AND groupID = 4 LIMIT 100) AS a

这条语句精妙就精妙在 LIMIT 100 ,使用未读索引并把结果集限定在 100 行以内,这个速度是非常快的。

优化后的时间:结果集:

groupID | unreadCount  
0 | 23  
1 | 100  
2 | 0  
3 | 100  
4 | 16

Explain:

id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra  
1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 23 | NULL  
2 | DERIVED | notification | ref | unreads | unreads | 6 | const,const,const | 23 | Using index  
3 | UNION | <derived4> | ALL | NULL | NULL | NULL | NULL | 100 | NULL  
4 | DERIVED | notification | ref | unreads | unreads | 6 | const,const,const | 73020 | Using index  
5 | UNION | <derived6> | ALL | NULL | NULL | NULL | NULL | 2 | NULL  
6 | DERIVED | notification | ref | unreads | unreads | 6 | const,const,const | 1 | Using index  
7 | UNION | <derived8> | ALL | NULL | NULL | NULL | NULL | 100 | NULL  
8 | DERIVED | notification | ref | unreads | unreads | 6 | const,const,const | 3208 | Using index  
9 | UNION | <derived10> | ALL | NULL | NULL | NULL | NULL | 16 | NULL  
10 | DERIVED | notification | ref | unreads | unreads | 6 | const,const,const | 16 | Using index  
NULL | UNION RESULT | <union1,3,5,7,9> | ALL | NULL | NULL | NULL | NULL | NULL | Using temporary

耗时:0.7ms(测试数据)

性能提升了几十倍,堵在胸口的这坨翔终于通了。这条语句的性能会因分组的数量所影响,但分组的数量是有限而且比较固定的,所以这个威胁不成立。

其实到这还没结束,还要结合前台,当 unreadCount 大于 99 时,就要显示 99+,优化后我们的通知中心未读提醒成了这样:

总结

优化不能单靠技术手段,有时产品上做下折中,优化的方法会简单很多。如果这次仅凭技术手段来优化,可能要引入缓存,或者冗余一个未读数,每次更新维护这个数字,这可能需要 2 ~ 3 天的工作量,而且还容易出 bug;而使用 99+ 的做法只花了不到 2 小时。另外也不能一直相信经验,经验有时也会犯错,而且会固化思维。


这篇关于为什么要使用 99+,记一次 sql 优化(消息数量显示优化)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1006836

相关文章

Vue3 的 shallowRef 和 shallowReactive:优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉,那么对 shallowRef 和 shallowReactive 是否了解呢? 在编程和数据结构中,“shallow”(浅层)通常指对数据结构的最外层进行操作,而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素,而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层(Shallow) 定义

SQL中的外键约束

外键约束用于表示两张表中的指标连接关系。外键约束的作用主要有以下三点: 1.确保子表中的某个字段(外键)只能引用父表中的有效记录2.主表中的列被删除时,子表中的关联列也会被删除3.主表中的列更新时,子表中的关联元素也会被更新 子表中的元素指向主表 以下是一个外键约束的实例展示

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

如何去写一手好SQL

MySQL性能 最大数据量 抛开数据量和并发数,谈性能都是耍流氓。MySQL没有限制单表最大记录数,它取决于操作系统对文件大小的限制。 《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB,才推荐分库分表。性能由综合因素决定,抛开业务复杂度,影响程度依次是硬件配置、MySQL配置、数据表设计、索引优化。500万这个值仅供参考,并非铁律。 博主曾经操作过超过4亿行数据

中文分词jieba库的使用与实景应用(一)

知识星球:https://articles.zsxq.com/id_fxvgc803qmr2.html 目录 一.定义: 精确模式(默认模式): 全模式: 搜索引擎模式: paddle 模式(基于深度学习的分词模式): 二 自定义词典 三.文本解析   调整词出现的频率 四. 关键词提取 A. 基于TF-IDF算法的关键词提取 B. 基于TextRank算法的关键词提取

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

HDFS—存储优化(纠删码)

纠删码原理 HDFS 默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。 此种方式节约了空间,但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。 默认只开启对 RS-6-3-1024k

Hadoop数据压缩使用介绍

一、压缩原则 (1)运算密集型的Job,少用压缩 (2)IO密集型的Job,多用压缩 二、压缩算法比较 三、压缩位置选择 四、压缩参数配置 1)为了支持多种压缩/解压缩算法,Hadoop引入了编码/解码器 2)要在Hadoop中启用压缩,可以配置如下参数

Makefile简明使用教程

文章目录 规则makefile文件的基本语法:加在命令前的特殊符号:.PHONY伪目标: Makefilev1 直观写法v2 加上中间过程v3 伪目标v4 变量 make 选项-f-n-C Make 是一种流行的构建工具,常用于将源代码转换成可执行文件或者其他形式的输出文件(如库文件、文档等)。Make 可以自动化地执行编译、链接等一系列操作。 规则 makefile文件

第10章 中断和动态时钟显示

第10章 中断和动态时钟显示 从本章开始,按照书籍的划分,第10章开始就进入保护模式(Protected Mode)部分了,感觉从这里开始难度突然就增加了。 书中介绍了为什么有中断(Interrupt)的设计,中断的几种方式:外部硬件中断、内部中断和软中断。通过中断做了一个会走的时钟和屏幕上输入字符的程序。 我自己理解中断的一些作用: 为了更好的利用处理器的性能。协同快速和慢速设备一起工作