不能在JOIN结果上直接用WHERE updated_at > ?筛增量，否则会漏数据；正确做法是用GREATEST(COALESCE(t1.updated_at,'1970-01-01'),COALESCE(t2.updated_at,'1970-01-01'))计算逻辑增量时间戳，并下推时间过滤至子查询提升性能。
JOIN后怎么用时间戳做增量导出
直接结论：不能在JOIN结果上直接用WHERE updated_at > ?筛增量，否则会漏数据——因为关联表的更新可能早于主表，但业务上仍需导出该记录。
本质是「逻辑增量」而非「物理增量」：你要导出的是「自上次导出以来，任一相关表发生变更的完整业务记录」，不是「主表刚改过的行」。
- 正确做法是先算出所有涉及表的最新变更时间（比如用
GREATEST(t1.updated_at, t2.updated_at, t3.updated_at)），再和导出位点比较 - 注意
NULL值会让GREATEST返回NULL，必须用COALESCE兜底，例如GREATEST(COALESCE(t1.updated_at, '1970-01-01'), COALESCE(t2.updated_at, '1970-01-01')) - MySQL 5.7+支持
GREATEST，但PostgreSQL要用LEAST/GREATEST配合VALUES或窗口函数，语法更啰嗦
LEFT JOIN场景下时间戳字段怎么选
LEFT JOIN里右表记录可能为NULL，如果直接取t2.updated_at参与比较，整行会被WHERE过滤掉——这不是你想要的「主表有变更就导出」逻辑。
典型错误写法：WHERE t1.updated_at > ? OR t2.updated_at > ?，一旦t2为NULL，OR右边永远不成立。
- 必须把右表时间戳也
COALESCE成一个有效时间，比如COALESCE(t2.updated_at, t1.created_at) - 更稳妥的是统一用
COALESCE(t2.updated_at, '1970-01-01')，避免依赖created_at字段存在性 - 如果右表有软删除字段（如
is_deleted），记得在JOIN条件里带上AND t2.is_deleted = 0，否则NULL时间戳可能来自已删记录
导出SQL性能卡在JOIN+GREATEST怎么办
GREATEST本身不走索引，但真正拖慢的是「对JOIN结果集整体计算时间戳最大值」——数据库得先完成所有JOIN，再逐行算GREATEST，中间结果集越大越慢。
- 优先把时间筛选下推到子查询：先用
WHERE updated_at > ?分别过滤各表，再JOIN，比全量JOIN后筛快得多 - 给每个表的
updated_at建单独索引；如果经常按业务主键+时间联合查，考虑复合索引如(order_id, updated_at) - 避免在
SELECT里写GREATEST(...)然后在应用层再筛——这等于把计算和网络传输压力全扔给数据库
不同数据库对NULL和GREATEST的处理差异
MySQL中GREATEST(NULL, '2023-01-01')返回NULL；PostgreSQL里同语句直接报错ERROR: greatest() requires at least one argument，而且它不接受NULL参与比较。
- PostgreSQL必须写成
(SELECT MAX(x) FROM (VALUES (t1.updated_at), (t2.updated_at)) AS v(x)) - SQLite用
MAX(t1.updated_at, t2.updated_at)即可，但要注意它把NULL当最小值，所以MAX(NULL, '2023')返回'2023'，行为反而最省心 - Oracle用
GREATEST但要求所有参数类型一致，遇到DATE和TIMESTAMP混用会隐式转换失败，得显式CAST
跨库迁移时最容易栽在这里——看着SQL一样，跑起来要么报错，要么漏数据，连日志都看不出哪条记录被跳过了。
