點(diǎn)擊上方“Java基基”，選擇“設(shè)為星標(biāo)”

做積極的人，而不是積極廢人！

源碼精品專欄

?

• 中文詳細(xì)注釋的開(kāi)源項(xiàng)目

• RPC 框架 Dubbo 源碼解析

• 網(wǎng)絡(luò)應(yīng)用框架 Netty 源碼解析

• 消息中間件 RocketMQ 源碼解析

• 數(shù)據(jù)庫(kù)中間件 Sharding-JDBC 和 MyCAT 源碼解析

• 作業(yè)調(diào)度中間件 Elastic-Job 源碼解析

• 分布式事務(wù)中間件 TCC-Transaction 源碼解析

• Eureka 和 Hystrix 源碼解析

• Java 并發(fā)源碼

來(lái)源：http://t.cn/EiVxHRU

• 案例一：

• 案例二：

• 案例三：

• 案例四：

• 案例五：

• 案例六：

• 案例七：

• 優(yōu)缺點(diǎn)

  • 優(yōu)點(diǎn)：

  • 缺點(diǎn)：

• 總結(jié)：

---

大多數(shù)開(kāi)發(fā)者應(yīng)該都使用過(guò)Hibernate或者M(jìn)ybatis的框架，或多或少都踩過(guò)一些坑！
如在MyBatis/Ibatis中#和$的區(qū)別，#方式能夠很大程度防止sql注入，$方式無(wú)法防止Sql注入。所以，老司機(jī)?對(duì)新手說(shuō)，最好用#。簡(jiǎn)單的說(shuō)#{}是經(jīng)過(guò)預(yù)編譯的,是安全的,而

解決一些實(shí)際問(wèn)題。
如在執(zhí)行sql語(yǔ)句時(shí)你有時(shí)并不希望讓變量進(jìn)行處理，而是直接賦值執(zhí)行，這時(shí)就要用到(${ａ})了，在使用時(shí)還要這樣賦值 @Param(value="a") String a

如日期問(wèn)題：
可能會(huì)遇到日期格式的時(shí)間段問(wèn)題，當(dāng)數(shù)據(jù)庫(kù)的時(shí)間為DATE類型時(shí)，MyBatis的jdbcType應(yīng)該使用DATE
jdbcType=DATE，而不是使用jdbcType=TIMESTAMP

如在使用resultMap的時(shí)候，要把ID寫在第一行，否則的話，就會(huì)報(bào)錯(cuò)。

又如最近在做的項(xiàng)目，遇到myBatis的大坑，Mybatis一直報(bào)異常Java.lang.ArrayIndexOutOfBoundsException，于是開(kāi)始代碼查錯(cuò)，代碼中有存儲(chǔ)過(guò)程，然后開(kāi)發(fā)使用ROOT用戶執(zhí)行SQL跑出來(lái)的數(shù)據(jù)結(jié)果集是正常的，在測(cè)試環(huán)境程序運(yùn)行也正常，但是在正式環(huán)境就其他用戶不行，最后發(fā)現(xiàn)是因?yàn)閿?shù)據(jù)庫(kù)沒(méi)有給該用戶授權(quán)出了問(wèn)題。

案例一：

作為新手，在此記下剛踩的一個(gè)坑，(踩踩更健康= =踩過(guò)痛過(guò)才不會(huì)再次錯(cuò))，寫了一個(gè)sql語(yǔ)句用到兩張表，兩張表中有兩個(gè)字段名字是一樣的都是Time和Content，然后要查詢這兩張表的這兩個(gè)字段都要查出來(lái)放到一個(gè)dto中，dto如下圖所示，

sql語(yǔ)句如下，

然而運(yùn)行后卻發(fā)現(xiàn)后幾個(gè)在數(shù)據(jù)庫(kù)表里同名的字段取出來(lái)都是null，

但是放到數(shù)據(jù)庫(kù)那邊執(zhí)行是沒(méi)有取出空數(shù)據(jù)的，

真是苦惱= =，后來(lái)經(jīng)大神指點(diǎn)，sql語(yǔ)句查詢出來(lái)的這個(gè)字段名必須和dto的參數(shù)名一致，改成這樣就通過(guò)了，

數(shù)據(jù)都取出來(lái)了。。。。。。。。。。還記得在hibernate里用hql時(shí)放到dto里，select?new?dto名()參數(shù)順序和類型一致就可以取出來(lái)。。。這應(yīng)該算一個(gè)不同點(diǎn)吧，，感覺(jué)還是hql用起來(lái)舒服，，，求大神科普兩者的差別優(yōu)缺點(diǎn)

當(dāng)實(shí)體類中的屬性名和表中的字段名不一致時(shí)，使用MyBatis進(jìn)行查詢操作時(shí)無(wú)法查詢出相應(yīng)的結(jié)果的問(wèn)題，當(dāng)時(shí)上網(wǎng)查了很多才知道，看到的一個(gè)解決方法分享給大家，通過(guò)來(lái)映射字段名和實(shí)體類屬性名的一一對(duì)應(yīng)關(guān)系。這種方式是使用MyBatis提供的解決方式來(lái)解決字段名和屬性名的映射關(guān)系的！

案例二：

數(shù)據(jù)庫(kù)表使用了聯(lián)合主鍵，逆向生成的時(shí)候生成了兩個(gè)實(shí)體類?？雌饋?lái)別扭。但還是可以用。后來(lái)就先取消主鍵，生成完后再將主鍵加上。還有就是，tinyint本來(lái)以為用來(lái)表示比較小的整數(shù)，結(jié)果生成了布爾型的屬性。后來(lái)就表示是和否才用tinyint了。逆向生成的sql語(yǔ)句絕對(duì)不能人為改動(dòng)，否則再次生成的時(shí)候會(huì)重復(fù)生成。但是，盡管踩過(guò)坑，我還是覺(jué)得mybatis超級(jí)好用，比hibernate好多了。雖然hibernate我只試過(guò)一點(diǎn)之后就完全轉(zhuǎn)向了mybatis了。

案例三：

sum()和count()使用場(chǎng)景不對(duì)導(dǎo)致出錯(cuò)：

count()、count(1)、count(0)就是指絕對(duì)的行數(shù)，哪怕某行所有字段全部為null也會(huì)計(jì)算在內(nèi)。count(1)和count()相比，innodb來(lái)說(shuō)count(*)效率低。

如果count(列名)查詢出來(lái)的結(jié)果就是查出列名中不為null的行數(shù)；

sum(列名)對(duì)指定列名進(jìn)行求和

MyBatis把int類型的0處理成空串’’和mysql處理空串’’為0的問(wèn)題，在Mybatis的Mapper中整數(shù)類型條件該如何判斷？

當(dāng)數(shù)據(jù)庫(kù)字段類型是整數(shù)，如果參數(shù)變量為空字符串或者NULL，Mybatis會(huì)自動(dòng)將參數(shù)賦值0，所以如果要判斷整數(shù)參數(shù)的多種狀態(tài)在傳遞數(shù)值到Mapper之前就要判斷是否為空字符串和NULL并將相應(yīng)的狀態(tài)數(shù)值賦值給該參數(shù)，否則參數(shù)值等于空字符串、NULL和0得到的結(jié)果是一樣的。

一般情況下，涉及到int類型的操作的時(shí)候，在Service中會(huì)統(tǒng)一把數(shù)字類型先變成字符串類型，然后再傳遞到Mapper中操作。

時(shí)間戳的使用

在創(chuàng)建新記錄的時(shí)候把這個(gè)字段設(shè)置為當(dāng)前時(shí)間，但以后修改時(shí)，不再刷新它(可以給createtime使用這個(gè))：TIMESTAMP?DEFAULT?CURRENT_TIMESTAMP

在創(chuàng)建新記錄和修改現(xiàn)有記錄的時(shí)候都對(duì)這個(gè)數(shù)據(jù)列刷新(可以給update使用這個(gè))：

TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

在使用resultMap的時(shí)候，要把ID寫在第一行，否則的話，就會(huì)報(bào)錯(cuò)。

案例四：

XML轉(zhuǎn)義字符，如果直接寫就會(huì)報(bào)錯(cuò)，需要用左邊一列的轉(zhuǎn)義字符
< < 小于號(hào) > > 大于號(hào)
& & 和
' ' 單引號(hào)
" " 雙引號(hào)

案例五：

前幾天在項(xiàng)目中碰到，來(lái)說(shuō)下吧。大神可繞道。在使用selectOne查詢個(gè)數(shù)時(shí)，
如果你寫了resultType為Integer，然后在業(yè)務(wù)代碼中很自然的用一個(gè)變量int去接當(dāng)前這個(gè)方法的返回，如果按照你傳入的條件在數(shù)據(jù)庫(kù)中沒(méi)有找到相關(guān)的值，此時(shí)selectOne方法的返回值會(huì)是一個(gè)null，當(dāng)你使用Java的自動(dòng)拆箱機(jī)制的時(shí)候會(huì)報(bào)出一個(gè)無(wú)情的NPE。
原因：Java在自動(dòng)拆箱的時(shí)候會(huì)調(diào)用Integer類中的intValue方法，如果當(dāng)前對(duì)象為null，則拋出NPE。
因此，在接受的時(shí)候要判空，否則可能異常。

案例六：

多參數(shù)的使用

MyBatis的查詢或者更新中，如果需要多個(gè)參數(shù)有如下幾種辦法：

對(duì)象映射，建立一個(gè)Java對(duì)象，并作為接口的參數(shù)，對(duì)象的屬性可以直接使用#{屬性名}的方式訪問(wèn)；
Map, 參數(shù)為一個(gè)Map, key對(duì)于屬性名，value對(duì)于參數(shù)值，這個(gè)方法就是傳參數(shù)是需要建立一個(gè)Map的臨時(shí)對(duì)象
@param參數(shù)注解，在接口方法參數(shù)前加入?yún)?shù)名稱注解，這樣就可以直接在Mapper中通過(guò)參數(shù)名訪問(wèn)
通過(guò)序號(hào)訪問(wèn)，第一個(gè)參數(shù)#{0}或#{param1}, 第二個(gè)參數(shù)#{1}, #{param2}
MyBatis中時(shí)間字段的使用–返回
時(shí)間字段的返回目前筆者采用放回字符串的方式：
date_format(update_time,?‘%Y-%c-%d?%H:%i:%s’)?updatetime
采用MySQL的時(shí)間格式化方法。
或者放回Timestamp類型的數(shù)據(jù)，要求放回對(duì)象屬性參數(shù)為Timestamp.

MyBatis中時(shí)間字段的使用–參數(shù)
如果需要查詢一段時(shí)間范圍的數(shù)據(jù)時(shí)，可以通過(guò)以下動(dòng)態(tài)SQL的方式查詢數(shù)據(jù)：

and lbr.update_time > #{startTime}

and lbr.update_time < #{endTime, javaType=Date, jdbcType=TIMESTAMP}

對(duì)于的接口方法名稱如下：
… Date startTime, Date endTime…
我想這個(gè)方法會(huì)比通過(guò)格式轉(zhuǎn)換的效率要高一些

MyBatis中時(shí)間字段的使用–寫入
寫入可是直接寫入Timestamp的數(shù)據(jù)，需要描述一些寫入的jdbcType，如下：

{installTime, jdbcType=TIMESTAMP}

1.Mapper層參數(shù)為Map,由Service層負(fù)責(zé)重載。

Mapper由于機(jī)制的問(wèn)題，不能重載，參數(shù)一般設(shè)置成Map，但這樣會(huì)使參數(shù)變得模糊，如果想要使代碼變得清晰，可以通過(guò)service層來(lái)實(shí)現(xiàn)重載的目的，對(duì)外提供的Service層是重載的，但這些重載的Service方法其實(shí)是調(diào)同一個(gè)Mapper，只不過(guò)相應(yīng)的參數(shù)并不一致。

也許有人會(huì)想，為什么不在Service層也設(shè)置成Map呢？我個(gè)人是不推薦這么做的，雖然為了方便，我在之前的項(xiàng)目中也大量采用了這種方式，但很明顯會(huì)給日后的維護(hù)工作帶來(lái)麻煩。因?yàn)檫@么做會(huì)使你整個(gè)MVC都依賴于Map模型，這個(gè)模型其實(shí)是很不錯(cuò)的，方便搭框架，但存在一個(gè)問(wèn)題：僅僅看方法簽名，你不清楚Map中所擁有的參數(shù)個(gè)數(shù)、類型、每個(gè)參數(shù)代表的含義。

試想，你只對(duì)Service層變更，或者DAO層變更，你需要清楚整個(gè)流程中Map傳遞過(guò)來(lái)的參數(shù)，除非你注釋或者文檔良好，否則必須把每一層的代碼都了解清楚，你才知道傳遞了哪些參數(shù)。針對(duì)于簡(jiǎn)單MVC，那倒也還好，但如果層次復(fù)雜之后，代碼會(huì)變得異常復(fù)雜，而且如果我增加一個(gè)參數(shù)，需要把每一個(gè)層的注釋都添加上。相對(duì)于注釋，使用方法簽名來(lái)保證這種代碼可控性會(huì)來(lái)得更可行一些，因?yàn)樽⑨層锌赡苁沁^(guò)時(shí)的，但方法簽名一般不太可能是陳舊的。

2.盡量少用if?choose等語(yǔ)句，降低維護(hù)的難度。

Mybatis的配置SQL時(shí)，盡量少用if?choose?等標(biāo)簽，能用SQL實(shí)現(xiàn)判斷的盡量用SQL來(lái)判斷(CASE?WHEN?,DECODE等)，以便后期維護(hù)。否則，一旦SQL膨脹，超級(jí)惡心，如果需要調(diào)試Mybatis中的SQL，需要去除大量的判斷語(yǔ)句，非常麻煩。另一方面，大量的if判斷，會(huì)使生成的SQL中包含大量的空格，增加網(wǎng)絡(luò)傳輸?shù)臅r(shí)間，也不可取。

而且大量的if?choose語(yǔ)句，不可避免地，每次生成的SQL會(huì)不太一致，會(huì)導(dǎo)致ORACLE大量的硬解析，也不可取。
我們來(lái)看看這樣的SQL：

SELECT?*?

這樣的if判斷，其實(shí)是完全沒(méi)有必要的,我們可以很簡(jiǎn)單的采用DECODE來(lái)解決默認(rèn)值問(wèn)題：

SELECT?*?

當(dāng)然有人會(huì)想，引入CASE?WHEN,DECODE會(huì)導(dǎo)致需要ORACLE函數(shù)解析，會(huì)拖慢SQL執(zhí)行時(shí)間，有興趣的同學(xué)可以回去做一下測(cè)試，看看是否會(huì)有大的影響。就個(gè)人經(jīng)驗(yàn)而言，在我的開(kāi)發(fā)過(guò)程，沒(méi)有發(fā)現(xiàn)因?yàn)楹瘮?shù)解析導(dǎo)致SQL變慢的情形。影響SQL執(zhí)行效率的一般情況下是JOIN、ORDER?BY、DISTINCT、PARTITATION?BY等這些操作，這些操作一般與表結(jié)構(gòu)設(shè)計(jì)有很大的關(guān)聯(lián)。相對(duì)于這些的效率影響程度，函數(shù)解析對(duì)于SQL執(zhí)行速度影響應(yīng)該是可以忽略不計(jì)的。
另外一點(diǎn)，對(duì)于一些默認(rèn)值的賦值，像上面那條SQL，默認(rèn)成當(dāng)前日期什么的，其實(shí)可以完全提到Service層或Controller層做處理，在Mybatis中應(yīng)該要少用這些判斷。因?yàn)?#xff0c;這樣的話，很難做緩存處理。如果startdate為空，在SQL上使用動(dòng)態(tài)的SYSDATE，就無(wú)法確定緩存startdate日期的key應(yīng)該是什么了。所以參數(shù)最好在傳遞至Mybatis之前都處理好，這樣Mybatis層也能減少部分if?choose語(yǔ)句，同時(shí)也方便做緩存處理。

當(dāng)然不使用if?choose也并不是絕對(duì)的，有時(shí)候?yàn)榱藘?yōu)化SQL，不得不使用if來(lái)解決，比如說(shuō)LIKE語(yǔ)句，當(dāng)然一般不推薦使用LIKE，但如果存在使用的場(chǎng)景，盡可能在不需要使用時(shí)候去除LIKE，比如查詢文章標(biāo)題，以提高查詢效率。?最好的方式是使用lucence等搜索引擎來(lái)解決這種全文索引的問(wèn)題。

總的來(lái)說(shuō)，if與choose判斷分支是不可能完全去除的，但是推薦使用SQL原生的方式來(lái)解決一些動(dòng)態(tài)問(wèn)題，而不應(yīng)該完全依賴Mybatis來(lái)完成動(dòng)態(tài)分支的判斷，因?yàn)榕袛喾种н^(guò)于復(fù)雜，而且難以維護(hù)。

3.用XML注釋取代SQL注釋。

Mybatis中原SQL的注釋盡量不要保留，注釋會(huì)引發(fā)一些問(wèn)題，如果需要使用注釋，可以在XML中用來(lái)注釋，保證在生成的SQL中不會(huì)存在SQL注釋，從而降低問(wèn)題出現(xiàn)的可能性。這樣做還有一個(gè)好處，就是在IDE中可以很清楚的區(qū)分注釋與SQL。

現(xiàn)在來(lái)談?wù)勛⑨屢l(fā)的問(wèn)題，我做的一個(gè)項(xiàng)目中，分頁(yè)組件是基于Mybatis的，它會(huì)在你寫的SQL腳本外面再套一層SELECT?COUNT(*)?ROWNUM_?FROM?(….)?計(jì)算總記錄數(shù)，同時(shí)有另一個(gè)嵌套SELECT?*?FROM(…)?WHERE?ROWNUM?>?10?AND?RONNUM?

SELECT?*?

即使傳入的參數(shù)中存在對(duì)應(yīng)的參數(shù)，實(shí)際也不會(huì)產(chǎn)生效果，因?yàn)楹竺娴膬?nèi)容實(shí)際上是被完全注釋了。這種錯(cuò)誤，如果不經(jīng)過(guò)嚴(yán)格的測(cè)試，是很難發(fā)現(xiàn)的。一般情況下，XML注釋完全可以替代SQL注釋，因此這種行為應(yīng)該可以禁止掉。

4.盡可能使用`#{}`，而不是`${}`.

Mybatis中盡量不要使用${}，盡量這樣做很方便開(kāi)發(fā)，但是有一個(gè)問(wèn)題，就是大量使用會(huì)導(dǎo)致ORACLE的硬解析，拖慢數(shù)據(jù)庫(kù)性能，運(yùn)行越久，數(shù)據(jù)庫(kù)性能會(huì)越差。對(duì)于一般多個(gè)字符串IN的處理，可以參考如下的解決方案:http://www.myexception.cn/sql/849573.html，基本可以解決大部分${}.
關(guān)于${}，另一個(gè)誤用的地方就是LIKE，我這邊還有個(gè)案例：比如一些樹型菜單，節(jié)點(diǎn)會(huì)設(shè)計(jì)成'01','0101',用兩位節(jié)點(diǎn)來(lái)區(qū)分層級(jí)，這時(shí)候，如果需要查詢01節(jié)點(diǎn)下所有的節(jié)點(diǎn)，最簡(jiǎn)單的SQL便是:SELECT?*?FROM?TREE?WHERE?ID?LIKE?'01%',這種SQL其實(shí)無(wú)可厚非，因?yàn)樗材苡玫剿饕?#xff0c;所以不需要特別的處理，直接使用就行了。但如果是文章標(biāo)題，則需要額外注意了：SELECT?*?FROM?T_NEWS_TEXT?WHERE?TITLE?LIKE?'%OSC%'，這是怎么也不會(huì)用到索引的，上面說(shuō)了，最好采用全文檢索。但如果離不開(kāi)LIKE，就需要注意使用的方式：?ID?LIKE?#{ID}?||?'%'而不是ID?LIKE?'

有人覺(jué)得使用||會(huì)增加ORACLE處理的時(shí)間，我覺(jué)得不要把ORACLE看得太傻，雖然有時(shí)候確實(shí)非常傻，有空可以再總結(jié)ORACLE傻不垃圾的地方，但是稍加測(cè)試便知：這種串聯(lián)方式，對(duì)于整個(gè)SQL的解析執(zhí)行，應(yīng)該是微乎其微的。

當(dāng)然還有一些特殊情況是沒(méi)有辦法處理的，比如說(shuō)動(dòng)態(tài)注入列名、表名等。對(duì)于這些情況，則比較棘手，沒(méi)有找到比較方便的手段。由于這種情況出現(xiàn)的可能性會(huì)比較少，所以使用ID有人覺(jué)得使用∣∣會(huì)增加ORACLE處理的時(shí)間，我覺(jué)得不要把ORACLE看得太傻，雖然有時(shí)候確實(shí)非常傻，有空可以再總結(jié)ORACLE傻不垃圾的地方，但是稍加測(cè)試便知：這種串聯(lián)方式，對(duì)于整個(gè)SQL的解析執(zhí)行，應(yīng)該是微乎其微的。當(dāng)然還有一些特殊情況是沒(méi)有辦法處理的，比如說(shuō)動(dòng)態(tài)注入列名、表名等。對(duì)于這些情況，則比較棘手，沒(méi)有找到比較方便的手段。由于這種情況出現(xiàn)的可能性會(huì)比較少，所以使用{}倒也不至于有什么太大的影響。當(dāng)然你如果有代碼潔癖的話，可以使用ORACLE的動(dòng)態(tài)執(zhí)行SQL的機(jī)制Execute?immediate，這樣就可以完全避免${}出現(xiàn)的可能性了。這樣會(huì)引入比較復(fù)雜的模型，這個(gè)時(shí)候，你就需要取舍了。

針對(duì)于以上動(dòng)態(tài)SQL所導(dǎo)致的問(wèn)題，最激進(jìn)的方式是全部采用存儲(chǔ)過(guò)程，用數(shù)據(jù)庫(kù)原生的方式來(lái)解決，方便開(kāi)發(fā)調(diào)試，當(dāng)然也會(huì)帶來(lái)問(wèn)題：對(duì)開(kāi)發(fā)人員會(huì)有更高的要求、存儲(chǔ)過(guò)程的管理等等，我這邊項(xiàng)目沒(méi)有采用過(guò)這種方式，這里不做更多的展開(kāi)。

5.簡(jiǎn)單使用Mybatis。

Mybatis的功能相對(duì)而言還是比較弱的，缺少了好多必要的輔助庫(kù)，字符串處理等等，擴(kuò)展也比較困難，一般也就可能對(duì)返回值進(jìn)行一些處理。因此最好僅僅把它作為單純的SQL配置文件，以及簡(jiǎn)單的ORM框架。不要嘗試在Mybatis中做過(guò)多的動(dòng)態(tài)SQL，否則會(huì)導(dǎo)致后續(xù)的維護(hù)非常惡心。

幾點(diǎn)技巧總結(jié)；

1、查詢很多字段時(shí)可以提出來(lái)再引入到sql語(yǔ)句

提取：
id, type, shopCouId, Path, fromDate, toDate, insDate, insUserId, updDate, updUserId, delFlg

引入：
select
from adinfo
where id = #{id,jdbcType=INTEGER}

2、如果sql語(yǔ)句中需要使用, "" 符號(hào)時(shí)，需要使用< > " 或者

?CDATA內(nèi)部所有東西都會(huì)被解析器忽略
select?type,?shopCouId,?Path
from?adinfo
WHERE?delFlg?='0'

and?fromDate?#{date}?and?toDate?>=?#{date}

3、緩存使用

在增刪查改時(shí)，可以使用緩存屬性控制數(shù)據(jù)緩存

4、可以判斷傳進(jìn)來(lái)的參數(shù)，再進(jìn)行操作

and langCd = #{langCd,jdbcType=VARCHAR}

5、可以在sql語(yǔ)句中直接進(jìn)行加減乘除計(jì)算，模糊查詢時(shí)，需要注意使用方式

SELECT?

MyBatis把int類型的0處理成空串’’和mysql處理空串’’為0的問(wèn)題

NULL，Mybatis會(huì)自動(dòng)將參數(shù)賦值

案例七：

使用mybatis?進(jìn)行批量insert的時(shí)候?會(huì)自動(dòng)封裝成一個(gè)map?key是list?要存的數(shù)據(jù)變成了數(shù)組?需要注意在xml里面如果使用自己定義的collection要在傳參時(shí)定義一個(gè)mapkey是自己定義的變量名哦。

在使用resultMap的時(shí)候，要把ID寫在第一行，否則的話，就會(huì)報(bào)錯(cuò)。

優(yōu)缺點(diǎn)

總結(jié)下mybatis的優(yōu)缺點(diǎn)，以便大家對(duì)于mybatis的了解能更全面些。但我所說(shuō)的優(yōu)缺點(diǎn)，僅是我個(gè)人總結(jié)并結(jié)合使用體驗(yàn)后得出的結(jié)果，并不能代表大眾想法，因此才以“淺談”作為文章標(biāo)題。如果大家的見(jiàn)解與我不同，歡迎積極提出來(lái)一塊討論，我也借以彌補(bǔ)自己認(rèn)識(shí)的不足和短見(jiàn)。

優(yōu)點(diǎn)：

易于上手和掌握。

sql寫在xml里，便于統(tǒng)一管理和優(yōu)化。

解除sql與程序代碼的耦合。

提供映射標(biāo)簽，支持對(duì)象與數(shù)據(jù)庫(kù)的orm字段關(guān)系映射

提供對(duì)象關(guān)系映射標(biāo)簽，支持對(duì)象關(guān)系組建維護(hù)

提供xml標(biāo)簽，支持編寫動(dòng)態(tài)sql。

缺點(diǎn)：

sql工作量很大，尤其是字段多、關(guān)聯(lián)表多時(shí)，更是如此。

sql依賴于數(shù)據(jù)庫(kù)，導(dǎo)致數(shù)據(jù)庫(kù)移植性差。

由于xml里標(biāo)簽id必須唯一，導(dǎo)致DAO中方法不支持方法重載。

字段映射標(biāo)簽和對(duì)象關(guān)系映射標(biāo)簽僅僅是對(duì)映射關(guān)系的描述，具體實(shí)現(xiàn)仍然依賴于sql。(比如配置了一對(duì)多Collection標(biāo)簽，如果sql里沒(méi)有join子表或查詢子表的話，查詢后返回的對(duì)象是不具備對(duì)象關(guān)系的，即Collection的對(duì)象為null)

DAO層過(guò)于簡(jiǎn)單，對(duì)象組裝的工作量較大。

不支持級(jí)聯(lián)更新、級(jí)聯(lián)刪除。

編寫動(dòng)態(tài)sql時(shí),不方便調(diào)試，尤其邏輯復(fù)雜時(shí)。
8?提供的寫動(dòng)態(tài)sql的xml標(biāo)簽功能簡(jiǎn)單(連struts都比不上)，編寫動(dòng)態(tài)sql仍然受限，且可讀性低。

若不查詢主鍵字段，容易造成查詢出的對(duì)象有“覆蓋”現(xiàn)象。

參數(shù)的數(shù)據(jù)類型支持不完善。(如參數(shù)為Date類型時(shí)，容易報(bào)沒(méi)有g(shù)et、set方法，需在參數(shù)上加@param)

多參數(shù)時(shí)，使用不方便，功能不夠強(qiáng)大。(目前支持的方法有map、對(duì)象、注解@param以及默認(rèn)采用012索引位的方式)

緩存使用不當(dāng)，容易產(chǎn)生臟數(shù)據(jù)。

總結(jié)：

mybatis的優(yōu)點(diǎn)其實(shí)也是mybatis的缺點(diǎn)，正因?yàn)閙ybatis使用簡(jiǎn)單，數(shù)據(jù)的可靠性、完整性的瓶頸便更多依賴于程序員對(duì)sql的使用水平上了。sql寫在xml里，雖然方便了修改、優(yōu)化和統(tǒng)一瀏覽，但可讀性很低，調(diào)試也非常困難，也非常受限，無(wú)法像jdbc那樣在代碼里根據(jù)邏輯實(shí)現(xiàn)復(fù)雜動(dòng)態(tài)sql拼接。mybatis簡(jiǎn)單看就是提供了字段映射和對(duì)象關(guān)系映射的jdbc，省去了數(shù)據(jù)賦值到對(duì)象的步驟而已，除此以外并無(wú)太多作為，不要把它想象成hibernate那樣強(qiáng)大，簡(jiǎn)單小巧易用上手，方便瀏覽修改sql就是它最大的優(yōu)點(diǎn)了。
mybatis適用于小型且程序員能力較低的項(xiàng)目和人群使用，對(duì)于中大型項(xiàng)目來(lái)說(shuō)我并不推薦使用，如果覺(jué)得hibernate效率低的話(實(shí)際上也是使用不當(dāng)所致，hibernate是實(shí)際上是不適用于擁有高負(fù)載的工程項(xiàng)目)，還不如直接用spring提供的jdbc簡(jiǎn)單框架(Template)，同樣支持對(duì)象映射。

---

---

歡迎加入我的知識(shí)星球，一起探討架構(gòu)，交流源碼。加入方式，長(zhǎng)按下方二維碼噢：

已在知識(shí)星球更新源碼解析如下：

如果你喜歡這篇文章，喜歡，轉(zhuǎn)發(fā)。

生活很美好，明天見(jiàn)(｡･ω･｡)ﾉ?

總結(jié)

以上是生活随笔為你收集整理的mybatis 查询的时间不对_程序员，Mybatis 你踩过坑吗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。