Mybatis 傳參與排序模糊查詢功能實現(xiàn)

更新時間：2025年04月08日 14:54:25 作者：鴿鴿程序猿

這篇文章主要介紹了Mybatis 傳參與排序模糊查詢功能實現(xiàn),本文通過實例代碼給大家介紹的非常詳細(xì),感興趣的朋友跟隨小編一起看看吧

一、#{ }和${ }傳參的區(qū)別

我們先來看一下，使用兩個方式傳遞Integer的日志上的不同。

我們可以看見使用#{ }傳參的參數(shù)沒有在后?拼接，id的值是使? ? 進(jìn)?占位. 這種SQL 我們稱之為"預(yù)編譯SQL" 。而使用${ } 傳參的參數(shù)直接在后?拼接，這種SQL 我們稱之為"即時SQL" 。
并且當(dāng)我們使用${ ]傳String類型的參數(shù)的時候，我們跟#{ }使用同樣方式會報錯。

這個原因是因為${ }傳參是直接拼接，導(dǎo)致我們SQL語句傳參是字符串時參數(shù)沒有用引號括起來，語法直接報錯了。我們使用${ }傳字符串要加引號。

    @Select("select * from user_info where username = '${userName}' and password = '${password}'")
    List<UserInfo> selectUsernameAndPassWord(String userName, String password) ;

即時SQL與預(yù)編譯SQL區(qū)別：

一條SQL的執(zhí)行流程如下：

解析語法和語義, 校驗SQL語句是否正確
優(yōu)化SQL語句, 制定執(zhí)?計劃
執(zhí)?并返回結(jié)果

預(yù)編譯SQL就可以當(dāng)執(zhí)行相同SQL語句，只是參數(shù)不同時，不用執(zhí)行第1步和第2步。編譯?次之后會將編譯后的SQL語句緩存起來，后?再次執(zhí)?這條語句時，不會再次編譯。

#{ }與${ }區(qū)別：

#{ }由于是預(yù)編譯SQL的原因性能更高一些。
#{ }還能防止SQL注入的安全問題。

SQL注?：是通過操作輸?的數(shù)據(jù)來修改事先定義好的SQL語句，以達(dá)到執(zhí)?代碼對服務(wù)器進(jìn)?攻擊的?法。
由于沒有對??輸?進(jìn)?充分檢查，?SQL?是拼接?成，在??輸?參數(shù)時，在參數(shù)中添加?些SQL關(guān)鍵字，達(dá)到改變SQL運?結(jié)果的?的，也可以完成惡意攻擊。

--這條SQL語句就有SQL注入的問題
select username, `password`, age, gender, phone from user_info where 
password = ''or 1 ='1'

二、排序

我們將排序的方式作為參數(shù)傳遞，用戶選擇升序還是降序。

@Select("select * from user_info order by id #{order}")
    List<UserInfo> selectAllSort(String order) ;

測試方法：

    @Test
    void selectAllSort() {
        System.out.println(userMapper.selectAllSort("desc"));
    }

向上面這樣使用#{ }傳參會報錯：會解析SQL語句為select * from user_info order by id ‘desc’

我們在這種情況下只能使用${ }傳參。但是又要防止SQL注入的風(fēng)險。由于排序只有desc和asc兩種選項，我們在后端寫好校驗，防止SQL注入。

    @Select("select * from user_info order by id ${order}")
    List<UserInfo> selectAllSort(String order) ;

三、like查詢

@Select("select * from user_info where username like '%#{name}%' ")
    List<UserInfo> selectLike(String name) ;

也會報錯：解析為select * from user_info where username like ‘%'zhang'%'

我們這里不能使用${ }來解決，由于參數(shù)不是有限固定的，不能進(jìn)行校驗防止SQL注入。我們使用SQL的字符串拼接函數(shù)concat。

@Select("select * from user_info where username like concat('%', #{name} ,'%') ")
    List<UserInfo> selectLike(String name) ;

測試方法：

    @Test
    void selectLike() {
        userMapper.selectLike("zhang");
    }

結(jié)果：

四、數(shù)據(jù)庫連接池

數(shù)據(jù)庫連接池負(fù)責(zé)分配、管理和釋放數(shù)據(jù)庫連接，它允許應(yīng)?程序重復(fù)使??個現(xiàn)有的數(shù)據(jù)庫連接，?不是再重新建??個。

常?的數(shù)據(jù)庫連接池：C3P0 DBCP Druid Hikari ?前?較流?的是 Hikari, Druid。

Hikari是SpringBoot默認(rèn)使?的數(shù)據(jù)庫連接池。
果我們想把默認(rèn)的數(shù)據(jù)庫連接池切換為Druid數(shù)據(jù)庫連接池,只需要引?相關(guān)依賴即可。

--3.x版本
<dependency>
 <groupId>com.alibaba</groupId>
 <artifactId>druid-spring-boot-3-starter</artifactId>
 <version>1.2.21</version>
</dependency>
--2.x版本
<dependency>
 <groupId>com.alibaba</groupId>
 <artifactId>druid-spring-boot-starter</artifactId>
 <version>1.1.17</version>
</dependency>

五、MySQL 開發(fā)企業(yè)規(guī)范

表名, 字段名使??寫字?或數(shù)字, 單詞之間以下劃線分割. 盡量避免出現(xiàn)數(shù)字開頭或者兩個下劃線中間只出現(xiàn)數(shù)字.數(shù)據(jù)庫字段名的修改代價很?,所以字段名稱需要慎重考慮。

MySQL 在 Windows 下不區(qū)分??寫, 但在 Linux下默認(rèn)是區(qū)分??寫.因此,數(shù)據(jù)庫名,表名,字段名都不允許出現(xiàn)任何?寫字?, 避免節(jié)外?枝
正例： aliyun_admin，rdc_config， level3_name
反例： AliyunAdmin，rdcConfig，level_3_name

表必備三字段: id, create_time, update_time

id 必為主鍵, 類型為 bigint unsigned, 單表時?增, 步?為 1
create_time, update_time 的類型均為 datetime 類型, create_time表?創(chuàng)建時間,
update_time表?更新時間
有同等含義的字段即可, 字段名不做強制要求

在表查詢中, 避免使? * 作為查詢的字段列表, 標(biāo)明需要哪些字段.