sql server的format函数可加千分位但返回字符串，仅限展示层使用；不可用于where、join等数值逻辑，否则引发隐式转换、性能下降及索引失效。
SQL Server 的 FORMAT 函数能直接加千分位，但别在 WHERE 或 JOIN 中用
FORMAT 是 SQL Server 2012+ 提供的字符串格式化函数，对货币类数值做展示层美化很顺手。但它返回的是 string 类型，不是数值——这意味着一旦你把它用在过滤、计算或关联字段上，就会触发隐式转换，拖慢查询，甚至导致索引失效。
常见错误写法：WHERE FORMAT(price, 'C', 'zh-CN') LIKE '%1,000%' —— 这会让整张表扫描，因为无法走 price 列上的索引。
正确姿势只用于最终 SELECT 输出：
SELECT FORMAT(price, 'C', 'zh-CN') AS formatted_price FROM orders;
- 第三个参数指定文化（如
'en-US'输出$1,234.56，'zh-CN'输出¥1,234.56） - 如果只要数字加千分位不带符号，用
'N2'（保留两位小数）或'N0'（无小数） - 注意：
FORMAT在大数据量下性能明显弱于CONVERT+ 字符串拼接，仅推荐用于报表导出、前端展示等非关键路径
MySQL 没有内置 FORMAT，但 FORMAT() 函数可替代（注意括号和大小写）
MySQL 的 FORMAT() 是一个原生函数，功能类似但语法更简单：它只接受数值、小数位数、可选区域设置（MySQL 8.0.17+），且返回字符串。
示例：
SELECT FORMAT(1234567.89, 2, 'zh_CN') AS money_zh;
输出：1,234,567.89（注意：它不自动加 ¥ 符号，得自己拼）
- 必须传小数位数，哪怕你想显示整数也要写
FORMAT(amount, 0) - 区域设置影响分组符和小数符，比如
'de_DE'会输出1.234.567,89 - 老版本 MySQL（REPLACE(CONVERT(...), '.', ',') 手动模拟，容易出错
PostgreSQL 没有 FORMAT，用 to_char() 更灵活也更易踩坑
PostgreSQL 用 to_char() 实现千分位，但它的模板字符串规则和 SQL Server 完全不同，新手常因符号写错得到空值或报错。
正确写法：
SELECT to_char(price, 'L999G999G999D00') FROM sales;
其中：L 是本地货币符号（依赖 lc_monetary 设置），G 是千分位分隔符，D 是小数点，9 表示数字占位符。
- 如果
price可能为 NULL，to_char(NULL, ...)返回空字符串，不是错误，但可能掩盖数据问题 - 模板长度必须大于实际数字位数，否则高位被截断（例如用
'999'格式化1000，结果是###） - 想固定显示 ¥，不能只靠
L，得设SET lc_monetary = 'zh_CN.UTF-8';，否则可能显示 $ 或空
跨数据库兼容方案：别依赖格式化函数，前端或应用层做更稳
真正需要“优雅展示”的场景，往往还涉及单位切换（¥ / $ / €）、汇率换算、负数括号表示等，这些逻辑塞进 SQL 里只会让语句臃肿难维护。
- 数据库只负责存原始数值（
DECIMAL(19,2)类型），保证精度和可计算性 - 把格式化逻辑下沉到 ORM（如 Python 的
babel.numbers.format_currency）或前端（Intl.NumberFormat） - 如果必须 SQL 输出，优先考虑
CAST+CONCAT等轻量操作，而非FORMAT类高开销函数
最常被忽略的一点：千分位只是视觉分隔，不影响数值比较或聚合。别为了“看起来整齐”牺牲查询语义清晰度和执行效率。
