当我们在不同数据库之间迁移时,总有一些认知幻像,下意识的以为,某些事应该还是那样。
但是事实上,有些事情永远的改变了,我们需要认识到这些变化,并且刷新认知。
最近有朋友在“云和恩墨大讲堂”的微信群提出了一个这样的问题,以下SQL的输出结果是什么?
create table enmotest (a int, b int );
insert into enmotest values(1,1);
update enmotest set a=a+1,b=b+a;
select * from enmotest;
要想回答这个问题,首先要跳出自我熟悉的认知,例如,Oracle 和 MySQL DBA看到的答案可能完全不同。而两者又很可能不熟悉另外一种数据库的工作原理,甚至缺少触手可得的验证环境。
现在借助墨天轮的 SQLRUN 工具,一切都非常简单,尝鲜地址:
https://modb.pro/sqlrun
我们验证一下不同数据库的表现。
1. Oracle 数据库,对于 Oracle 开发者很熟悉,结果可想而知是 (2,2)
2. MogDB 数据库,和O表达相同,结果是 (2,2)
3. MySQL 数据库,这会让Oracle开发者惊讶,结果是(2,3)
4. OceanBase 数据库,表达和 MySQL 一致,结果是(2,3)
在国产数据库的替代过程中,开发者也一定要深入了解不同数据库的细微差异,以避免因为简单的疏忽而产生严重的生产事故。
2023 数据技术嘉年华大会,将会在4.7 ~ 4.8 北京开幕,大会特设数据迁移专场,欢迎接受我的赠票邀请(扫码),共享数据库技术盛会,免费报名链接:
https://modb.pro/event/804/395289
对于上面的用例,通过 MySQL 的 Binlog 日志,还可以进一步审视后台的工作逻辑。
#230331 11:20:52 server id 1 end_log_pos 975 CRC32 0x67f56d5b Update_rows: table id 95 flags: STMT_END_F
### UPDATE `enmotech`.`enmotest`
### WHERE
### @1=1
### @2=1
### SET
### @1=2
### @2=3
# at 975
#230331 11:20:52 server id 1 end_log_pos 1006 CRC32 0x72b8ef24 Xid = 31
这就是 MySQL 的工作原理,在手册上有这样一段说明:
> Single-table UPDATE assignments are generally evaluated from left to right. For multiple-table updates, there is no guarantee that assignments are carried out in any particular order.
> If you set a column to the value it currently has, MySQL notices this and does not update it.
MySQL 单表更新赋值,通常是从左到右计算,这样先完成的计算结果就会影响后面的计算。对于多表更新,不保证按任何特定的顺序执行分配。
如果 update 赋值前后的结果不变, MySQL 不会执行update, 所以不能通过SQL影响行数来判断业务逻辑的执行情况。
这些行为都和Oracle完全不同。
云和恩墨大讲堂 | 一个分享交流的地方
长按,识别二维码,加入万人交流社群
请备注:云和恩墨大讲堂
点个“在看”
你的喜欢会被看到❤