视图中对日期字段格式化会丢失索引能力且引发排序/比较错误，应保留原始时间字段，格式化交由应用层或使用生成列、提取函数等可索引方式处理。
MySQL 视图里用 DATE_FORMAT() 会丢失索引能力
视图本身不存储数据，只是保存查询逻辑；但一旦在 SELECT 中对字段用 DATE_FORMAT() 包裹，这个字段就变成表达式结果，无法走原表上的日期索引。比如你有 created_at 索引，但视图里写成 DATE_FORMAT(created_at, '%Y-%m')，后续 WHERE 条件再查这个视图的该列，基本等于全表扫描。
实操建议：
- 视图只做「结构投影」，别做格式化 —— 把
created_at原样 SELECT 出来，格式化交给应用层或查询时临时加 - 真需要统一格式输出，考虑用生成列（MySQL 5.7+）：给原表加一个
created_month虚拟列，定义为DATE_FORMAT(created_at, '%Y-%m')，再在视图里 SELECT 它；这样既能复用，又不影响主字段索引 - 如果必须在视图里格式化，且查询条件又依赖该格式（比如按年月分组统计），那就得接受性能代价，并确保底层表数据量可控
PostgreSQL 视图中用 TO_CHAR() 后排序/比较行为易出错
TO_CHAR(created_at, 'YYYY-MM') 返回的是文本，不是日期。这意味着：按这个字段 ORDER BY 是字典序，不是时间序；WHERE month_col > '2024-03' 看似合理，实则依赖字符串比较规则，遇到 '2024-10' 和 '2024-09' 时可能反直觉。
实操建议：
- 视图里保留原始
TIMESTAMP或DATE字段，额外提供格式化列仅作展示用，命名上加后缀区分，比如created_at_str - 需要按年月聚合？用
EXTRACT(YEAR FROM created_at)和EXTRACT(MONTH FROM created_at)组合，或直接用DATE_TRUNC('month', created_at)—— 这俩都返回时间类型，可索引、可比较、可排序 - 如果业务强依赖字符串格式（如导出 Excel 表头），宁可用视图 + 应用层映射，也别让格式化污染查询逻辑
SQL Server 视图里 CONVERT() 和 FORMAT() 的兼容性差异
CONVERT() 支持老版本（2008+），速度快，但格式选项少；FORMAT() 功能强（支持文化参数、自定义模式），但 SQL Server 2012 才引入，且性能差不少 —— 尤其在大结果集上，它会逐行调用 .NET CLR。
实操建议：
- 只要需求是标准格式（如
'yyyy-MM-dd'），一律用CONVERT(VARCHAR, created_at, 23)—— 第三个参数是风格码，23 对应 ISO8601 无时区日期 - 避免在视图里用
FORMAT(created_at, 'yyyy-MM')，除非你确认 SQL Server 版本 ≥2012 且能接受性能损耗 - 如果必须本地化（比如显示中文月份），别在视图里做，放到应用层处理更可控
跨数据库视图统一日期输出的现实妥协点
没有银弹。不同数据库的日期函数名、参数顺序、风格码、返回类型都不一致，硬写一个“通用视图”只会导致维护噩梦。比如 PostgreSQL 的 TO_CHAR() 和 MySQL 的 DATE_FORMAT() 看似等价，但前者支持时区修饰符，后者不支持；SQL Server 的 CONVERT() 风格码又和它们完全不兼容。
实操建议：
- 视图只暴露原始时间字段，格式化逻辑下沉到 ORM 层（如 Django 的
datefilter、Laravel 的format()）或前端（Day.js / Luxon） - 如果必须数据库层统一，用视图 + 数据库特有函数，但加好注释说明适用版本和限制，比如：
-- 注意：此视图仅适用于 MySQL 8.0+，DATE_FORMAT 不支持时区 - 最常被忽略的一点：时区。所有格式化函数默认用数据库服务器时区，而你的应用很可能跑在 UTC 或其他时区 —— 视图里不做
AT TIME ZONE或CONVERT_TZ()处理，早晚出时间错位问题
