SELECT数字显示科学计数法是客户端格式化行为，非数据库本身所致；根源在于float/real等近似类型或decimal精度设置不当，解决方案为先转DECIMAL再转VARCHAR，并在应用层锁定字符串类型防止二次格式化。
为什么SELECT出来的数字自动变成科学计数法？
这不是SQL Server或PostgreSQL“故意”显示成1.23456789E+07，而是客户端（比如SSMS、DBeaver、某些Python驱动）对高精度/大数值的默认格式化行为。数据库本身存的是精确数值，但展示时触发了浮点数或decimal精度溢出的自动缩写逻辑。关键判断点：如果字段类型是float、real或decimal(p,s)中p过大而s过小，就容易被渲染成科学计数法。
CAST和CONVERT都能转，但用哪个更稳？
在SQL Server里，CONVERT支持样式参数（比如日期格式），CAST更标准、跨库兼容性好；但两者对数值转字符串效果一致。重点不是选谁，而是**必须指定足够宽的目标字符串类型**——否则可能截断或仍触发科学表示：
-
CAST(num_col AS VARCHAR(10))→ 如果值超10位，会截断或报错 -
CONVERT(VARCHAR(20), num_col)→ 推荐至少留20位，覆盖整数部分+小数点+小数位 - 若原字段是
float，先转DECIMAL再转字符串更安全：CAST(CAST(num_col AS DECIMAL(18,6)) AS VARCHAR(20))
MySQL和PostgreSQL怎么处理？
MySQL没有CONVERT的样式功能，直接用CAST(col AS CHAR)即可，但要注意：CAST(123456789012345.67 AS CHAR)在旧版本可能仍返回科学计数法。稳妥做法是配合FORMAT()（MySQL 8.0+）：FORMAT(col, 2)，它强制返回带千分位和两位小数的字符串，且不走科学计数法。
PostgreSQL里，CAST(col AS TEXT)通常够用；但如果值来自double precision，建议先用ROUND(col, 6)再转，避免浮点误差导致末尾一堆9引发意外进位或显示异常。
应用层拿到结果后还变科学计数法，怎么办？
这是最常被忽略的一环：数据库返回的是正确字符串，但前端JS、Excel或Python pandas又自己重格式化了。比如pandas读取时把长数字列自动识别为float64，再输出就变1.23e+07。解决方式：
- SQL里加
CAST(col AS VARCHAR)并确保别名明确（如AS "amount_str"） - Python用
pd.read_sql(..., dtype={"amount_str": str})锁定列类型 - 导出CSV时，在Excel里右键单元格→设置单元格格式→文本，或前置单引号
'123456789
真正麻烦的从来不是SQL怎么写，而是数据离开数据库之后，在哪一层又被悄悄“优化”掉了精度。
