STR函数专用于SQL Server，将数值转为右对齐、定宽、可指定小数位的字符串，用于报表对齐等场景；不跨数据库兼容，易因length不足返回“**”，且结果带前导空格，需RTRIM清理。
STR函数在SQL Server中能做什么
STR 是 SQL Server 特有的字符串转换函数，专用于把数值转成带指定宽度和小数位的右对齐字符串。它不适用于 MySQL、PostgreSQL 或 Oracle —— 这些数据库没有同名函数，强行用会报 Invalid column name 'STR' 或类似错误。
它的核心用途是格式化输出，比如生成固定长度的编号、对齐报表字段、拼接带前导空格的数值字符串。但要注意：它不是四舍五入工具，也不是类型转换通用方案。
STR函数的三个参数怎么填才不出错
STR 接收三个参数：STR(numeric_expression, length, decimal)。最容易出问题的是后两个——它们不是可选的，默认值不等于“不写”。省略 length 会导致语法错误；设得太小会截断或返回星号（*****）。
-
length至少为 1，且必须 ≥ 小数点前位数 + 小数点 + 小数位数 + （可能的负号）。例如STR(-123.456, 6, 2)会返回*****，因为 -123.46 需要 7 个字符（含负号和小数点），但只给了 6 位 -
decimal范围是 0–16，超出报错；设为 0 时小数部分直接截断（不是四舍五入），如STR(3.7, 4, 0)→' 4'？错，实际是' 3'—— 它先截小数再四舍五入整数部分？不，STR对整数部分不做进位，只按小数位截断后四舍五入小数部分，再整体转字符串 - 如果
numeric_expression是NULL，结果就是NULL，不会变成空字符串
为什么STR返回的字符串带前导空格
STR 默认右对齐，所以会在左边补空格凑够 length。这在 SELECT 中看起来像“多出空格”，导出到 Excel 或拼接时容易引发对齐或去重问题。
常见应对方式：
- 用
RTRIM()去掉尾部空格（但STR本身不产生尾部空格）→ 实际要RTRIM(LTRIM(...))？不需要，只需RTRIM即可，因空格只在左侧 - 更稳妥的是套一层
CONVERT(VARCHAR, ...)或CAST(... AS VARCHAR)，但会丢失格式控制能力 - 真要左对齐+定长，得自己拼：
RIGHT(SPACE(10) + CAST(@val AS VARCHAR), 10)
示例：SELECT STR(123.456, 8, 2) 返回 ' 123.46'（前面两个空格）；SELECT RTRIM(STR(123.456, 8, 2)) 返回 '123.46'（无空格，但长度不固定）
替代方案：跨数据库怎么安全格式化数值
如果你的 SQL 要跑在多个数据库上，或者用的是 PostgreSQL/MySQL，STR 直接不可用。这时候得换思路：
- SQL Server：坚持用
STR，但务必校验length是否足够；或改用FORMAT(value, '000.00')（SQL Server 2012+，但性能较差，且依赖语言设置） - PostgreSQL：用
TO_CHAR(value, 'FM999999.00')，FM去前导空格 - MySQL：没有内置等价函数，需组合
LPAD(CONVERT(ROUND(val,2), CHAR), 8, ' ')，但无法自动处理小数点对齐 - 通用底线：数值格式化尽量移到应用层做，数据库只负责算，别让它承担显示责任
真正麻烦的不是函数怎么写，而是团队里有人在 SQL Server 里调通了 STR，转头在另一套用 MySQL 的系统里照抄，然后卡在 FUNCTION STR does not exist 上半天没反应过来——这种跨环境假设，比语法本身更常导致上线失败。
