问题小记-达梦数据库报错“字符串转换出错”处理

最近遇到一个达梦数据库报错“-6111: 字符串转换出错”的问题，这个问题主要是涉及到一条sql语句的执行，在此分享下这个报错的处理过程。

问题表现为：一样的表结构和数据，执行相同的SQL，在Oracle数据库中执行正常，到达梦数据库执行报错。

SQL语句大致如下：

sql">SELECT "START_VAL", "END_VAL"
FROM 
(SELECT FLOOR(C2 / 200000) * 200000 AS START_VAL, CEIL(C2 / 200000) * 200000 - 1 AS END_VALFROM T1WHERE C3 IN ('测试1', '测试2')GROUP BY FLOOR(C2 / 200000) * 200000, CEIL(C2 / 200000) * 200000 - 1
) 
WHERE START_VAL < END_VAL;

还有一个现象，如果把最后的条件“WHERE START_VAL < END_VAL”去掉，SQL就可以正常执行，结果如下图。

客户尝试过对SQL语句中C2列使用to_number和CAST函数做显示类型转换，仍然会报错。这里不做赘述。

其实既然涉及到字符串转换出错，那问题的表象就很明显了，一定是查询语句中对应列字段真的涉及到字符串转换才会出错，数据库不会凭空报错的。

这里根据当时最终排查的结果，人工构造一批测试数据来复现下当时的情况，然后看下当时的分析过程：

sql">--创建表
DROP TABLE IF EXISTS T1;
CREATE TABLE T1(C1 INT, C2 VARCHAR2(20), C3 VARCHAR2(50), C4 VARCHAR2(50),NOT CLUSTER PRIMARY KEY(C1));
--创建索引
CREATE INDEX IDX1 ON T1(C1 ASC,C3 ASC,C2 ASC);
--插入测试数据
DECLARE
BEGINFOR I IN 1..1000 LOOPIF (I >= 1 AND I <= 200) THENIF MOD(I, 3) = 0 THENINSERT INTO T1 VALUES(I, DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10));ELSEINSERT INTO T1 VALUES(I, ABS(FLOOR(DBMS_RANDOM.VALUE(1000000000, 9999999999))), '测试1', DBMS_RANDOM.STRING('X', 10));END IF;ELSEIF I IN (119,120,911,10086,12345,12315,12580,96577) THENINSERT INTO T1 VALUES(I, DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10));ELSEINSERT INTO T1 VALUES(I, ABS(FLOOR(DBMS_RANDOM.VALUE(1000000000, 9999999999))), '测试2', DBMS_RANDOM.STRING('X', 10));END IF;END IF;END LOOP;COMMIT;
END;
SELECT COUNT(*) FROM T1;  --共计1000条数据

注意：这里的表结构中只是本次模拟表结构随意创建的C1字段主键，实际业务场景中表字段很多，C1列也并不是主键，且表T1中包含C2和C3列的索引不止一条。表实际数据有几千万条，这里只做大致的问题模拟。

出现问题的SQL语句很简单，且只涉及到一张表，查询语句只涉及到T1表的两个字段列，分别为C2、C3，在SQL中能涉及到类型转换报错的，可以大胆判断是FLOOR和CEIL函数处理数据出现的问题。FLOOR和CEIL函数的功能如下：

这两个函数中的参数应该为数值类型才可以正常执行不报错

此时查看T1表结构，很明显，查询列C2是varchar2类型，SQL查询过程中会存在数据类型隐式转换。

通过几条SQL，来查看下数据，看看C2列数据是什么样的

先大致查询下全表数据

sql">SELECT * FROM T1;   --查看全表数据

从上图可以得知，C2列是存在非纯数值类型的字符串的

根据过滤条件，查询下数据

sql">SELECT * FROM T1 WHERE C3 IN ('测试1', '测试2'); --根据条件查看全表数据

根据查询结果来看，应该都是纯数字。再次查询下条数

sql">SELECT COUNT(*) FROM T1 WHERE C3 IN ('测试1', '测试2');  --933

一共有933行

验证下C2列是否全为数值类型

sql">SELECT COUNT(*) FROM T1 WHERE C3 IN ('测试1', '测试2') AND ISNUMERIC((C2)); --933

确认根据条件过滤后，都是数值类型，这时候使用FLOOR和CEIL理论上来说，并不应该出问题。

此时可以推测，是查询到了过滤条件“('测试1', '测试2')”之外的C2列数据，这种情况下使用FLOOR和CEIL函数一定会出现报错。如果是这种情况，就不得不看下达梦的SQL执行计划了，大概率是没有对条件提前进行过滤。执行计划如下：

sql">1   #NSET2: [2, 1, 144] 
2     #PRJT2: [2, 1, 144]; exp_num(2), is_atom(FALSE) 
3       #PRJT2: [2, 1, 144]; exp_num(2), is_atom(FALSE) 
4         #HAGR2: [2, 1, 144]; grp_num(2), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889195957.TMPCOL0, DMTEMPVIEW_889195957.TMPCOL1) 
5           #PRJT2: [1, 2, 144]; exp_num(2), is_atom(FALSE) 
6             #HASH RIGHT SEMI JOIN2: [1, 2, 144]; n_keys(1) KEY(DMTEMPVIEW_889195959.colname=T1.C3) KEY_NULL_EQU(0)
7               #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
8               #SLCT2: [1, 50, 96]; exp11*var5 < exp11*var5-var6
9                 #SSCN: [1, 50, 96]; IDX1(T1); btr_scan(1); is_global(0)

分析以上的执行计划，执行顺序大致如下：

1、SQL执行过程中，先走了索引IDX1，直接对这个二级索引IDX进行扫描，

2、通过FLOOR和CEIL两个函数计算相关结果，并根据最外层条件带入进行过滤。

3、CONST VALUE LIST常量列表放的是查询条件C3的两个参数值'测试1'和'测试2'

4、将常量列表与第2步中过滤后的结果做HASH RIGHT SEMI JOIN

5、PRJT2获取第4步的join结果

6、HASH分组，并计算集函数

7、PRJT2获取第6步分组后的结果，至此最内层子查询已结束

8、PRJT2最外层查询结果

9、结果集输出

计划中涉及到的索引定义如下：

sql">CREATE INDEX IDX1 ON T1(C1 ASC,C3 ASC,C2 ASC);

该索引包含了查询列和where条件列。

根据执行计划和索引定义，其实问题已经很明显了。情况和预料的一样，条件列C3的值并没有提前过滤，IDX的SSCN是包含那些不是纯数值类型的字符串的，此时用函数FLOOR和CEIL来处理数据就会报错。

那么为什么去掉最外层的where子句后，查询正常呢。让我们看下去掉“WHERE START_VAL < END_VAL”之后的执行计划

sql">1   #NSET2: [2, 1, 144] 
2     #PRJT2: [2, 1, 144]; exp_num(2), is_atom(FALSE) 
3       #PRJT2: [2, 1, 144]; exp_num(2), is_atom(FALSE) 
4         #HAGR2: [2, 1, 144]; grp_num(2), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889195968.TMPCOL0, DMTEMPVIEW_889195968.TMPCOL1) 
5           #PRJT2: [1, 50, 144]; exp_num(2), is_atom(FALSE) 
6             #HASH RIGHT SEMI JOIN2: [1, 50, 144]; n_keys(1) KEY(DMTEMPVIEW_889195970.colname=T1.C3) KEY_NULL_EQU(0)
7               #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
8               #SSCN: [1, 1000, 96]; IDX1(T1); btr_scan(1); is_global(0)

上边的计划，可以看到，虽然也走了索引IDX1，也是SSCN对这个二级索引IDX进行扫描，但是这里SSCN后，直接与CONST VALUE LIST常量列表做了HASH RIGHT SEMI JOIN，此时已经不存在非数值的字符串了，之后再做函数计算时就不会报错。

那么这条原始SQL，在Oracle中的执行计划是什么样的呢？Oracle的计划如下：

sql"> Plan Hash Value  : 4058097160 -------------------------------------------------------------------------
| Id  | Operation               | Name | Rows | Bytes | Cost | Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |      |   47 |   940 |    4 | 00:00:01 |
|   1 |   HASH GROUP BY         |      |   47 |   940 |    4 | 00:00:01 |
| * 2 |    INDEX FAST FULL SCAN | IDX1 |   47 |   940 |    3 | 00:00:01 |
-------------------------------------------------------------------------Predicate Information (identified by operation id):
------------------------------------------
* 2 - filter(("C3"='测试1' OR "C3"='测试2') AND FLOOR(TO_NUMBER("C2")/200000)*200000<CEIL(TO_NUMBER("C2")/200000)*200000-1)

上边Oracle的执行计划，可以看出来，Oracle在IDX SCAN的时候，做了C3条件过滤，然后做了FLOOR和CEIL函数处理，所以Oracle执行没有问题。

根据对达梦SQL分析的情况，如果能够正常先根据C3过滤数据，再做FLOOR和CEIL就不会报错。

依照这种思路处理的方法其实有很多，比如

方法一：再创建一个C3和C2列的索引

sql">create index idx2 on T1(C3 ASC,C2 ASC);

执行计划如下：

sql">1   #NSET2: [1, 1, 96] 
2     #PRJT2: [1, 1, 96]; exp_num(2), is_atom(FALSE) 
3       #PRJT2: [1, 1, 96]; exp_num(2), is_atom(FALSE) 
4         #HAGR2: [1, 1, 96]; grp_num(2), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889196107.TMPCOL0, DMTEMPVIEW_889196107.TMPCOL1) 
5           #PRJT2: [1, 50, 96]; exp_num(2), is_atom(FALSE) 
6             #NEST LOOP INDEX JOIN2: [1, 50, 96] 
7               #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
8               #SLCT2: [1, 25, 96]; exp11*var5 < exp11*var5-var6
9                 #SSEK2: [1, 25, 96]; scan_type(ASC), IDX2(T1), scan_range[(DMTEMPVIEW_889196109.colname,min),(DMTEMPVIEW_889196109.colname,max)), is_global(0)

此时的计划中可以看到是SSEK2二级索引数据定位，是能够直接过滤掉C3列数据的，之后再做函数FLOOR和CEIL不会报错。SQL语句也能正常执行。

方法二：以上创建的索引，似乎有冗余之嫌，因为已存在的IDX1已包含了C2和C3列，如果能调整IDX1索引列顺序，不增加索引的情况下会更好，但这就需要根据实际业务需求判断是否可以如此操作了。

sql">CREATE OR REPLACE INDEX IDX1 ON T1(C3 ASC,C2 ASC,C1 ASC);

执行计划如下：

sql">1   #NSET2: [1, 1, 96] 
2     #PRJT2: [1, 1, 96]; exp_num(2), is_atom(FALSE) 
3       #PRJT2: [1, 1, 96]; exp_num(2), is_atom(FALSE) 
4         #HAGR2: [1, 1, 96]; grp_num(2), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889196261.TMPCOL0, DMTEMPVIEW_889196261.TMPCOL1) 
5           #PRJT2: [1, 50, 96]; exp_num(2), is_atom(FALSE) 
6             #NEST LOOP INDEX JOIN2: [1, 50, 96] 
7               #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
8               #SLCT2: [1, 25, 96]; exp11*var5 < exp11*var5-var6
9                 #SSEK2: [1, 25, 96]; scan_type(ASC), IDX1(T1), scan_range[(DMTEMPVIEW_889196263.colname,min,min),(DMTEMPVIEW_889196263.colname,max,max)), is_global(0)

此时的执行计划可以看到与方法一是相同的，问题同样得到解决。

方法三：改写SQL语句，这种方式不会额外创建索引，也不会改变原有索引的字段顺序，如果业务方便进行SQL改造，也是一种不错的解决办法，下边提供两种改写方法：

（1）通过使用窗口函数来避免 GROUP BY 子句的改写方法

sql">SELECT START_VAL, END_VAL
FROM
(SELECTFLOOR(C2 / 200000) * 200000 AS START_VAL,CEIL(C2 / 200000) * 200000 - 1 AS END_VAL,ROW_NUMBER() OVER (PARTITION BY FLOOR(C2 / 200000) * 200000 ORDER BY C2) AS RNFROM T1WHERE C3 IN ('测试1','测试2')
) AS SUBQUERY
WHERE RN = 1 AND START_VAL < END_VAL;

执行计划如下：

sql">1   #NSET2: [1, 2, 156] 
2     #PRJT2: [1, 2, 156]; exp_num(3), is_atom(FALSE) 
3       #SLCT2: [1, 2, 156]; (SUBQUERY.RN = var2 AND SUBQUERY.START_VAL < SUBQUERY.END_VAL)
4         #PRJT2: [1, 50, 156]; exp_num(4), is_atom(FALSE) 
5           #AFUN: [1, 50, 156]; afun_num(1); partition_num(1)[DMTEMPVIEW_889196575.TMPCOL1]; order_num(1)[DMTEMPVIEW_889196575.TMPCOL0]
6             #SORT3: [1, 50, 156]; key_num(2), partition_key_num(0), is_distinct(FALSE), top_flag(0), is_adaptive(0)
7               #PRJT2: [1, 50, 156]; exp_num(3), is_atom(FALSE) 
8                 #HASH2 INNER JOIN: [1, 50, 156];  KEY_NUM(1); KEY(DMTEMPVIEW_889196577.colname=T1.C3) KEY_NULL_EQU(0)
9                   #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
10                  #SSCN: [1, 1000, 108]; IDX1(T1); btr_scan(1); is_global(0)

上边的计划，与前文所述的去掉最外层where子句“START_VAL < END_VAL”条件类似。先做SSCN，再与CONST VALUE LIST关联过滤掉C3列的数据，不会出现“字符串类型转换出错”的异常。

（2）把SQL修改为inner join的方式

sql">SELECT A.START_VAL, B.END_VAL
FROM(SELECTFLOOR(C2 / 200000) * 200000 AS START_VALFROMT1WHERE C3 IN ('测试1','测试2')GROUP BY FLOOR(C2 / 200000) * 200000) AS A
INNER JOIN(SELECTCEIL(C2 / 200000) * 200000 - 1 AS END_VALFROMT1WHERE C3 IN ('测试1','测试2')GROUP BY CEIL(C2 / 200000) * 200000 - 1) AS B
ON A.START_VAL < B.END_VAL;

执行计划如下：

sql">1   #NSET2: [68, 1, 288] 
2     #PRJT2: [68, 1, 288]; exp_num(2), is_atom(FALSE) 
3       #SLCT2: [68, 1, 288]; A.START_VAL < B.END_VAL
4         #NEST LOOP INNER JOIN2: [68, 1, 288] 
5           #PRJT2: [2, 1, 144]; exp_num(1), is_atom(FALSE) 
6             #HAGR2: [2, 1, 144]; grp_num(1), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889196622.TMPCOL0) 
7               #PRJT2: [1, 50, 144]; exp_num(1), is_atom(FALSE) 
8                 #HASH RIGHT SEMI JOIN2: [1, 50, 144]; n_keys(1) KEY(DMTEMPVIEW_889196625.colname=T1.C3) KEY_NULL_EQU(0)
9                   #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
10                  #SSCN: [1, 1000, 96]; IDX1(T1); btr_scan(1); is_global(0)
11          #PRJT2: [2, 1, 144]; exp_num(1), is_atom(FALSE) 
12            #HAGR2: [2, 1, 144]; grp_num(1), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889196623.TMPCOL0) 
13              #PRJT2: [1, 50, 144]; exp_num(1), is_atom(FALSE) 
14                #HASH RIGHT SEMI JOIN2: [1, 50, 144]; n_keys(1) KEY(DMTEMPVIEW_889196626.colname=T1.C3) KEY_NULL_EQU(0)
15                  #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
16                  #SSCN: [1, 1000, 96]; IDX1(T1); btr_scan(1); is_global(0)

上边的计划，与第一种改写方法类似。同样是先做SSCN，再与CONST VALUE LIST关联过滤掉C3列的数据，不会出现“字符串类型转换出错”的异常。这种方法是将START_VAL和END_VAL分别拆分为两张A、B表的字段，A表和B表进行inner join。当数据量很大时，执行计划就显得不那么好看了，预估代价会非常大，但还是以最终实际执行效率为准。

最终方案：由于客户SQL可改写，最终采取了改写的方案，尽量避免了改动原表的索引。但采取的是第二种方案inner join方式。本文开头构造表数据时曾提到，客户数据量很大，两个改写的SQL第二种inner join方式的执行计划预估代价非常高，但实际执行效率是最优的，比第一种改写方案快几倍。如果在第二种改写的SQL基础上加上并行hint，效率会更高。（注：第一种改写方式的SQL加并行hint执行效率基本不变）

因此最终确定SQL改写大致如下：

sql">SELECT /*+PARALLEL(4)*/ A.START_VAL, B.END_VAL
FROM(SELECTFLOOR(C2 / 200000) * 200000 AS START_VALFROMT1WHERE C3 IN ('测试1','测试2')GROUP BY FLOOR(C2 / 200000) * 200000) AS A
INNER JOIN(SELECTCEIL(C2 / 200000) * 200000 - 1 AS END_VALFROMT1WHERE C3 IN ('测试1','测试2')GROUP BY CEIL(C2 / 200000) * 200000 - 1) AS B
ON A.START_VAL < B.END_VAL;

总结：

1、在处理问题的过程中，思维要灵活，分析要细致，定位问题原因很重要。问题排错处理不能盲目进行，“‌东一榔头，西一棒子”的方式不可取，直击要害，循序渐进，才是解决问题之本。

2、达梦数据库使用过程中，数据库的优化器有待进一步改进，在实际使用过程中，需要不断人工调试，才能使业务系统保持在较好的运行状态。

问题小记-达梦数据库报错“字符串转换出错”处理

相关文章

使用Python探索量子机器学习

HarmonyOS NEXT 实战之元服务：静态案例效果（二）

云原生后端开发（一）

大数据新视界 -- Hive 数据生命周期管理：数据归档与删除策略（2 - 16 - 11）

C# 第二阶段 modbus

解决在vue3+vite+element-plus 中echarts在el-dialog无法正常显示问题

如何使用 WebAssembly 扩展后端应用

js创建对象的方式