双写开关必须控制在DAO层，旧库写入成功为前提，新库失败不阻断主流程；需异步提交、失败入retry_queue重试；开关由数据库或Nacos驱动；停同步与开双写必有空窗，须通过T0时间戳补偿覆盖；国产库双写需处理自增主键与大小写兼容；切读前须验证索引与执行计划。
双写开关必须控制在 DAO 层，不能放在业务逻辑里
双写不是“多写一次”，而是要确保旧库写入成功是前提，新库写入失败不阻断主流程。如果把双写逻辑塞进 Service 方法里，容易导致事务边界混乱、异常处理不可控、回滚策略失效。
正确做法是把双写封装成数据访问层的增强行为，比如 MyBatis 的 Interceptor 或 Spring 的 DataSource 路由代理。关键点：
- 旧库写操作走本地事务，必须成功；新库写操作异步提交或走独立事务，失败后记录到
retry_queue表，由定时任务重试 - 开关配置用数据库表或配置中心（如 Nacos）驱动，避免重启应用——
dual_write_enabled、write_target（old/new/both）两个字段足够 - 禁止在 Service 层手动调用两次
insert()：这会导致事务传播异常，比如@Transactional方法内嵌套调用新库 DAO，可能意外开启新事务，破坏一致性
增量同步停启与双写开启之间必有数据空窗，必须靠校验+补偿兜底
你停掉 Canal/Maxwell 同步程序、再开启双写，这两步无法原子执行。哪怕在低峰期，中间几十毫秒也可能产生未同步的 Binlog 事件，造成新库漏数据。
这不是理论风险，是每次切换都真实发生的。应对方式不是追求“无缝”，而是接受空窗、主动覆盖：
- 双写开启前，先查旧库最后一条变更时间戳（比如
updated_at），记为T0 - 双写开启后，立即启动一次“空窗期补偿”任务：扫描旧库中
updated_at > T0的记录，逐条比对新库是否存在且字段一致 - 不一致时，以旧库为准覆盖新库——注意用
REPLACE INTO或INSERT ... ON DUPLICATE KEY UPDATE，避免主键冲突报错 - 该任务需幂等，可加
compensation_task_log表记录执行状态，防止重复执行
MySQL 切国产库双写时，自增主键和大小写敏感是高频崩点
双写本身不解决语法兼容问题。当目标库是金仓、达梦、TiDB 等，AUTO_INCREMENT 和标识符大小写规则差异会直接导致写入失败，且错误常被吞掉或误判为网络超时。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
必须提前做两件事：
- 建表语句改写：把
AUTO_INCREMENT替换为目标库等效写法，例如金仓用SERIAL，达梦用IDENTITY；所有表名、字段名统一小写并用反引号包裹，绕过大小写敏感问题——`user_order`而非UserOrder - 双写 DAO 层加兜底转换：读取
LAST_INSERT_ID()前，先判断当前write_target，若为新库则改用对应函数，如 TiDB 的SELECT LAST_INSERT_ID()仍可用，但达梦需用SELECT SEQ_NAME.CURRVAL FROM DUAL - 测试阶段必须跑通“连续插入 + 主键回填 + 关联查询”全链路，不能只测单条 insert
切读流量前，务必验证新库的索引命中率和执行计划
双写保证了数据存在，不代表能高效读。国产库优化器对 GROUP BY、ORDER BY、JOIN 的处理逻辑不同，同一 SQL 在 MySQL 走索引，在新库可能全表扫。
灰度切读前要做的不是“功能对得上”，而是“性能扛得住”：
- 用
EXPLAIN对比核心查询语句在新旧库的执行计划，重点关注type（是否range或ref）、key（是否命中预期索引）、rows（扫描行数是否激增） - 新库补索引不能照搬旧库：比如 MySQL 的联合索引
(a,b,c)可用于WHERE a=1 AND b=2，但某些国产库要求最左前缀严格匹配，WHERE b=2就无法使用，得单独建(b)索引 - 开启慢日志采集，灰度期间重点监控新库
Query_time > 1s的 SQL，优先优化而非扩容
双写只是迁移的起点，真正的平滑在于每一步都留退路、每一步都验证副作用。最容易被跳过的，是切读前对执行计划的逐条核对，以及切写后对新库锁等待和死锁日志的持续盯盘。
