SQL中SECOND()函数仅MySQL 8.0+和SQL Server原生支持；PostgreSQL需用EXTRACT(SECOND FROM ...)，SQLite用strftime('%S', ...)并转整型，Oracle用EXTRACT或TO_CHAR；多数数据库对NULL敏感，且秒提取不保留毫秒精度。
SQL里根本没有SECOND()函数，别被名字骗了
多数人搜“SQL SECOND函数”是想从时间字段里提取秒数，但得先认清现实：SECOND()只在MySQL 8.0+和SQL Server里原生支持；PostgreSQL用EXTRACT(SECOND FROM ...)；SQLite压根没这个函数，得靠strftime('%S', ...)；而Oracle用的是EXTRACT(SECOND FROM ...)或TO_CHAR(..., 'SS')。直接写SECOND(my_time)在很多环境里会报function does not exist错误。
MySQL和SQL Server怎么安全取秒数
MySQL 5.7及更早版本不支持SECOND()，必须升级到8.0+才可用。SQL Server倒是从2005起就支持，但要注意参数类型：只接受DATETIME、DATETIME2、TIME，传入字符串会隐式转换，可能出错。
- MySQL 8.0+ 正确写法：
SELECT SECOND('2023-01-01 12:34:56')→ 返回56 - SQL Server 正确写法：
SELECT SECOND('2023-01-01 12:34:56')→ 同样返回56 - 如果字段是
VARCHAR存的时间（如'12:34:56'），先转成TIME再用：SECOND(CAST(time_str AS TIME))
PostgreSQL和SQLite的替代方案
PostgreSQL不认SECOND()，硬写会报错function second(unknown) does not exist。SQLite连EXTRACT都不支持，必须用字符串函数兜底。
- PostgreSQL：用
EXTRACT(SECOND FROM my_time_col)::INTEGER，注意返回的是double precision，强制转INTEGER避免小数 - SQLite：用
CAST(strftime('%S', my_time_col) AS INTEGER)，strftime返回字符串，不转类型会导致排序/计算异常 - 两者都对NULL值敏感——输入NULL，结果也是NULL，做聚合前记得加
WHERE my_time_col IS NOT NULL
秒级数据处理时最容易忽略的精度陷阱
秒数本身是整数，但很多数据库内部把时间存成带微秒的类型（比如TIMESTAMP(6)），直接取秒可能丢掉毫秒部分影响业务逻辑——比如按秒聚合订单时，12:34:56.999和12:34:56.001会被归到同一秒，但实际相差近1秒。
- 需要精确到毫秒级分组？别只取秒，改用
FLOOR(EXTRACT(EPOCH FROM my_time_col))（PostgreSQL）或UNIX_TIMESTAMP(my_time_col)（MySQL）转为秒级时间戳再处理 - 做范围查询（比如“查56秒整的数据”）时，用
SECOND(col) = 56不如写col >= '... 56:00' AND col ，后者能走索引，前者必然全表扫描 - 跨数据库写SQL？别硬套某个方言的函数，优先用ANSI标准的
EXTRACT（PostgreSQL/Oracle/SQL Server支持），MySQL 8.0+也兼容
不同数据库对“秒”的定义其实有细微差别——比如是否包含闰秒、是否四舍五入，真正在金融或日志分析场景用，得先确认你用的数据库版本和时区设置是否一致。
