MySQL事务控制无障碍设计实战指南
|
“MySQL事务控制无障碍设计实战指南”——这书名去年夏天我第一次在阿里云DBA内网论坛看到时，差点以为是新出的无障碍网页标准文档。结果点开PDF第3页，就撞见InnoDB死锁图谱用高对比色块重绘的案例：深红表示等待，墨绿表示持有，灰线标出隔离级别变更节点——连色盲模式都配了十六进制RGB值标注（#CC0000 / #006600），我当时直接截图发给了组里三位有红绿色弱的同事。 去年夏天我们上线新风控系统，订单补偿事务链跑着跑着在T+2凌晨崩了三次，查日志发现不是锁超时，是READ COMMITTED下间隙锁被意外释放——但监控平台根本没告警，因为它的SQL解析器把FOR UPDATE语句里带WITH RECURSIVE的子查询误判成只读。后来翻《MySQL事务控制无障碍设计实战指南》附录B，才看到作者用137行Python脚本模拟了5种隔离级别下28个边缘case的执行路径，其中第17个case正好复现了我们的问题：当UPDATE语句嵌套UNION ALL且第二分支含SELECT ... FOR UPDATE时，8.0.28会漏加gap锁。我们连夜打了补丁，把该SQL拆成两步执行，错误率从12.7%降到0.03%——但说实话，补丁本身比原逻辑多占11%内存带宽。 新技术。 不过别信它说“兼容所有MySQL 5.7+版本”。我们在CentOS 7.9 + MySQL 5.7.39上跑了三天压测，事务回滚段（rollback segment）的自动扩缩容策略会和这本书推荐的innodb_rollback_segments=128参数冲突——因为5.7.39实际最大只支持127，第128个segment初始化时静默失败，但错误日志只埋在mysqld_safe的stderr重定向文件里，连show variables like '%rollback%'都查不到异常。这个坑是我自己抠源码才发现的：ha_innodb.cc第4912行有个if (n > UNIV_MAX_ROLL_SEGMENTS-1) continue; ——它根本没报错，就跳过了。现在我手写了一个check_rollback_segments.sh，每次启库后自动grep error.log匹配"rollback segment init fail"，再curl推钉钉。你猜怎么着？上线后第七天凌晨三点，它真抓到一次——当时innodb_fast_shutdown=2，导致rollback segment重建阶段卡在mutex竞争，连续19秒没响应。 这书里第6章讲XA事务的无障碍化改造，但漏了一条：如果用Seata做AT模式协调器，在MySQL 8.0.33里开启binlog_checksum=CRC32后，xa_prepare()返回的XID字符串末尾会多一个不可见的U+001F字符（单元分隔符），而Seata客户端Java代码里的String.trim()完全砍不掉它——于是二阶段commit时MySQL直接报“XID not found”。我们花了11小时抓包比对，最后在Percona官网一个已关闭的issue #9427里找到线索：这是8.0.33新引入的binlog事件header修正机制导致的副作用。作者没写这事，可能根本没见过混合部署Seata+8.0.33的生产环境。 我的主观判断：它对事务可见性描述比官方手册还准，但把too many connections这种连接池级故障硬塞进“事务控制”范畴，属于用力过猛。
文章配图，仅供参考 上周五测试环境又挂了，这次是SAVEPOINT命名含emoji（用了 ???? 作分隔符），MySQL解析器报错码HY000，错误信息里却显示为乱码十六进制（0xF0 0x9F 0xA7 0xA9），而《MySQL事务控制无障碍设计实战指南》里第112页写的“命名仅支持ASCII字母数字”显然不够——它没提UTF8MB4四字节字符在内部STATEMENT对象里如何截断。我现在正用gdb attach mysqld进程，想看看Sql_cmd_savepoint::execute()里到底在哪一步把emoji吞掉了……要不你也试试？（编辑：航空爱好网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
