MySQL中必须用DATE_FORMAT()函数格式化日期输出，它接受日期值和格式模板两个参数，不支持TO_CHAR()或FORMAT()；常见错误包括%y与%Y、%m与%M混淆，且原生不支持中文星期需应用层处理。
MySQL 中用 DATE_FORMAT() 控制日期输出样式
MySQL 不支持直接用 TO_CHAR() 或标准 SQL 的 FORMAT()，必须用 DATE_FORMAT()。它第一个参数是日期值（可以是列、函数如 NOW()，或字符串），第二个是格式化模板字符串。
常见错误是把年份写成 %y（两位）却想要四位，结果得到 24 而不是 2024；或者混淆 %m（月份数字）和 %M（英文全称），导致返回 03 却期待 March。
-
DATE_FORMAT(NOW(), '%Y-%m-%d')→2024-03-15 -
DATE_FORMAT(created_at, '%d/%m/%Y %H:%i')→15/03/2024 14:22 - 想显示中文星期？
DATE_FORMAT(order_date, '%W')返回英文（如Friday），MySQL 原生不支持本地化 weekday 名称，得靠应用层转换或CASE映射
PostgreSQL 里优先用 TO_CHAR()，别碰 EXTRACT()
EXTRACT() 只能取单个字段（比如年、小时），不能拼字符串；真正做格式化得用 TO_CHAR()。它的第二个参数是模板字符串，语法和 Oracle 类似，但注意大小写敏感：YYYY 是四位年，yyyy 会报错。
容易忽略的是时区影响：如果字段是 TIMESTAMP WITHOUT TIME ZONE，TO_CHAR() 按数据库默认时区解释；如果是 WITH TIME ZONE，则自动转为当前会话时区再格式化——查出结果突然偏移 8 小时，大概率是这个原因。
-
TO_CHAR(payment_time, 'YYYY-MM-DD HH24:MI:SS')→2024-03-15 14:22:05 -
TO_CHAR(created_at, 'FMMonth DD, YYYY')中FM去掉前导空格，否则March前可能有空格 - 模板里双引号包裹的字符原样输出，例如
'"Order date: "YYYY-MM-DD'→Order date: 2024-03-15
SQL Server 的 FORMAT() 性能差，生产环境慎用
FORMAT() 写法最接近 C#，比如 FORMAT(order_date, 'yyyy-MM-dd HH:mm')，但它在 SQL Server 2012+ 才有，且底层调用 .NET，比 CONVERT() 慢 3–10 倍。高并发报表查询中，一个 FORMAT() 可能让执行时间从 200ms 拉到 2s。
替代方案是用 CONVERT() 配风格编号（style code），比如 CONVERT(VARCHAR, order_date, 120) 输出 2024-03-15 14:22:05（ISO 格式），但灵活性差——没法自定义分隔符或顺序。
- 真要动态格式，且数据量不大，才用
FORMAT()；否则优先CONVERT()+ 字符串拼接 -
FORMAT()第三个参数可指定文化（如'de-DE'），但服务器需安装对应语言包，否则报错Msg 9815 - 注意
NULL输入：FORMAT(NULL, 'yyyy-MM-dd')返回NULL，而CONVERT()对NULL也返回NULL，行为一致
跨数据库可移植的底线方案：用标准 SQL 的 CAST + 字符串截取
如果查询要跑在 MySQL / PostgreSQL / SQL Server 甚至 SQLite 上，DATE_FORMAT()、TO_CHAR()、FORMAT() 全都不通用。这时只能退到 ANSI SQL 的 CAST(date_col AS VARCHAR)，再配合 SUBSTRING() 或 LEFT() 拼接。
代价是失去语义控制：比如 CAST(order_date AS VARCHAR) 在 PostgreSQL 返回 2024-03-15 14:22:05.123456，在 SQL Server 可能是 Mar 15 2024 2:22PM——你得先 CHARINDEX() 或 POSITION() 找空格位置，再切，非常脆弱。
- 仅建议用于调试或一次性导出，别放进核心业务视图
- SQLite 没
DATE_FORMAT()，但支持strftime()，语法类似strftime('%Y-%m-%d', order_date)，属于特例，不能当通用解 - 真正的跨库统一，应该由应用代码（Python/Java）做格式化，SQL 层只传原始
DATE或TIMESTAMP值
