SQL Server中CONVERT函数输出ISO标准日期（YYYY-MM-DD）的样式代码是23；它专用于纯日期格式，不带时间，兼容性好、性能优，且不受区域设置影响。
CONVERT函数中ISO日期样式的数字代码是多少
SQL Server里CONVERT函数输出ISO标准日期（即YYYY-MM-DD格式），关键不是靠“ISO”这种字符串，而是用固定的样式编号23。这个编号对应的就是不带时间的纯ISO 8601日期格式，和CAST或FORMAT不同，它不依赖区域设置，也不需要额外参数。
常见误区是误用120（YYYY-MM-DD HH:MI:SS）或126（带T分隔符的完整ISO 8601），它们都包含时间部分，不符合“仅日期”的ISO要求。
-
CONVERT(varchar, GETDATE(), 23)→2024-05-21 -
CONVERT(char(10), OrderDate, 23)→ 精确10位，无空格、无时间 - 样式
23在SQL Server 2005+全版本支持，但不适用于Azure SQL Database的某些旧兼容级别（需≥120）
为什么不用FORMAT或CONCAT拼接来实现ISO日期
FORMAT虽然能写成FORMAT(GETDATE(), 'yyyy-MM-dd')，但性能差、不可SARGable，且在高并发报表场景下CPU开销明显高于CONVERT。而用CONCAT(YEAR(d), '-', RIGHT('0'+MONTH(d),2), '-', RIGHT('0'+DAY(d),2))这类手动拼接，不仅冗长，还容易因隐式转换或NULL值导致意外截断或报错Conversion failed when converting date and/or time from character string。
-
CONVERT是底层类型转换，执行计划里直接走计算标量，无函数调用开销 -
FORMAT在WHERE子句中会强制索引扫描，CONVERT(..., 23)仍可利用索引查找（如果列上有日期索引） - 当源字段为
datetime2或date时，CONVERT(varchar, d, 23)结果始终稳定；而FORMAT对null返回NULL，手动拼接可能返回NULL或空字符串，行为不一致
CONVERT(23)在不同日期类型上的表现差异
CONVERT样式23对date、datetime、datetime2都有效，但输出长度和精度隐含逻辑不同：
- 输入是
date：输出固定YYYY-MM-DD，无多余字符 - 输入是
datetime：只取日期部分，忽略1900-01-01 14:30:00.000中的时间，不会四舍五入或截断日期本身 - 输入是
datetime2(7)：同样只截取日期，但要注意——如果字段允许NULL，CONVERT(varchar, nullable_col, 23)结果也是NULL，不是空字符串 - 避免用
CONVERT(char(10), ... , 23)处理可能为NULL的列，否则会变成10个空格；应改用varchar或加ISNULL
实际查询中CONVERT(23)的典型误用场景
最常出问题的是在JOIN或GROUP BY中混用不同样式，或者把CONVERT结果当成日期再参与计算。比如：
SELECT CONVERT(varchar, OrderDate, 23) AS iso_date FROM Orders WHERE CONVERT(varchar, OrderDate, 23) = '2024-05-21'
这句看似合理，实则无法走索引，且若OrderDate有大量数据，性能急剧下降。更糟的是有人写成：
WHERE CONVERT(date, CONVERT(varchar, OrderDate, 23)) = '2024-05-21'
多套一层CONVERT毫无意义，还增加CPU负担。真正该做的是：
- WHERE OrderDate >= '2024-05-21' AND OrderDate
- SELECT CONVERT(varchar, OrderDate, 23) AS iso_date —— 仅用于输出展示，不在过滤/连接逻辑中使用
- 如果必须按ISO字符串分组，优先考虑在应用层处理，或用计算列+索引固化
样式23本身很简单，但它的威力只在“只读展示”时才完全释放；一旦卷入逻辑判断，就该立刻退回到原生日期类型操作。
