join时金额比较应在where而非on中，因on定义关联逻辑，where才用于过滤；需处理null、浮点精度、类型一致、索引优化及适用join类型。
JOIN 时用 WHERE 过滤金额不等，别用 ON
直接在 WHERE 子句里写 table1.amount != table2.amount，而不是塞进 ON 条件。ON 是用来定义关联逻辑的，不是筛数据的——放错地方会导致左表/右表记录被意外过滤或补 NULL，尤其用 LEFT JOIN 时，金额为 NULL 的记录可能根本不会进入比较范围。
常见错误现象：LEFT JOIN ... ON a.id = b.id AND a.amount != b.amount —— 这实际是“只连那些金额不等的匹配行”，但你真正要的是“先完整关联，再挑出金额不等的行”。
- 正确写法：先
LEFT JOIN或INNER JOIN关联两表，再用WHERE a.amount != b.amount - 注意 NULL：如果任一金额字段可能为
NULL，!=判断会失效（NULL != 100 返回 UNKNOWN），得加IS NOT NULL显式排除 - 浮点数慎用
!=：金额如果是FLOAT或DOUBLE，建议转成DECIMAL或用差值绝对值判断，比如ABS(a.amount - b.amount) > 0.01
用 INNER JOIN 还是 LEFT JOIN？看你要查什么
想查“两边都有、但金额对不上”的记录，用 INNER JOIN；想查“A 表有、B 表没对应记录，或金额不一致”的全量异常，就得用 LEFT JOIN 并配合 WHERE b.id IS NULL OR a.amount != b.amount。
使用场景差异：
-
INNER JOIN：核对已知配对关系（如订单表 vs 结算表，ID 必然存在） -
LEFT JOIN：排查缺失或错配（如原始流水 vs 对账文件，后者可能漏传） - 别用
FULL OUTER JOIN：多数 MySQL 版本不支持，且容易把“两边都缺”的脏数据也拉进来，干扰判断
金额字段类型不一致会导致 JOIN 失效
如果一张表用 DECIMAL(10,2)，另一张用 INT 或 VARCHAR 存金额，不仅比较结果不准，JOIN 本身也可能因隐式类型转换变慢甚至走错索引。
实操建议：
- 先用
SELECT COLUMN_NAME, DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS查两表金额字段类型 - 统一转成
DECIMAL再比，例如：CAST(a.amount AS DECIMAL(12,2)) != CAST(b.amount AS DECIMAL(12,2)) - 避免用
CONVERT或字符串函数做转换，性能差且易出精度丢失（比如ROUND(a.amount, 2)可能掩盖真实差异）
性能差？加索引和限制范围
大表 JOIN 查金额不一致，没索引基本跑不动。重点不是给金额字段建索引，而是给 JOIN 条件字段（如 order_id、trans_no）建联合索引，并把金额字段包含进去，形成覆盖索引。
可操作项：
- 建索引示例：
CREATE INDEX idx_order_amount ON table_a (order_id, amount) - 加时间范围限制：金额差异问题通常集中在最近 N 天，
WHERE a.created_at >= '2024-06-01'能极大提速 - 先抽样验证逻辑：
LIMIT 100看结果是否符合预期，再删掉跑全量
最容易被忽略的是 NULL 和浮点精度——这两点不处理，查出来的“不一致”可能是假阳性，或者真问题被漏掉。
