最稳妥方式是WHERE updated_at > NOW() - INTERVAL 1 HOUR（MySQL）、current_timestamp - INTERVAL '1 hour'（PostgreSQL）或datetime('now', '-1 hour')（SQLite），需确保updated_at有索引且不被函数包裹，类型匹配，注意时区与精度。
WHERE子句里用NOW()减去时间间隔比较快
直接在WHERE里写updated_at > NOW() - INTERVAL 1 HOUR是最常用也最稳妥的方式。MySQL支持这种写法，语义清晰，索引也能用上（前提是updated_at字段有索引）。注意别写成DATE_SUB(NOW(), INTERVAL 1 HOUR)——虽然结果一样，但函数包裹列会导致索引失效。
-
updated_at字段类型必须是DATETIME或TIMESTAMP，不能是字符串（比如VARCHAR存的"2024-05-20 14:30:00"） - 如果表数据量大但没给
updated_at建索引，这条查询会全表扫描，延迟明显 - 跨时区要注意：
NOW()返回的是服务器本地时区时间，如果业务按UTC存时间，得改用UTC_TIMESTAMP()
PostgreSQL里得用current_timestamp和INTERVAL
PostgreSQL不认NOW() - INTERVAL '1 hour'这种简写，必须显式写成current_timestamp - INTERVAL '1 hour'。而且它对大小写不敏感，但INTERVAL后面的单位字符串必须带单引号。
- 错误写法：
updated_at > current_timestamp - INTERVAL 1 hour→ 缺少引号，报错syntax error at or near "1" - 正确写法：
updated_at > current_timestamp - INTERVAL '1 hour' - 如果字段是
timestamp with time zone，current_timestamp自动带时区，不用额外处理；但如果是timestamp without time zone，就得确认存储逻辑是否统一
SQLite里没有INTERVAL，得靠datetime()函数
SQLite时间函数弱，得用datetime('now', '-1 hour')生成边界时间点，再跟updated_at比。注意它的datetime()返回的是ISO8601字符串（如"2024-05-20 14:30:00"），所以updated_at也得是同样格式的字符串或TEXT类型——否则比较会出错。
- 如果
updated_at是整数时间戳（秒级或毫秒级），得先转：datetime(updated_at, 'unixepoch')（秒级）或datetime(updated_at/1000, 'unixepoch')（毫秒级） - 别用
strftime('%s', 'now') - 3600再反查，太绕且无法利用索引 - SQLite默认不校验日期格式，存了"2024/05/20"这种也会通过，但
datetime()可能解析失败，返回NULL导致查不到数据
WHERE条件里别对字段用函数，否则索引白建
不管哪种数据库，只要在updated_at上套函数（比如DATE(updated_at)、UNIX_TIMESTAMP(updated_at)），优化器就无法走索引。真正要查“最近一小时”，就得让字段本身参与比较，而不是把它变成另一个值后再比。
- 错误示范：
UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(updated_at) → 两个函数调用，必全表扫 - 正确思路：把动态边界算出来，让字段“裸奔”参与比较，例如
updated_at > '2024-05-20 14:30:00'（哪怕这个字符串是程序拼的） - 如果应用层能预计算时间点（比如PHP里
date('Y-m-d H:i:s', time() - 3600)），传参进去，反而比数据库里算更可控
时间精度容易被忽略：有些系统用毫秒级时间戳存updated_at，但查询时只按秒比，会漏掉最后那部分数据；反过来，如果字段是秒级但用了毫秒级函数（如MySQL的SYSDATE(3)），也可能因精度截断导致边界偏差。
