快捷導(dǎo)航

mybatis查詢SqlServer慢問題及解決

更新時(shí)間：2023年08月30日 16:35:31 作者：Ikarosxx

這篇文章主要介紹了mybatis查詢SqlServer慢問題及解決方案,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教

背景

項(xiàng)目中用到了mybatis連接SqlServer，但遇到了一些查詢慢的問題

問題1：一樣的sql，換一個(gè)日期執(zhí)行計(jì)劃不同

# 一樣的sql，djsj不同，第一條比第二條快很多
SELECT COUNT
	( 1 ) 
FROM
	e_ld2022 a WITH ( nolock )
	INNER JOIN m_user b ON b.MID = a.dbbh 
WHERE
	a.djsj = '2022-05-18 00:00:00' 
	AND a.TQBH LIKE '01%' 
	AND a.XMBH = 41;
SELECT COUNT
	( 1 ) 
FROM
	e_ld2022 a WITH ( nolock )
	INNER JOIN m_user b ON b.MID = a.dbbh 
WHERE
	a.djsj = '2022-05-19 00:00:00' 
	AND a.TQBH LIKE '01%' 
	AND a.XMBH = 41;

解決

通過MSSM分析執(zhí)行計(jì)劃，發(fā)現(xiàn)兩條查詢執(zhí)行計(jì)劃不一致，查詢慢的預(yù)估行數(shù)為1，走了LOOP，循環(huán)次數(shù)過多導(dǎo)致變慢

故懷疑是沒有更新統(tǒng)計(jì)信息，導(dǎo)致優(yōu)化器優(yōu)化失敗

# 更新統(tǒng)計(jì)信息
UPDATE STATISTICS databse.table;

執(zhí)行更新統(tǒng)計(jì)信息后重新查詢，正常。

問題2：#{}和${}導(dǎo)致查詢效率不同

mybatis中使用到了如下語句

select a.*,x.CBX from e_ld${year} a inner join E_XM x on x.XMBH = a.XMBH
<where>
	<if test="dbbh != null and dbbh !=''">
		AND dbbh LIKE concat(#{dbbh},'%')
	</if>
	<if test="tqbh != null and tqbh !=''">
		AND TQBH LIKE concat(#{tqbh},'%')
	</if>
</where>

經(jīng)過測(cè)試，只要條件增加了DBBH和TQBH，就是LIKE語句，查詢就巨慢

但一樣的SQL拎出來放到MSSM上執(zhí)行，就很快

解決

經(jīng)過偶然測(cè)試，發(fā)現(xiàn)如果使用AND TQBH LIKE '${tqbh}%'，就很快

說明問題出現(xiàn)在${}與#{}的區(qū)別上

以往的認(rèn)知上，只知道#{}就相當(dāng)于PreparedStatement，能夠防注入

${}可能出現(xiàn)注入風(fēng)險(xiǎn)

但不知道為啥這個(gè)會(huì)影響到查詢性能

跟了一下源碼，發(fā)現(xiàn)跟sendStringParametersAsUnicode和數(shù)據(jù)庫(kù)字段類型(VARCHAR、NVARCHAR)有關(guān)系

總結(jié)來說就是

sendStringParametersAsUnicode\字段類型	VARCHAR	NVARCHAR
true	×	√
false	√	×

分析

SendStringParametersAsUnicode文檔

SendStringParametersAsUnicode={true | false}.

Determines whether string parameters are sent to the SQL Server databasein Unicode or in the default character encoding of the database.

True means that string parameters are sent to SQL Serverin Unicode.

False means that they are sent in the default encoding, which can improve performance because the serverdoes not need to convert Unicode characters to the default encoding.

You should, however, use default encoding only if theparameter string data that you specify is consistent with the default encoding of the database.The default is true.

如果SendStringParametersAsUnicode=true，會(huì)將String參數(shù)用Unicode的編碼方式發(fā)送個(gè)服務(wù)器,即 JDBCType=NVARCHAR

如果SendStringParametersAsUnicode=false，會(huì)將String參數(shù)用默認(rèn)的方式發(fā)送給服務(wù)器，即 JDBCType=VARCHAR

我們系統(tǒng)里 SendStringParametersAsUnicode=false ，所以指定的 JdbcType=VARCHAR

但是數(shù)據(jù)庫(kù)字段是NVARCHAR，和我們指定的不一致，所以會(huì)發(fā)生轉(zhuǎn)換性能損耗，導(dǎo)致時(shí)間查詢慢

基于這個(gè)思路，我測(cè)試了一下

select a.*,x.CBX from e_ld${year} a inner join E_XM x on x.XMBH = a.XMBH
<where>
	<if test="dbbh != null and dbbh !=''">
		AND dbbh LIKE concat(#{dbbh, jdbcType=NVARCHAR},'%')
	</if>
	<if test="tqbh != null and tqbh !=''">
		AND TQBH LIKE concat(#{tqbh, jdbcType=NVARCHAR},'%')
	</if>
</where>

在mybatis xml中手動(dòng)指定參數(shù)的jdbcType和數(shù)據(jù)庫(kù)保持一致，和結(jié)論一樣，可以正常執(zhí)行，不會(huì)出現(xiàn)查詢慢的情況。