MySQL

迁移项目开工第一天，客户发来一个压缩包，说数据都在里面。导进去只用了一个下午，财务发现上个月的应收少了一万二千七百八十八，用了三个星期才问明白差在哪。迁移的验收，说了算的是客户财务签字确认的金额、总量和权限范围；Excel 的合并单元格、期初余额、旧单号、离职员工，每一件都能让这个签字拖到下周。

内网机器不给出网，最小化镜像里没有 CA 证书和中文字体，jar 里的 native 库只带 x86_64，镜像 tag 写成 latest 到了离线环境就是一个陌生的镜像名。“在我机器上跑通了”这句话在客户机房里不值钱，介质、环境检查、库结构、密钥、升级和回滚，每缺一样都能让安装卡在当场。

只比渠道账单和我方订单，抓不到手续费漏记和分账记错。对账要能回答“错在哪一层”：渠道流水、业务订单、账户分录各对一次。下载地址 30 秒就失效、微信账单只给三个月、账单里的退款行出账后状态不再更新，而对账系统自己的失效方式是任务返回成功。

余额字段一旦能被 update，账就只能靠人工对平。账户管谁是主体、流水管动了多少、凭证管为什么动，三张表各管一件事。分账规则要带生效区间，退款要按原分录反向冲销，可用和冻结别做成一行两列。代收再结算算不算二次清算，这条线绕不开。

订单状态那一列管得住“现在是什么”，管不住“谁把它改成的”“当时能不能改”“同一件事收到两次会怎样”。把 updateStatus(id, 3) 换成事件加守卫，改动量就是那十几处调用各自想清楚自己发的是哪个事件。

需求说“要加门店”，开发在 sys_dept 上加了一列 type，两行代码当天上线。三个月后加代理商，type 多个值；半年后要求门店同时归区域运营、归总部核算，parent_id 只有一个。行政组织、经营单元、外部主体这三层的差别不在层级深浅，在于谁需要历史、谁会算钱、谁是外部人。

一句“销售只能看自己的客户”，里面藏着行、列、入口、失效四个判定，RBAC 一个都答不了。这篇讲数据范围怎么落成一条 SQL、@DataScope 这类拼法会在哪一层漏、成本价为什么会整整齐齐出现在导出的 Excel 里，以及为什么详情接口是行级权限最大的口子。

多租户不是加个 tenant_id 就完了。共享表、独立 schema、独立库，三种模型的成本和失效方式不一样。这篇按 Spring Boot + MySQL 讲我怎么选、怎么落地，以及异步、定时任务、MQ、导出这些地方怎么漏。