mysql表格增加字段时数据丢失_MySQL表添加了一个字段，竟然导致数据无法写入，反思...

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

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

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

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

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

表结构信息如下&＃xff1a;

CREATE TABLE &＃96;data_stat&＃96; (

&＃96;id&＃96; int(11) NOT NULL AUTO_INCREMENT,

&＃96;day&＃96; int(8) NOT NULL DEFAULT &＃39;0&＃39;,

&＃96;kind&＃96; varchar(10) NOT NULL DEFAULT &＃39;&＃39;,

&＃96;netid&＃96; varchar(3) NOT NULL DEFAULT &＃39;&＃39;,

&＃96;item&＃96; varchar(10) NOT NULL DEFAULT &＃39;&＃39; &＃xff0c;

&＃96;value&＃96; varchar(20) NOT NULL DEFAULT &＃39;&＃39;,

&＃96;room&＃96; varchar(10) NOT NULL DEFAULT &＃39;null&＃39; ,

PRIMARY KEY (&＃96;id&＃96;),

KEY &＃96;idx_day_netid&＃96; (&＃96;day&＃96;,&＃96;kind&＃96;,&＃96;netid&＃96;,&＃96;item&＃96;)

) ENGINE&＃61;InnoDB AUTO_INCREMENT&＃61;55158 DEFAULT CHARSET&＃61;utf8 ;

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

举个小例子&＃xff0c;数据可以这样描述&＃xff1a;

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

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

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

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

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

可以使用如下的两条数据描述来说明&＃xff1a;

第1条记录&＃xff1a;

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

第2条记录&＃xff1a;

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

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

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

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

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

这个问题带给我的总结就是&＃xff1a;

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