最近遇到一个达梦数据库报错“-6111: 字符串转换出错”的问题，这个问题主要是涉及到一条sql语句的执行，在此分享下这个报错的处理过程。
问题表现为：一样的表结构和数据，执行相同的SQL，在Oracle数据库中执行正常，到达梦数据库执行报错。
SQL语句大致如下：
SELECT "START_VAL", "END_VAL"
FROM
(
SELECT FLOOR(C2 / 200000) * 200000 AS START_VAL, CEIL(C2 / 200000) * 200000 - 1 AS END_VAL
FROM T1
WHERE 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函数做显示类型转换，仍然会报错。这里不做赘述。
其实既然涉及到字符串转换出错，那问题的表象就很明显了，一定是查询语句中对应列字段真的涉及到字符串转换才会出错，数据库不会凭空报错的。
这里根据当时最终排查的结果，人工构造一批测试数据来复现下当时的情况，然后看下当时的分析过程：
--创建表
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
BEGIN
FOR I IN 1..1000 LOOP
IF (I >= 1 AND I <= 200) THEN
IF MOD(I, 3) = 0 THEN
INSERT INTO T1 VALUES(I, DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10));
ELSE
INSERT INTO T1 VALUES(I, ABS(FLOOR(DBMS_RANDOM.VALUE(1000000000, 9999999999))), '测试1', DBMS_RANDOM.STRING('X', 10));
END IF;
ELSE
IF I IN (119,120,911,10086,12345,12315,12580,96577) THEN
INSERT INTO T1 VALUES(I, DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10));
ELSE
INSERT 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列数据是什么样的
先大致查询下全表数据
SELECT * FROM T1; --查看全表数据
从上图可以得知，C2列是存在非纯数值类型的字符串的
根据过滤条件，查询下数据
SELECT * FROM T1 WHERE C3 IN ('测试1', '测试2'); --根据条件查看全表数据
根据查询结果来看，应该都是纯数字。再次查询下条数
SELECT COUNT(*) FROM T1 WHERE C3 IN ('测试1', '测试2'); --933
一共有933行
验证下C2列是否全为数值类型
SELECT COUNT(*) FROM T1 WHERE C3 IN ('测试1', '测试2') AND ISNUMERIC((C2)); --933
确认根据条件过滤后，都是数值类型，这时候使用FLOOR和CEIL理论上来说，并不应该出问题。
此时可以推测，是查询到了过滤条件“('测试1', '测试2')”之外的C2列数据，这种情况下使用FLOOR和CEIL函数一定会出现报错。如果是这种情况，就不得不看下达梦的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、结果集输出
计划中涉及到的索引定义如下：
CREATE INDEX IDX1 ON T1(C1 ASC,C3 ASC,C2 ASC);该索引包含了查询列和where条件列。
根据执行计划和索引定义，其实问题已经很明显了。情况和预料的一样，条件列C3的值并没有提前过滤，IDX的SSCN是包含那些不是纯数值类型的字符串的，此时用函数FLOOR和CEIL来处理数据就会报错。
那么为什么去掉最外层的where子句后，查询正常呢。让我们看下去掉“WHERE START_VAL < END_VAL”之后的执行计划
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的计划如下：
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列的索引
create index idx2 on T1(C3 ASC,C2 ASC);执行计划如下：
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索引列顺序，不增加索引的情况下会更好，但这就需要根据实际业务需求判断是否可以如此操作了。
CREATE OR REPLACE INDEX IDX1 ON T1(C3 ASC,C2 ASC,C1 ASC);执行计划如下：
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 子句的改写方法
SELECT START_VAL, END_VAL
FROM
(
SELECT
FLOOR(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 RN
FROM T1
WHERE C3 IN ('测试1','测试2')
) AS SUBQUERY
WHERE RN = 1 AND START_VAL < END_VAL;执行计划如下：
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的方式
SELECT A.START_VAL, B.END_VAL
FROM
(SELECT
FLOOR(C2 / 200000) * 200000 AS START_VAL
FROM
T1
WHERE C3 IN ('测试1','测试2')
GROUP BY FLOOR(C2 / 200000) * 200000) AS A
INNER JOIN
(SELECT
CEIL(C2 / 200000) * 200000 - 1 AS END_VAL
FROM
T1
WHERE C3 IN ('测试1','测试2')
GROUP BY CEIL(C2 / 200000) * 200000 - 1) AS B
ON A.START_VAL < B.END_VAL;执行计划如下：
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改写大致如下：
SELECT /*+PARALLEL(4)*/ A.START_VAL, B.END_VAL
FROM
(SELECT
FLOOR(C2 / 200000) * 200000 AS START_VAL
FROM
T1
WHERE C3 IN ('测试1','测试2')
GROUP BY FLOOR(C2 / 200000) * 200000) AS A
INNER JOIN
(SELECT
CEIL(C2 / 200000) * 200000 - 1 AS END_VAL
FROM
T1
WHERE C3 IN ('测试1','测试2')
GROUP BY CEIL(C2 / 200000) * 200000 - 1) AS B
ON A.START_VAL < B.END_VAL;总结：
1、在处理问题的过程中，思维要灵活，分析要细致，定位问题原因很重要。问题排错处理不能盲目进行，““东一榔头，西一棒子”的方式不可取，直击要害，循序渐进，才是解决问题之本。
2、达梦数据库使用过程中，数据库的优化器有待进一步改进，在实际使用过程中，需要不断人工调试，才能使业务系统保持在较好的运行状态。