不可行。current_timestamp是动态值，每次执行返回当前时刻，直接用where created_at = current_timestamp几乎永不匹配；查最近n分钟数据应使用>=加时间减法构造范围，如postgresql/mysql 8.0+中where created_at >= current_timestamp - interval '5 minutes'。
直接用 CURRENT_TIMESTAMP 作为查询条件可行吗？
不可行。把 CURRENT_TIMESTAMP 当作“固定时间点”去查历史记录，逻辑上就错了——它每次执行都返回当前时刻，而你真正想查的，通常是“最近几分钟/小时内写入的数据”。CURRENT_TIMESTAMP 本身不是过滤锚点，而是动态值，直接写 WHERE created_at = CURRENT_TIMESTAMP 几乎永远不匹配，因为精度和写入时差导致毫秒级不一致。
查“最近 N 分钟内”的记录怎么写才可靠？
用时间运算构造范围，而不是等值比较。不同数据库语法略有差异，但核心都是：用 CURRENT_TIMESTAMP 减去一个时间间隔，生成下界。
- PostgreSQL / MySQL 8.0+：
WHERE created_at >= CURRENT_TIMESTAMP - INTERVAL '5 minutes' - MySQL 5.7 及更早：
WHERE created_at >= DATE_SUB(NOW(), INTERVAL 5 MINUTE)（注意这里用NOW()更常见，CURRENT_TIMESTAMP在 MySQL 中是其同义词） - SQL Server：
WHERE created_at >= DATEADD(MINUTE, -5, GETDATE()) - SQLite：
WHERE created_at >= datetime('now', '-5 minutes')
关键点：必须用 >= + 时间减法，且确保 created_at 字段类型是 TIMESTAMP 或 DATETIME，不是字符串；否则索引失效，查询变慢。
为什么用 CURRENT_TIMESTAMP 而不是 NOW() 或 SYSDATE？
语义和事务一致性是主要区别：
-
CURRENT_TIMESTAMP在同一个事务中多次调用返回相同值（符合 SQL 标准），适合需要时间一致性的地方，比如批量插入时统一打时间戳 -
NOW()在 MySQL 中行为与CURRENT_TIMESTAMP相同；但在某些老版本或严格模式下可能有细微差异 -
SYSDATE()（MySQL）或SYSDATE（Oracle）返回的是函数执行瞬间的真实系统时间，同一事务里多次调用可能不同
查“最近记录”这种场景，三者效果通常一样，但如果你的查询嵌在存储过程或事务里，用 CURRENT_TIMESTAMP 更可预测。
容易忽略的时区陷阱
CURRENT_TIMESTAMP 返回的是数据库服务器本地时区的时间，不是你的应用时区，也不是 UTC。如果表里存的是 UTC 时间（推荐做法），而你直接用 CURRENT_TIMESTAMP 做比较，结果会偏移。
- 正确做法：统一用 UTC 存储 + 查询，例如 PostgreSQL 中用
CURRENT_TIMESTAMP AT TIME ZONE 'UTC' - MySQL 中需确认
time_zone系统变量设置，或显式转换：CONVERT_TZ(CURRENT_TIMESTAMP, @@session.time_zone, '+00:00') - 最稳妥方式：应用层生成 UTC 时间字符串传参，避免依赖数据库函数
时区错配不会报错，只会默默返回错误数据集——这是线上排查最头疼的问题之一。
