背景介绍

2020年6月，商品系统从SAP、中间层等接入的商品数据越来越多且更新频繁，商品数据库主从更新数据量大，约每分钟54万多条更新，约八分钟就会产生大于1G的Binlog文件，在数据库IO能力一定的情况下，发生数据同步延迟，影响写入与读出的及时性，进而影响到商品基础系统的可用性。

如果仅是从翻阅代码的角度去分析，会花费大量人力。抛开系统本身，当商品多个应用都在读写商品库，并在数据库层起到数据汇总和集中反馈的情况下，分析这个点是一个较好的方向。

分析模型

把Binlog解析成Sql 纯文本，解析出来的Sql文本样例如下：

观察解析出来的文本，判断是否是有效更新，关键在于找到实际更新的是哪些字段。即: WHERE块中和SET块中哪些字段上有值的更新。

通过对比发现：

实际只更新了第 7 和 8 号的时间字段，如果没有刷新其他值，只是刷新了时间，估计这条更新语句没什么意义；又，商品系统接收到下发数据时，估计是我们拿到了数据后，直接用 modified=now()产生了update语句，这样时间有变化，必然产生Binlog。

基于以上逻辑，只要能分析出一条update语句中，哪些字段更新了，这些更新字段本身对业务是否有意义，来判断是否应该产生Binlog。希望分析出的结果模型如下：

通过分析表X中，字段组合 以及相应的 更新次数，可以得出：

1. 更新的 字段组合 判断出是否是有效更新；

2. 相应的 更新次数 反映出有效和无效更新的条数、占比程度等；

组合统计

由于Binlog对应的文本量大，通过脚本把每条 Insert 、Delete、Update语句切到单独的文件中。然后计算每个文件中的Sql 里的字段差异并做归集。流程如下:

统计每张表的每个字段单独更新是否有效：1表示单独更新有效，0表示单独更新无效，如以下统计样例表:

根据以上统计表，计算每种更新语句的“更新是否有效表达式”，计算方法为：

每种更新语句的更新字段组合的单独更新是否有效的数值做加法。

如果更新字段组合中，所有字段的单独更新是否有效的值为0，则加起来的和等于0；

只要更新字段组合中，某一字段的单独更新是否有效的值为1，则加起来的和大于0；

根据 “更新是否有效表达式”的和是否大于0 得出对应的更新语句是否是有效的更新。

以商品库表以及字段为例，判断更新语句是否有效，统计表参考如下：

根据以上统计表，无效更新的占比为：sum(无效更新=0的更新量)/sum(更新量)。结果模型举例如下图：

这样为分析提供：定性与定量的基础，并且知道后续优化的预期效果。商品系统经过优化，减少了90%以上的无效更新，并且减少了下游系统订阅商品Binlog的数据更新压力。

代码排查

初步分析是我们拿到数据后，在SqlMapper文件中: 时间字段=now()，触发了实际更新产生binlog，根据实际情况修改排查，确认是否对下游系统有影响，如大数据抽数等情况做优化。

商品系统初步的修改方法为：

1.建表时，建议按照以下格式设计：

create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP;

update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

这样做的好处是:Insert时，created字段不需要设置；update时，modified字段不需要设置，让业务代码更纯粹，同时也不用担心数仓拉数据的时候没更新时间；

2. 语句中，update * set * where * ，如果set 块中没有更新数据，set 和 where 直接连在一起，Sql语法会错误，在set 里面加上where 块中的条件字段，如id=#id#, 这样让 Sql 语句语法正确。另外也遵循如果没有实际的数据更新，不会产生binlog的规律；

其他引申

用以上的结果模型，清晰地展示出一个库的更新情况，不仅能判断出Sql语句是否是有效更新，也能反馈以下些情况：

1. 数据库设计是否合理，比如在分析我们公司的XX系统的数据库后，结论是：更新都是有效更新，但更新量最大的一张表有98个字段，且更新量最大的部分，只更新了表的 yn字段，由Binlog解析出来的纯文本可知，即使只更新yn字段，也会在SET和WHERE块中带上这98个字段，合计约200多行的更新语句，也触发了大量Binlog文件产生；后面计划通过拆分表字段，通过归类数据字段、状态字段等方式来解决。

2. 给缓存数据提供定量依据，比如频繁更新字段，是否能用缓存的启发等；

3. 给系统负责同学提供数据库更新字段维度的透视，知道数据库实际更新了哪些字段，有无必要，还可以做哪些优化启发等；

以上通用的分析方法，特别适合于数据库更新量大的系统，以及通用的脚本分析工具快速出分析结果。

每分钟54万多条数据更新，商品系统性能如何优化？相关推荐

1.3 万亿条数据查询，知乎如何做到毫秒级响应？
(给视学算法加星标,提升数据技能) 作者:孙晓光 http://itindex.net/ 知乎搜索后端负责人,目前承担知乎搜索后端架构设计以及工程团队的管理工作.曾多年从事私有云相关产品开发工作,关注 ...
好文深思：1.3 万亿条数据查询，如何做到毫秒级响应？
点击上方好好学java ,选择星标公众号重磅资讯.干货,第一时间送达今日推荐:硬刚一周,3W字总结,一年的经验告诉你如何准备校招! 个人原创100W+访问量博客:点击前往,查看更多知乎,在 ...
美团医美发起“至美行动”，单月拦截六万余条虚假医美评价
千亿医美市场仍在高速发展,"行业规范"与"消费权益"成新的关键词.近期,美团医美发起"至美行动"治理专项,基于医美消费全链路的用户痛点,从平 ...
万亿条数据查询如何做到毫秒级响应？
点击上方"朱小厮的博客",选择"设为星标" 回复"666"获取公众号专属资料知乎,在古典中文中意为"你知道吗?",它是 ...
第四十四期:1.3万亿条数据查询如何做到毫秒级响应？
知乎,在古典中文中意为"你知道吗?",它是中国的 Quora,一个问答网站,其中各种问题由用户社区创建,回答,编辑和组织. 图片来自 Pexels 作为中国最大的知识共享平台,我们 ...
1.3 万亿条数据查询，如何做到毫秒级响应？
点击上方 "程序员小乐"关注, 星标或置顶一起成长后台回复"大礼包"有惊喜礼包! 每日英文 Each night I put my head to my pi ...
【k哥爬虫普法】非法入侵计算机信息系统，获取1500万余条个人信息！
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rZDkxIyG-1668593948055)(https://s2.loli.net/2022/11/07/Lx2ZiW ...
知乎1.3万亿条数据查询毫秒级响应，如何做到的？
点击"开发者技术前线",选择"星标????" 在看|星标|留言, 真爱来自:孙晓光 | 责编:乐乐链接:dzone.com/articles/lesson ...
Python | 一万多条拼车数据，看春运的迁徙图
作者 | 白苏,医疗健康领域产品经理一枚,Python&R爱好者来源 | InThirty 编辑 | Jane 今天是腊月二十八,你们都到家了吗?这篇文章,作者对北京.上海.广州.深圳.杭州 ...
mysql 万亿数据_sql-server – 哪个数据库可以处理数十亿/数万亿条记录的存储？...
我们正在研究开发一种捕获和分析netflow数据的工具,我们收集了大量的数据.每天我们捕获大约14亿个流记录,这些记录在json格式中看起来像这样: { "tcp_flags": ...

每分钟54万多条数据更新，商品系统性能如何优化？