背景

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

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

# 一樣的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í)行計劃，發(fā)現(xiàn)兩條查詢執(zhí)行計劃不一致，查詢慢的預(yù)估行數(shù)為1，走了LOOP，循環(huán)次數(shù)過多導(dǎo)致變慢

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

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

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

問題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)過測試，只要條件增加了DBBH和TQBH，就是LIKE語句，查詢就巨慢

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

解決

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

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

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

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

但不知道為啥這個會影響到查詢性能

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

總結(jié)來說就是

分析

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，會將String參數(shù)用Unicode的編碼方式發(fā)送個服務(wù)器,即 JDBCType=NVARCHAR

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

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

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

基于這個思路，我測試了一下

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中手動指定參數(shù)的jdbcType和數(shù)據(jù)庫保持一致，和結(jié)論一樣，可以正常執(zhí)行，不會出現(xiàn)查詢慢的情況。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論