视图中对日期字段使用 DATE_FORMAT 或 CONVERT 会导致索引失效、触发全表扫描并增加维护成本；正确做法是直接在 WHERE 条件中使用原始日期字段进行范围查询。
在视图里对日期字段调用 DATE_FORMAT 或 CONVERT 做格式化，等于主动放弃索引、引入排序陷阱、增加维护成本——除非你明确接受这些代价，否则不该这么做。
MySQL 视图中用 DATE_FORMAT 会彻底失效索引
哪怕原表 created_at 上有 B+ 树索引，只要视图定义里写了 DATE_FORMAT(created_at, '%Y-%m')，后续查询这个视图的该列就无法走索引。MySQL 把它当表达式处理，全表扫描是常态。
- 错误写法：
SELECT DATE_FORMAT(created_at, '%Y-%m') AS month_str FROM orders_vw WHERE month_str = '2026-05'→ 全表扫 - 正确替代：
WHERE created_at >= '2026-05-01' AND created_at ，保留原始字段参与条件 - 如果真要导出“2026-05”这种字符串列，建议加生成列：
ALTER TABLE orders ADD COLUMN created_month VARCHAR(7) AS (DATE_FORMAT(created_at, '%Y-%m')) STORED，再在视图里 SELECT 它
SQL Server 视图中优先用 CONVERT 而非 FORMAT
FORMAT 功能强但性能差，尤其在大结果集上会触发 .NET CLR 逐行计算；CONVERT 是原生 C++ 实现，快且兼容 SQL Server 2008+。
- 推荐写法：
CONVERT(CHAR(10), order_date, 120)→ 输出2026-05-19，长度固定、无尾部空格 - 避免写
CONVERT(VARCHAR, order_date, 120)：VARCHAR 不定长，可能带空格，JOIN 或 GROUP BY 时隐式出错 - 别用
FORMAT(order_date, 'yyyy-MM-dd')做高频视图字段，除非确认版本 ≥2012 且能容忍 3–5 倍响应延迟
跨数据库视图无法统一日期格式化逻辑
不存在一个 SQL 写法，能让同一段视图定义在 MySQL 和 SQL Server（更别说 Oracle）里都跑通。函数名、参数顺序、格式符规则全不同。
- MySQL 必须用
DATE_FORMAT(date_col, '%Y-%m-%d') - SQL Server 必须用
CONVERT(CHAR(10), date_col, 120)或FORMAT(date_col, 'yyyy-MM-dd') - Oracle 必须用
TO_CHAR(date_col, 'YYYY-MM-DD')，写成CONVERT直接报ORA-00904 - 实际做法：为每个数据库单独建同名视图，字段语义一致，仅格式化部分按方言重写
最常被忽略的一点：视图里的格式化列一旦返回字符串，下游应用若拿它做日期运算（比如 + INTERVAL 1 DAY）或范围比较（比如 BETWEEN '2026-05' AND '2026-08'），结果几乎必然错——因为那是字典序，不是时间序。
