快捷導(dǎo)航

sql于navicat中能運(yùn)行在mybatis中不能運(yùn)行的解決方案

更新時(shí)間：2024年01月27日 10:30:58 作者：_0.78

這篇文章主要介紹了sql于navicat中能運(yùn)行在mybatis中不能運(yùn)行的解決方案,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教

其異常信息

如下：

org.mybatis.spring.MyBatisSystemException: nested exception is org.apache.ibatis.exceptions.PersistenceException:

Error querying database. Cause: com.baomidou.mybatisplus.core.exceptions.MybatisPlusException: Failed to process, please exclude the tableName or statementId.

在本條sql中，于navicat中是可以正常運(yùn)行的，但是在mybatisplus中是不可以正常使用的

SELECT
	claim_key,
	claim_no,
	occur_time,
	amnt,
	b_name,
	city_branch_code,
	town_branch_code,
	cntr_no,
	opsn_name,
	opsn_id_no,
	rcpt_amnt,
	occur_result_code,
	accept_clerk_code,
	accept_branch_no,
	proc_clerk_no,
	proc_clerk_branch,
	chk_clerk_no,
	pol_code,
	claim_date,
	close_date,
	accept_channel,
	hospital_name,
	occur_1cls_code,
	lp_extracted 
FROM
	compensation_case 
WHERE
	stamp & gt;= DATE_FORMAT( "2021-02-08 00:00:00", 'yyyy-MM-dd %H:%m:%s' ) 
AND stamp & lt;= DATE_FORMAT( "2023-02-08 00:00:00", 'yyyy-MM-dd %H:%m:%s' ) 
AND lp_extracted = 0 
AND claim_proc_stat = 'E' 
AND pol_code IN ( 'DDD', 'DDE', '975' ) = 0

后經(jīng)排查，有兩個(gè)解決方案

1、使用注解 @SqlParser(filter = true) 就可以解決問(wèn)題，其實(shí)現(xiàn)原理為略過(guò) mybatis plus的SQL解析過(guò)濾，直接執(zhí)行sql，這個(gè)效果跟在navicat執(zhí)行sql的效果是一樣的。

2、修改sql語(yǔ)句，將in () = 0 修改為 not in，這樣子的話就可以在mybatis plus中就可以正常運(yùn)行了。

其具體的出錯(cuò)原因還需要進(jìn)行debug查詢。

在debug的過(guò)程中，看到了mybatisplus的解析處理器中如下代碼：

public abstract class AbstractSqlParserHandler{
    /**
     * 攔截 SQL 解析執(zhí)行
     */
    protected void sqlParser(MetaObject metaObject) {
        //
        // @SqlParser(filter = true) 跳過(guò)該方法解析
        if (SqlParserHelper.getSqlParserInfo(metaObject)) {
            return;
        }
        //
    }
}

可以看到如果加上了@SqlParser(filter = true)注解的話，就會(huì)跳過(guò)SQL解析。

在底層sql解析中，可以看到sql在where解析的時(shí)候，拋出了異常，根據(jù)特殊符號(hào)進(jìn)行解析

net.sf.jsqlparser.parser.ParseException: Encountered unexpected token: "=" "="
    at line 33, column 51.

Was expecting one of:

    "&&"
    ";"
    "AND"
    "CONNECT"
    "EXCEPT"
    "FOR"
    "GROUP"
    "HAVING"
    "INTERSECT"
    "MINUS"
    "ORDER"
    "START"
    "UNION"
    <EOF>

特殊符號(hào)如下

"&&"
";"
"AND"
"CONNECT"
"EXCEPT"
"FOR"
"GROUP"
"HAVING"
"INTERSECT"
"MINUS"
"ORDER"
"START"
"UNION"

在解析sql的時(shí)候，對(duì)于如下sql是這么解析的

AND pol_code IN ( 'DDD', 'DDE', '975' ) = 0

根據(jù)IN解析之后，認(rèn)為下面這條SQL

AND pol_code IN ( 'DDD', 'DDE', '975' )

解析完成之后是一個(gè)完整的條件語(yǔ)句了。

那么這個(gè)條件語(yǔ)句它后面希望讀取到的字符會(huì)期望是特殊符號(hào)

"&&"
";"
"AND"
"CONNECT"
"EXCEPT"
"FOR"
"GROUP"
"HAVING"
"INTERSECT"
"MINUS"
"ORDER"
"START"
"UNION"

但是由于本條SQL在

AND pol_code IN ( 'DDD', 'DDE', '975' )

之后提供的是 =

即

AND pol_code IN ( 'DDD', 'DDE', '975' ) = 0

它不是mybatis plus所期望特俗字符中的其中一個(gè)，所以拋了異常，拋出異常的翻譯如下：

net.sf.jsqlparser.parser.ParseException: Encountered unexpected token: "=" "="
at line 33, column 51.

Was expecting one of:
"&&"
";"
"AND"
"CONNECT"
"EXCEPT"
"FOR"
"GROUP"
"HAVING"
"INTERSECT"
"MINUS"
"ORDER"
"START"
"UNION"
---------------------------------------------------------------------------------

在第 33 行第 51 列遇到意外標(biāo)記：“=”“=”。期待以下之一：
"&&"
";"
"AND"
"CONNECT"
"EXCEPT"
"FOR"
"GROUP"
"HAVING"
"INTERSECT"
"MINUS"
"ORDER"
"START"
"UNION"

故解決該問(wèn)題的辦法有三種：

1、添加注解@SqlParser(filter = true)，那么跳過(guò)mybatis的sql解析，直接就可以運(yùn)行sql語(yǔ)句；

2、修改sql，將sql的 in () = 0 修改為 not in ();

3、修改源碼。

綜合考慮，選擇第二種做法，將sql修改為如下

SELECT
	claim_key,
	claim_no,
	occur_time,
	amnt,
	b_name,
	city_branch_code,
	town_branch_code,
	cntr_no,
	opsn_name,
	opsn_id_no,
	rcpt_amnt,
	occur_result_code,
	accept_clerk_code,
	accept_branch_no,
	proc_clerk_no,
	proc_clerk_branch,
	chk_clerk_no,
	pol_code,
	claim_date,
	close_date,
	accept_channel,
	hospital_name,
	occur_1cls_code,
	lp_extracted 
FROM
	compensation_case 
WHERE
	stamp & gt;= DATE_FORMAT( "2021-02-08 00:00:00", 'yyyy-MM-dd %H:%m:%s' ) 
AND stamp & lt;= DATE_FORMAT( "2023-02-08 00:00:00", 'yyyy-MM-dd %H:%m:%s' ) 
AND lp_extracted = 0 
AND claim_proc_stat = 'E' 
AND pol_code NOT IN ( 'DDD', 'DDE', '975' )

修改之后重新運(yùn)行，SQL正常使用。