不会报语法错误但结果可能不符合预期：TIMESTAMP只能加INTERVAL DAY TO SECOND，加INTERVAL YEAR TO MONTH需先转为TIMESTAMP WITH TIME ZONE或用ADD_MONTHS()；INTERVAL精度声明影响计算行为与性能。
INTERVAL 直接加减 TIMESTAMP 会出错吗？
不会报语法错误，但结果可能不符合预期——timestamp 和 interval day to second 或 interval year to month 属于不同家族，不能混用。比如写 ts + interval '1' month 看似合理，但如果 ts 是 timestamp 类型而没显式指定时区，oracle 可能按会话时区解释，导致跨月计算出错（如 1 月 31 日 + 1 个月 → 2 月 29 日或 3 月 3 日，取决于版本和 nls 设置）。
- 必须匹配类型：
TIMESTAMP只能加INTERVAL DAY TO SECOND；TIMESTAMP WITH TIME ZONE才能安全加INTERVAL YEAR TO MONTH -
DATE类型反而更“宽容”，能直接加两种INTERVAL，但精度丢失（秒级归零） - 常见错误现象：
ORA-01841: (full) year must be between -4713 and +9999, and not be 0，多因隐式转换把INTERVAL YEAR TO MONTH当成年份字面量用了
怎么让 TIMESTAMP + INTERVAL YEAR TO MONTH 安全生效？
核心是把 TIMESTAMP 升级为带时区的类型，再用 FROM_TZ 或 AT TIME ZONE 显式锚定上下文。
- 先转成
TIMESTAMP WITH TIME ZONE：FROM_TZ(ts, 'UTC')或ts AT TIME ZONE 'UTC' - 再加
INTERVAL YEAR TO MONTH，Oracle 才会按日历语义处理（如自动跳过不存在的日期） - 如果只是想加月数且不关心时区，更稳妥的做法是用
ADD_MONTHS()函数，它专为日历运算设计，对TIMESTAMP也支持（内部转DATE再转回，但秒级保留） - 注意：
ADD_MONTHS()不接受负的INTERVAL字面量，只能传数字，比如ADD_MONTHS(ts, -3)
INTERVAL DAY TO SECOND 的精度陷阱有哪些？
INTERVAL DAY TO SECOND 看似简单，但字段精度声明直接影响计算行为。声明为 INTERVAL DAY(2) TO SECOND(3) 和默认的 DAY(9) TO SECOND(6) 在拼接字符串、绑定变量或跨库迁移时容易出问题。
- 绑定变量未指定精度时，JDBC 或 ODP.NET 可能截断微秒，导致
+ INTERVAL '1.123456' SECOND实际变成+ INTERVAL '1.123' SECOND - 字符串转
INTERVAL时，格式必须严格匹配声明精度，否则报ORA-01867；建议统一用NUMTODSINTERVAL(n, 'SECOND')避免解析歧义 - 性能影响：高精度
INTERVAL（如SECOND(6)）在大量计算中比SECOND(0)多约 5% CPU 开销，纯秒级场景可降精度
跨时区 TIMESTAMP 运算后怎么保持本地时间一致性？
当原始 TIMESTAMP WITH TIME ZONE 来自不同时区（如 'Asia/Shanghai' 和 'America/New_York'），直接相减得到的 INTERVAL DAY TO SECOND 是绝对时长，但若想表达“当地时间过了几天几小时”，必须先统一时区。
- 别用
ts1 - ts2得到间隔后反推本地感知，应先对齐：(ts1 AT TIME ZONE 'UTC') - (ts2 AT TIME ZONE 'UTC') - 如果目标是“上海时间下，两个事件相隔多少个自然日”，得用
TRUNC(ts1 AT TIME ZONE 'Asia/Shanghai') - TRUNC(ts2 AT TIME ZONE 'Asia/Shanghai') - 容易被忽略的是夏令时切换日：同一时区里，某天可能只有 23 小时或 25 小时，
INTERVAL计算仍按 UTC 秒数，但业务上可能需要按“日历日”计数
