首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
30 篇文章
1
迁移到MySQL的业务架构演进实战
2
如何优化MySQL千万级大表,我写了6000字的解读
3
MySQL中的SQL优化建议那么多,该如何有的放矢
4
说几点关于数据库的见解
5
迁移至MySQL的数据流转流程优化
6
引入TiDB方案的一些思考
7
MySQL数据克隆的用户权限设计
8
MySQL逻辑数据恢复体系的设计
9
MySQL随机恢复的设计思路
10
从Oracle到MySQL,金融核心场景在线换库落地实战
11
基于Maxwell的MySQL数据传输服务整体设计
12
MySQL数据库升级的一些坑
13
数据架构选型必读:4月数据库产品技术解析
14
基于数据库中间件配置的几类问题
15
关于中间件服务的配置管理,分为5个阶段
16
MySQL中10多张表关联要做优化,怎么理解逻辑幂等
17
关于MySQL拓扑关系的梳理
18
对于新技术栈落地和架构思维的建议
19
MyCAT让人诟病的配置文件,说说破局的思路
20
MySQL多活数据消费服务设计方案
21
数据双向复制中的6个数据冲突场景和解决思路
22
MySQL双主模式下是如何避免数据回环冲突的
23
一个MySQL服务CPU 100%的优化案例反思
24
MySQL表添加了一个字段,竟然导致数据无法写入,反思
25
MySQL周期表管理太繁琐,通过Python自定义工具方法优雅解决
26
MySQL业务双活的初步设计方案
27
数据库修改密码风险高,如何保证业务持续,这几种密码双活方案可以参考
28
一道经典的MySQL面试题,答案出现三次反转
29
​业务双活的数据切换思路设计(下)
30
基于Consul的MySQL高可用服务,健康检查怎么做?这里有一个完整脚本

MySQL表添加了一个字段,竟然导致数据无法写入,反思

这是学习笔记的第 2152 篇文章

今天有一个同事通过即时通讯工具找我,说需要做一个数据变更操作,我一看需求很简单,是新增了一个列,需要创建相关的索引。

对于SQL自动化上线,目前算是到了收获的时段,从近期的工单情况来看,很多业务需求都从平台化的工单操作转向了自动化单据,按照最新的数据统计结果,假设有150个工单,那么100个左右都是自动化流程完成的,占比近70%。

这个工单的操作是目前自动化不支持的,因为需求是删除已有的索引,然后添加新的索引字段。

当我看到问题的时候,我感觉到一种异常,但是又实在说不清楚,所以准备当面沟通下。

表结构信息如下:

CREATE TABLE `data_stat` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`day` int(8) NOT NULL DEFAULT '0',

`kind` varchar(10) NOT NULL DEFAULT '',

`netid` varchar(3) NOT NULL DEFAULT '',

`item` varchar(10) NOT NULL DEFAULT '' ,

`value` varchar(20) NOT NULL DEFAULT '',

`room` varchar(10) NOT NULL DEFAULT 'null' ,

PRIMARY KEY (`id`),

KEY `idx_day_netid` (`day`,`kind`,`netid`,`item`)

) ENGINE=InnoDB AUTO_INCREMENT=55158 DEFAULT CHARSET=utf8 ;

大体的业务含义是对每一天的登录数据进行统计,原本是3个维度(kind,netid,item),现在多了一个维度(room)。

举个小例子,数据可以这样描述:

在2019-01-01(day)这一天用户通过手机(kind)登录了网站,使用的是5G手机(netid),连接的就近站点(room)是北京,在线时长(item)为5分钟(value)。

此时我需要了解的是业务的查询模型,即通常都有哪些场景的查询,而一旦这个room新字段在复合索引中,而如果条件不满足,则这个索引列不会被用到,其实效果更糟。

而通过沟通,我惊奇的发现业务对于这个表的使用是有问题的。他说如果不添加索引字段room,业务就写入不了数据了。

这个大大超出了我的预期,大家可以仔细看下这条SQL,按照我刚刚描述的场景,是否能够理解。

经过沟通,理解了这个业务场景,总算是明白了为什么业务写入不了数据。

可以使用如下的两条数据描述来说明:

第1条记录:

2019-01-01(day)用户通过手机(kind)登录了网站,使用的是5G手机(netid),连接的就近站点(room)是北京,在线时长(item)为5分钟(value)

第2条记录:

2019-01-01(day)用户通过手机(kind)登录了网站,使用的是5G手机(netid),连接的就近站点(room)是北京,在线时长(item)为15分钟(value)

在这种情况下,因为字段(day,kind,netid,item)是唯一性索引,那么第2条记录对应的数据是无法写入的。

所以按照这种设计,如果后续还有新的字段,那索引就需要横向扩展了,所以对于这个问题,我提出了改进建议。

索引确实需要重建,根据业务反馈的查询场景,其实添加非唯一性索引(`day`,`netid`,`room`)已经足够覆盖目前的查询,而更有意义的是:数据写入不会因为索引设计不合理/新增业务字段而导致数据无法写入。

所以在明确了需求之后,帮业务同学重建了索引,这个问题的处理就告一段落。

这个问题带给我的总结就是:

  1. 对于潜在的问题,第一要旨就是参考标准,如果违反了标准,我们可以很快发现潜在问题,而不是屈从于被动响应业务。
  2. 对于沟通,我们尽可能避免一些聊天式沟通,越是不够明确清晰,我们的沟通成本反而更高,所以对于一些模糊问题,几句话解释不清楚的,我都喜欢当面沟通。
  3. 理解业务需求的深层次含义。这个业务开始的反馈是很紧急,通过熟悉业务后的改进来看,其实和开始的描述是有偏差的,业务紧急的深层次含义其实是业务因为新增字段导致写入不了数据了,所以迫切需要重建索引。而我们理解这个问题的出发点是基于数据统计查询。而帮助业务解决了这个问题之后,对他们来说,收益更大,所以在沟通中也就淡化了这种紧急度。
  4. 需要换位思考,从熟悉业务的角度来进行优化调整。在这个过程中,我是本着帮他的态度去理解这个问题的,在沟通中不断的调整自己的问题分析方向,最终发现这个问题,解决这个问题的过程其实是无法预料到这么多潜在的问题的,而逐步理解了业务,也就掌握了主动性。
  5. 索引优化的知识补充,通过这个问题,无论是历史遗留还是新人犯的错误,其实都从侧面反映出我们需要提供一些可供参考的技术建议,这是一个持续改进的过程。
下一篇
举报
领券