FORMAT 返回字符串，后续无法参与数值计算或排序；其结果受 locale 影响导致生产环境不一致；在大表聚合中可能因隐式转换引发精度丢失；应坚持数值处理与格式化分离，优先在应用层格式化。
FORMAT 返回字符串，后续无法参与数值计算或排序
这是最直接、最常踩的坑：你用 FORMAT(price, 2) 看起来输出是 '199.00'，但它在 MySQL 内部就是 VARCHAR，不是数字。一旦你把它放进 WHERE、ORDER BY 或 GROUP BY，MySQL 就会按字符串规则比较——比如 '1000.00' 居然为真，因为字符串比较从左到右逐字符比，<code>'1' 小于 '2'。
- 错误写法：
SELECT * FROM sales WHERE FORMAT(amount, 2) > '500.00'→ 实际执行的是字符串比较，结果不可信 - 正确做法：过滤/排序必须用原始字段，如
WHERE amount > 500 ORDER BY amount DESC - 如果非要带格式化再筛选，得先用子查询或 CTE 把数值逻辑做完，最后外层套
FORMAT
FORMAT 的返回值受 locale 影响，生产环境行为不一致
MySQL 默认用系统 locale 决定千分位符号和小数点——中文环境是 1,234.56，德语环境可能是 1.234,56（点作千分位，逗号作小数点）。你本地测试正常，上线后因服务器 locale 不同，API 返回突然变成 '1.234,56'，前端解析就崩了。
- 查当前 locale：
SELECT @@lc_time_names, @@collation_database - 临时改（仅会话级）：
SET lc_time_names = 'en_US';，但不能解决跨服务器部署问题 - 真正可控的方式：不用
FORMAT，改用ROUND(amount, 2)+ 应用层加千分位（Python 的format(x, ',.2f')或 JS 的toLocaleString()）
FORMAT 在大表聚合中可能引发隐式类型转换错误
典型翻车场景：SELECT FORMAT(SUM(amount), 2) AS total FROM orders。当 SUM(amount) 结果极大（比如超 DECIMAL(18,2) 范围），FORMAT 内部会先尝试转成浮点再格式化，导致精度丢失甚至显示为 '1'（曾实测真实总和 1619 显示为 1）。这不是四舍五入问题，是中间表示溢出。
- 安全替代：
SELECT CONCAT(ROUND(SUM(amount), 2), '.00')（若确定要两位小数） - 更稳做法：先用
CAST(SUM(amount) AS DECIMAL(18,2))固定精度，再ROUND，最后应用层加逗号 - 绝对避免在
SUM/AVG外直接套FORMAT，尤其涉及百万级以上行数时
真正需要 SQL 层统一格式化的场景极少；多数时候，把 FORMAT 当成「最终导出快照」的临时工具就行，别让它混进业务逻辑链路里——数值处理归数值，格式化归展示，边界不清最容易出 silent bug。
