对账JOIN必须用业务主键而非时间戳，因时间字段存在精度、时钟同步及重复等问题；应使用order_id+channel等唯一组合，或至少2–3个无歧义字段；优先LEFT JOIN+IS NULL查差异，金额需转整型比较。
JOIN 条件必须用业务主键，不能只靠时间戳对齐
流水表对账最常踩的坑，就是拿 created_at 或 trade_time 字段直接 JOIN。时间字段精度不一致（MySQL 默认秒级，PostgreSQL 可能带毫秒）、系统时钟不同步、批量插入导致时间重复，都会让结果漏匹配或重复匹配。
真正可靠的依据是业务层面唯一且稳定的标识，比如：order_id + channel，或银行侧的 trace_id + settle_date。如果双方都没有全局唯一 ID，至少要组合 2–3 个字段（如 amount + payee_account + trade_date），并提前确认业务上无歧义。
- 先用
SELECT COUNT(*)分别查两张表的待对账记录数，再用COUNT(*)查 JOIN 后结果数——明显少于任一表，大概率是 JOIN 条件太严格；明显多于任一表，说明条件太松或存在一对多 - 避免在 ON 条件里写函数，比如
ON DATE(a.trade_time) = DATE(b.trade_time)，会导致索引失效；应提前把日期归一化为字段（如加trade_date CHAR(10)）
LEFT JOIN + IS NULL 是查“仅A有、B没有”的标准写法
对账核心诉求不是拼出完整记录，而是找出差异。用 INNER JOIN 只能看到两边都有的，反而掩盖问题。实际操作中，90% 的对账任务是查“我司有但银行没记”或“银行有但我司漏记”。
典型语句结构：
SELECT a.* FROM our_flow a LEFT JOIN bank_flow b ON a.order_id = b.order_id AND a.amount = b.amount WHERE b.order_id IS NULL;
注意点：
-
WHERE b.xxx IS NULL必须写在 JOIN 外层，不能写成ON ... AND b.order_id IS NULL，否则逻辑错误 - 金额字段要小心浮点数比较，建议统一转为分（整型）或用
ABS(a.amount - b.amount) - 如果一张表存在同一笔订单多次冲正，另一张表只有一条净额，需先聚合（
GROUP BY order_id）再 JOIN
对账结果里出现 NULL 不代表数据缺失，可能是类型不兼容
执行 JOIN 后某些字段显示 NULL，第一反应常是“对方没这条”，但更可能是字段类型或隐式转换导致匹配失败。比如：a.order_id 是 VARCHAR(32)，b.order_id 是 BIGINT，MySQL 会把字符串转数字比对，遇到含字母的 ID（如 "ORD-123"）就全变成 0，自然匹配不上。
排查步骤：
- 用
SELECT a.order_id, b.order_id, LENGTH(a.order_id), LENGTH(b.order_id)看长度和内容是否一致 - 检查字符集：若一张表是
utf8mb4，另一张是latin1，中文或特殊符号会乱码，JOIN 失效 - 留意空格：有些接口返回的 ID 带首尾空格，加
TRIM()再比对
大数据量时别用全字段 SELECT，先缩小范围再 JOIN
流水表动辄百万级，直接 SELECT * FROM a LEFT JOIN b ON ... 容易 OOM 或超时。真实对账流程里，应该分阶段推进：
- 先按日期分区过滤：只查
WHERE trade_date = '2024-06-15'，不要扫全表 - 用
EXPLAIN确认 JOIN 走了索引——重点看type是否为ref或eq_ref，key是否命中预期索引 - 如果 JOIN 结果仍很大，把差异记录 ID 写入临时表（
CREATE TEMPORARY TABLE diff_ids AS (...)），后续再关联查详情
对账不是一次性动作，而是持续校验过程。字段类型、编码、空值处理、精度误差这些细节，往往比 JOIN 语法本身更决定成败。
