黑盒测试本质是验证业务sql在新环境能否正确执行、结果一致且性能达标，而非仅检查数据是否丢失；需从线上日志提取真实sql，覆盖join/group by/事务/函数等场景，结合explain与结果集比对，并校验权限、连接参数及sql_mode等隐形依赖。
黑盒测试不是测数据库，是测业务SQL是否还能跑通
迁移前做黑盒测试，本质是绕过“数据有没有少”这种表层问题，直接验证应用发出来的SQL在新环境里能不能执行、结果对不对、性能扛不扛得住。它不关心表结构怎么建的，只看业务链路走不走得通。
从日志里捞出真实SQL，别信开发给的“典型语句”
开发说的“核心SQL”往往漏掉边缘 case，真正可靠的是线上真实流量。重点抓这些：
-
SELECT类：带JOIN、GROUP BY、ORDER BY LIMIT的报表查询，尤其注意没加索引字段的ORDER BY—— 迁移后可能因排序规则变化导致全表扫 -
INSERT/UPDATE类：含ON DUPLICATE KEY UPDATE或REPLACE INTO的写操作，MySQL 8.0 对唯一键冲突处理更严格，容易报错 -
事务块：跨多表的BEGIN; ... COMMIT;，重点看隔离级别（如READ-COMMITTED）下是否出现幻读或锁等待延长 - 含函数的语句：
NOW()、UNIX_TIMESTAMP()、JSON_EXTRACT()，不同版本对时区、JSON 空值返回行为有差异
执行时必须带 EXPLAIN 和实际结果比对
光看 SQL 能执行不报错没用，要确认它干的事和原来一样：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 在源库和目标库分别执行
EXPLAIN FORMAT=TRADITIONAL，对比type（是否从ref退化成ALL）、key（是否走了预期索引）、rows（预估扫描行数是否暴涨） - 执行后导出结果集到文件，用
sort | diff比对（注意加ORDER BY，否则顺序不定）；若含时间字段，统一转成 UTC 再比，避免时区干扰 - 对
UPDATE或DELETE，先用SELECT复现 WHERE 条件，确认影响行数一致；再查被改字段的值，比如status是否从 1 变成 2，而不是只看Rows matched: 100
别忽略权限和连接行为这类“隐形依赖”
很多黑盒失败根本不是 SQL 本身问题，而是环境差异：
- 用迁移后账号连目标库，执行
SHOW GRANTS，确认USAGE、EXECUTE（存过）、LOCK TABLES（某些备份脚本需要）没丢 - 检查
max_connections和wait_timeout，旧应用长连接未及时 close，新库超时断开会导致重连风暴 - 验证
sql_mode是否一致，特别是STRICT_TRANS_TABLES开关——旧库容忍空字符串插入NOT NULL字段，新库直接报错 - 如果用了代理（如
ProxySQL或MySQL Router），要测路由规则是否生效，比如读请求真发到了从库，而不是全打到主库
黑盒测试最难的不是跑 SQL，是把“业务认为正确”的结果翻译成可比对的确定性输出。时间字段格式、NULL 与空字符串、JSON 字段 key 排序……这些细节不提前对齐，diff 出来全是噪音。
