Oracle中TO_CHAR日期格式模板需用自定义格式模型，如'YYYY-MM-DD HH24:MI:SS'，其中YYYY为4位年份、MM为月份数字（01–12）、HH24为24小时制、MI为分钟、SS为秒；大小写敏感，MI才是分钟而非mm；'DAY'返回全大写英文星期，需配合NLS_DATE_LANGUAGE参数输出中文；'MON'为月份缩写，'MONTH'为全称；带时区应使用SYSTIMESTAMP及'TZH:TZM'；'Q'表示季度（1–4），'WW'按1月1日所在周为第1周，'IW'为ISO标准周；TO_CHAR(NULL, ...)返回NULL不报错，但WHERE中会导致行被过滤，建议用原生日期比较替代。
TO_CHAR在Oracle里怎么写日期格式模板？
Oracle的TO_CHAR不是简单套几个字母，它用的是自定义格式模型，比如'YYYY-MM-DD HH24:MI:SS'里每个字符都对应特定含义——YYYY是4位年份，MM是月份数字（01–12），HH24是24小时制，MI是分钟，SS是秒。大小写敏感，mm会被当成“月份”的别名（实际无效），MI才是分钟。
常见错误是混用格式符：比如想输出中文星期却写成'DAY'，结果得到全大写的英文（如‘MONDAY’）；正确写法是'DY'配NLS_DATE_LANGUAGE参数，或直接用'DAY'加'NLS_DATE_LANGUAGE=SIMPLIFIED CHINESE'上下文。
-
'DD-MON-YYYY'→'05-JAN-2024'（注意MON是缩写，MONTH才是全称） - 带时区的写法：
TO_CHAR(SYSTIMESTAMP, 'YYYY-MM-DD"T"HH24:MI:SS.FF3TZH:TZM')，其中FF3取毫秒前三位，TZH:TZM输出+08:00这类偏移 - 避免
'Q'（季度）和'WW'（全年第几周）混淆——'Q'返回1–4，'WW'按1月1日所在周算第1周，而'IW'才是ISO标准周（周一为起点，第1周含当年第一个周四）
为什么TO_CHAR处理NULL日期会报错？
TO_CHAR(NULL, 'YYYY-MM-DD')本身不报错，返回NULL；但常见陷阱是把TO_CHAR嵌在WHERE或JOIN条件里，比如WHERE TO_CHAR(date_col, 'YYYY') = '2024'——如果date_col为NULL，整个表达式结果为NULL，导致该行被过滤掉，而非“忽略”。这不是函数问题，而是SQL三值逻辑的必然结果。
- 安全写法：显式处理空值，
WHERE NVL(TO_CHAR(date_col, 'YYYY'), '1970') = '2024' - 更推荐用原生日期比较：
WHERE date_col >= DATE '2024-01-01' AND date_col ，避免函数导致索引失效 - 若必须格式化后比对（比如跨库同步需字符串一致），先确认
date_col非空：WHERE date_col IS NOT NULL AND TO_CHAR(date_col, 'YYYY') = '2024'
PostgreSQL或MySQL能直接用TO_CHAR吗？
不能。TO_CHAR是Oracle/PostgreSQL的函数，但MySQL完全不支持——它用DATE_FORMAT()替代，语法和格式符完全不同。PostgreSQL虽有TO_CHAR()，但格式符部分兼容Oracle，部分需调整，比如Oracle的'D'（一周第几天，周日=1）在PG里默认是'ID'（ISO标准，周一=1）。
- MySQL等效写法：
DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i:%s')，注意%i是分钟，%s是秒，%H是24小时制 - PostgreSQL中
TO_CHAR(NOW(), 'YYYY-MM-DD HH24:MI:SS')可用，但TO_CHAR(NOW(), 'Day')会右补空格到长度9，需加TRIM或改用'FMDay'（FM去掉填充） - 跨数据库迁移时，最稳妥的方式是应用层格式化，或统一用标准ISO格式
TO_CHAR(dt, 'YYYY-MM-DD"T"HH24:MI:SS')再适配各方言
性能上，TO_CHAR用在WHERE里有多伤？
极伤。只要TO_CHAR(date_col, 'YYYY-MM-DD')出现在WHERE左侧，哪怕date_col上有索引，Oracle/PG也大概率无法走索引范围扫描，退化为全表扫描。因为函数改变了列的原始值形态，优化器无法直接匹配索引B树结构。
- 真实案例：某表1000万行，
WHERE TO_CHAR(create_time, 'YYYY') = '2024'耗时3.2秒；改写为WHERE create_time >= DATE '2024-01-01' AND create_time 后降到0.08秒 - 如果必须按格式查（比如前端传了
'2024-01-01'字符串），用函数索引：CREATE INDEX idx_create_time_yyyymmdd ON t (TO_CHAR(create_time, 'YYYY-MM-DD'))，但维护成本高，且只对该固定格式生效 - 真正复杂的格式化（如“2024年一月五日”）应该放在SELECT列表里，而不是过滤条件里
日期格式化的本质是展示层需求，不是数据筛选逻辑。把TO_CHAR塞进WHERE，基本等于主动放弃索引——这点容易被赶工期时忽略，但上线后查慢就只能重构。
