systimestamp 返回 timestamp with time zone 类型，含时区和微秒精度，非字符串，隐式转换依赖 nls 设置易出错，需用 to_char 显式格式化。
SYSTIMESTAMP 返回什么类型，为什么不能直接当字符串用
SYSTIMESTAMP 返回的是 TIMESTAMP WITH TIME ZONE 类型，不是字符串，也不是简单日期。直接在拼接 SQL 或插入 VARCHAR2 字段时会隐式转换，但结果依赖数据库的 NLS_TIMESTAMP_TZ_FORMAT 设置，容易出错或格式不统一。
常见错误现象：ORA-01805: possible error in date/time operation（尤其在跨时区应用中），或导出后时间显示为 01-JAN-22 12.00.00.000000000 AM +08:00 这类难读格式。
- 如需固定格式字符串，必须显式用
TO_CHAR(SYSTIMESTAMP, 'YYYY-MM-DD HH24:MI:SS.FF3 TZR') - 若只要秒级精度，用
TO_CHAR(SYSTIMESTAMP, 'YYYY-MM-DD HH24:MI:SS')更安全 - 避免依赖隐式转换——哪怕当前环境看似“正常”，换一套 NLS 配置就可能崩
SYSTIMESTAMP 和 SYSDATE 的关键区别在哪
两者都返回当前数据库时间，但 SYSDATE 是 DATE 类型（无时区、无毫秒），SYSTIMESTAMP 带时区和微秒精度。这不是“升级版”，而是用途完全不同。
使用场景差异：
- 做表分区键、审计字段需精确到毫秒或跨时区比对 → 必须用
SYSTIMESTAMP - 老系统兼容 DATE 字段、或只关心日/时/分 → 用
SYSDATE更轻量，性能略优（少解析时区） -
SYSTIMESTAMP在分布式事务中更可靠，因它包含时区信息，可还原真实发生时刻
在 INSERT 或 UPDATE 语句里怎么安全写 SYSTIMESTAMP
直接写 SYSTIMESTAMP 没问题，但要注意目标列类型是否匹配。最常踩的坑是往 DATE 列插 SYSTIMESTAMP，Oracle 会截断时区和毫秒，不报错但丢精度。
- 目标列为
TIMESTAMP WITH TIME ZONE：直接写SYSTIMESTAMP即可 - 目标列为
TIMESTAMP（无时区）：用CAST(SYSTIMESTAMP AS TIMESTAMP)显式剥离时区 - 目标列为
DATE：用TRUNC(SYSTIMESTAMP)或SYSDATE，别用TO_DATE(TO_CHAR(...))绕路 - 如果字段允许为空且想默认填当前时间戳，建表时定义
DEFAULT SYSTIMESTAMP，比触发器更高效
SYSTIMESTAMP 在函数或物化视图里会被多次求值吗
会。Oracle 对 SYSTIMESTAMP 这类“非确定性函数”不做语句级缓存。同一 SQL 中多次出现，每次调用都重新取系统时间，可能导致微妙不一致。
比如：SELECT SYSTIMESTAMP t1, SYSTIMESTAMP t2 FROM DUAL，t1 和 t2 的微秒部分大概率不同。
- 需要“语句内一致”的时间戳，先用子查询或 CTE 固定一次：
WITH now AS (SELECT SYSTIMESTAMP ts FROM DUAL) SELECT ts t1, ts t2 FROM now - 物化视图刷新时，
SYSTIMESTAMP取值是刷新开始时刻，不是每行计算；但快速刷新（FAST）模式下行为复杂，建议避免在 MV 定义里直接依赖它 - 函数内多次调用
SYSTIMESTAMP，除非加 PRAGMA UDF 或用变量缓存，否则无法保证一致性
SYSTIMESTAMP 只是“能用”，得清楚它在哪被截断、在哪被转、在哪悄悄变了。
