TO_CHAR丢毫秒是因为默认格式模型不支持毫秒，必须用FF3等分数秒修饰符显式指定。正确写法为TO_CHAR(event_time, 'YYYY-MM-DD HH24:MI:SS.FF3')，且需注意索引失效与跨库兼容性问题。
TO_CHAR 处理带毫秒的时间字段时为什么总丢掉毫秒？
因为标准 Oracle TO_CHAR 的默认时间格式模型（如 'YYYY-MM-DD HH24:MI:SS'）根本不解析毫秒——它只识别秒级及以上的单位。哪怕源字段是 TIMESTAMP(3)，不显式指定毫秒占位符，毫秒部分就直接被截断或补零。
真正起作用的是格式模型里的 FF（Fractional Seconds）修饰符，且必须和底层数据的精度匹配：
-
FF1到FF9分别表示 1~9 位小数秒，FF3对应毫秒（三位） - 如果字段定义为
TIMESTAMP(6)（微秒），但用FF3格式化，会四舍五入截断到毫秒，不是丢弃 - Oracle 12c 及以后支持
FF直接写成FF（自动适配精度），但老版本必须写死位数，比如FF3
正确写法：TIMESTAMP(3) 字段必须用 FF3 显式声明
假设表 logs 有列 event_time TIMESTAMP(3)，要输出形如 2024-05-22 14:30:45.123 的字符串：
SELECT TO_CHAR(event_time, 'YYYY-MM-DD HH24:MI:SS.FF3') FROM logs;
注意几个关键点：
- 小数点
.是字面量，必须手动写在格式串里，FF3本身不带分隔符 - 不要用
MS或MILLISECOND—— Oracle 不识别这些，会报错ORA-01821: date format not recognized - 如果想对齐显示（如固定 3 位毫秒，即使原始值是
.5也显示为.500），FF3天然支持，无需额外处理
性能陷阱：在 WHERE 或 JOIN 中滥用 TO_CHAR 会导致索引失效
把 TO_CHAR(event_time, 'YYYY-MM-DD HH24:MI:SS.FF3') 放在查询条件里，比如：
WHERE TO_CHAR(event_time, 'YYYY-MM-DD HH24:MI:SS.FF3') = '2024-05-22 14:30:45.123'
这会让 Oracle 无法使用 event_time 上的普通 B-tree 索引。更高效的做法是反向操作：
- 用
TO_TIMESTAMP把字符串转回时间类型，再做范围比较 - 或者直接用原生时间比较：
event_time BETWEEN ... AND ... - 若必须按格式字符串查，考虑建基于函数的索引：
CREATE INDEX idx_event_time_ff3 ON logs (TO_CHAR(event_time, 'YYYY-MM-DD HH24:MI:SS.FF3'));，但需权衡维护成本
跨数据库兼容性提醒：TO_CHAR(FF) 是 Oracle 特有语法
PostgreSQL 用 TO_CHAR(ts, 'YYYY-MM-DD HH24:MI:SS.MS')（MS 表示毫秒），MySQL 用 DATE_FORMAT(dt, '%Y-%m-%d %H:%i:%s.%f')（%f 是微秒，需除以 1000 截取毫秒）。一旦代码需要迁移：
- 别硬套 Oracle 的
FF3写法，否则在其他库直接报错 - 应用层做格式化比 SQL 层更可控，尤其涉及多数据库时
- 如果坚持 SQL 层统一，至少把格式逻辑封装进视图或函数，隔离方言差异
毫秒精度的格式化看着简单，但格式符、索引行为、跨库移植这三点，任何一个没对齐，后面查不出数据或查得慢，都是悄无声息的坑。
