针对你遇到的痛点——DB2里Double转Varchar时要么丢失末尾小数位、要么截断有效小数，导致正则校验误判，这里有两个无需硬编码数值范围的实用方案：

方案1：用CASE语句补全整数的小数位 #

核心思路是先判断数值是否为整数，如果是，就在转换后的字符串末尾追加.0，确保能匹配你的正则规则；非整数则直接转换，保留完整小数部分。同时用DECFLOAT避免Double的精度误差，保证整数判断准确：

SELECT column 
FROM table 
WHERE NOT REGEXP_LIKE(
    CASE 
        WHEN DECFLOAT(column) = FLOOR(DECFLOAT(column)) 
        THEN CAST(DECFLOAT(column) AS VARCHAR(25)) || '.0'
        ELSE CAST(DECFLOAT(column) AS VARCHAR(25))
    END, 
    '(\d{6}\.?\d{2})|(\d{7}\.?\d)'
)

这个方案完全不需要预设数值范围，能适配所有符合你正则要求的数值：

• 像1234567.0这类整数型Double，会被转为1234567.0，完美匹配正则的\d{7}\.?\d模式，不会被误判
• 像134567.89这类带两位小数的数值，会完整保留字符串形式，不匹配正则，被正确识别为非法值

方案2：用VARCHAR_FORMAT强制保留小数位 #

通过VARCHAR_FORMAT指定一个灵活的格式模型，既强制显示至少一位小数，又保留所有有效小数数字，无需限定整数范围：

SELECT column 
FROM table 
WHERE NOT REGEXP_LIKE(
    VARCHAR_FORMAT(DECFLOAT(column), '0.0###########'),
    '(\d{6}\.?\d{2})|(\d{7}\.?\d)'
)

格式模型0.0###########的作用：

• 开头的0确保整数部分正常显示（不会省略前导零，对你的6/7位整数数据无影响）
• .0强制显示至少一位小数，解决1234567.0被转为1234567的问题
• 后面的#表示可选小数位，最多支持11位，足够覆盖Double的精度，不会截断像134567.89这类有效小数

关键注意点 #

使用DECFLOAT转换是为了规避Double类型的精度误差——有些看起来是整数的Double值可能实际存储为近似值，DECFLOAT能更精准地处理这类数值的整数判断，避免误判。

内容的提问来源于stack exchange，提问作者sql_dummy