來源：https://yq.aliyun.com/roundtable/49835
大多數(shù)開發(fā)者應(yīng)該都使用過Hibernate或者Mybatis的框架玛荞，或多或少都踩過一些坑娇掏！
如在MyBatis/Ibatis中#和$的區(qū)別，#方式能夠很大程度防止sql注入勋眯，$方式無法防止Sql注入婴梧。所以，老司機對新手說客蹋，最好用#塞蹭。簡單的說#{}是經(jīng)過預(yù)編譯的是安全的,而是未經(jīng)過編譯的，僅僅是取變量的值讶坯，是非安全的番电，存在sql注入。
有些特例是需要關(guān)注的辆琅，有的時候需要解決一些實際問題漱办。
如在執(zhí)行sql語句時你有時并不希望讓變量進行處理，而是直接賦值執(zhí)行婉烟，這時就要用到(${ａ})了洼冻，在使用時還要這樣賦值：
@Param(value="a") String a
如日期問題：
可能會遇到日期格式的時間段問題，當數(shù)據(jù)庫的時間為DATE類型時隅很，MyBatis的jdbcType應(yīng)該使用：
DATE jdbcType=DATE撞牢，
而不是使用：
jdbcType=TIMESTAMP。
如在使用resultMap的時候叔营，要把ID寫在第一行屋彪，否則的話，就會報錯绒尊。
又如最近在做的項目畜挥，遇到myBatis的大坑，Mybatis一直報異常：
Java.lang.ArrayIndexOutOfBoundsException婴谱，
于是開始代碼查錯蟹但，代碼中有存儲過程躯泰，然后開發(fā)使用ROOT用戶執(zhí)行SQL跑出來的數(shù)據(jù)結(jié)果集是正常的，在測試環(huán)境程序運行也正常华糖，但是在正式環(huán)境就其他用戶不行麦向，最后發(fā)現(xiàn)是因為數(shù)據(jù)庫沒有給該用戶授權(quán)出了問題。
案例一：
作為新手客叉，在此記下剛踩的一個坑诵竭，（踩踩更健康= =踩過痛過才不會再次錯），寫了一個sql語句用到兩張表兼搏，兩張表中有兩個字段名字是一樣的都是Time和Content卵慰，然后要查詢這兩張表的這兩個字段都要查出來放到一個dto中，dto如下圖所示佛呻，
sql語句如下裳朋，
然而運行后卻發(fā)現(xiàn)后幾個在數(shù)據(jù)庫表里同名的字段取出來都是null，
但是放到數(shù)據(jù)庫那邊執(zhí)行是沒有取出空數(shù)據(jù)的吓著，
真是苦惱= =鲤嫡，后來經(jīng)大神指點，sql語句查詢出來的這個字段名必須和dto的參數(shù)名一致夜矗，改成這樣就通過了泛范，
數(shù)據(jù)都取出來了让虐。紊撕。。赡突。对扶。。惭缰。浪南。。漱受。還記得在hibernate里用hql時放到dto里络凿，select new dto名（）參數(shù)順序和類型一致就可以取出來。昂羡。絮记。這應(yīng)該算一個不同點吧，虐先，感覺還是hql用起來舒服怨愤，，蛹批，求大神科普兩者的差別優(yōu)缺點
當實體類中的屬性名和表中的字段名不一致時撰洗，使用MyBatis進行查詢操作時無法查詢出相應(yīng)的結(jié)果的問題篮愉，當時上網(wǎng)查了很多才知道，看到的一個解決方法分享給大家差导，通過來映射字段名和實體類屬性名的一一對應(yīng)關(guān)系试躏。這種方式是使用MyBatis提供的解決方式來解決字段名和屬性名的映射關(guān)系的！
案例二：
數(shù)據(jù)庫表使用了聯(lián)合主鍵柿汛，逆向生成的時候生成了兩個實體類冗酿。看起來別扭络断。但還是可以用裁替。后來就先取消主鍵，生成完后再將主鍵加上貌笨。還有就是弱判，tinyint本來以為用來表示比較小的整數(shù)，結(jié)果生成了布爾型的屬性锥惋。后來就表示是和否才用tinyint了昌腰。逆向生成的sql語句絕對不能人為改動，否則再次生成的時候會重復(fù)生成膀跌。但是遭商，盡管踩過坑，我還是覺得mybatis超級好用捅伤，比hibernate好多了劫流。雖然hibernate我只試過一點之后就完全轉(zhuǎn)向了mybatis了。
案例三：
sum()和count()使用場景不對導(dǎo)致出錯：
count()丛忆、count(1)祠汇、count(0)就是指絕對的行數(shù)，哪怕某行所有字段全部為null也會計算在內(nèi)熄诡。count(1)和count()相比可很，innodb來說count(*)效率低。
如果count(列名)查詢出來的結(jié)果就是查出列名中不為null的行數(shù)凰浮；
sum(列名)對指定列名進行求和
MyBatis把int類型的0處理成空串’’和mysql處理空串’’為0的問題我抠，在Mybatis的Mapper中整數(shù)類型條件該如何判斷？
當數(shù)據(jù)庫字段類型是整數(shù)袜茧，如果參數(shù)變量為空字符串或者NULL菜拓，Mybatis會自動將參數(shù)賦值0，所以如果要判斷整數(shù)參數(shù)的多種狀態(tài)在傳遞數(shù)值到Mapper之前就要判斷是否為空字符串和NULL并將相應(yīng)的狀態(tài)數(shù)值賦值給該參數(shù)惫周，否則參數(shù)值等于空字符串尘惧、NULL和0得到的結(jié)果是一樣的。
一般情況下递递，涉及到int類型的操作的時候喷橙，在Service中會統(tǒng)一把數(shù)字類型先變成字符串類型啥么，然后再傳遞到Mapper中操作。
時間戳的使用
在創(chuàng)建新記錄的時候把這個字段設(shè)置為當前時間贰逾，但以后修改時悬荣，不再刷新它(可以給createtime使用這個)：
TIMESTAMP DEFAULT CURRENT_TIMESTAMP
在創(chuàng)建新記錄和修改現(xiàn)有記錄的時候都對這個數(shù)據(jù)列刷新(可以給update使用這個)：
TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
在使用resultMap的時候，要把ID寫在第一行疙剑，否則的話氯迂，就會報錯。
案例四：
XML轉(zhuǎn)義字符言缤，如果直接寫就會報錯嚼蚀，需要用左邊一列的轉(zhuǎn)義字符
< < 小于號 > > 大于號
& & 和
' ' 單引號
" " 雙引號
案例五：
前幾天在項目中碰到，來說下吧管挟。大神可繞道轿曙。在使用selectOne查詢個數(shù)時，
如果你寫了resultType為Integer僻孝，然后在業(yè)務(wù)代碼中很自然的用一個變量int去接當前這個方法的返回导帝，如果按照你傳入的條件在數(shù)據(jù)庫中沒有找到相關(guān)的值，此時selectOne方法的返回值會是一個null穿铆，當你使用Java的自動拆箱機制的時候會報出一個無情的NPE您单。
原因：Java在自動拆箱的時候會調(diào)用Integer類中的intValue方法，如果當前對象為null荞雏，則拋出NPE虐秦。
因此，在接受的時候要判空讯檐，否則可能異常羡疗。
案例六：
多參數(shù)的使用
MyBatis的查詢或者更新中染服，如果需要多個參數(shù)有如下幾種辦法：
對象映射别洪，建立一個Java對象，并作為接口的參數(shù)柳刮，對象的屬性可以直接使用#{屬性名}的方式訪問挖垛；
Map, 參數(shù)為一個Map, key對于屬性名，value對于參數(shù)值秉颗，這個方法就是傳參數(shù)是需要建立一個Map的臨時對象
@param參數(shù)注解痢毒，在接口方法參數(shù)前加入?yún)?shù)名稱注解，這樣就可以直接在Mapper中通過參數(shù)名訪問
通過序號訪問蚕甥，第一個參數(shù)#{0}或#{param1}, 第二個參數(shù)#{1}, #{param2}
MyBatis中時間字段的使用–返回
時間字段的返回目前筆者采用放回字符串的方式：
date_format(update_time, ‘%Y-%c-%d %H:%i:%s’) updatetime
采用MySQL的時間格式化方法哪替。
或者放回Timestamp類型的數(shù)據(jù)，要求放回對象屬性參數(shù)為Timestamp.
MyBatis中時間字段的使用–參數(shù)
如果需要查詢一段時間范圍的數(shù)據(jù)時菇怀，可以通過以下動態(tài)SQL的方式查詢數(shù)據(jù)：
and lbr.update_time > #{startTime}
and lbr.update_time < #{endTime, javaType=Date, jdbcType=TIMESTAMP}
對于的接口方法名稱如下：
… Date startTime, Date endTime…
我想這個方法會比通過格式轉(zhuǎn)換的效率要高一些
MyBatis中時間字段的使用–寫入
寫入可是直接寫入Timestamp的數(shù)據(jù)凭舶，需要描述一些寫入的jdbcType晌块，如下：
{installTime, jdbcType=TIMESTAMP}
1、Mapper層參數(shù)為Map,由Service層負責重載帅霜。
Mapper由于機制的問題匆背，不能重載，參數(shù)一般設(shè)置成Map身冀，但這樣會使參數(shù)變得模糊钝尸，如果想要使代碼變得清晰，可以通過service層來實現(xiàn)重載的目的搂根，對外提供的Service層是重載的珍促，但這些重載的Service方法其實是調(diào)同一個Mapper，只不過相應(yīng)的參數(shù)并不一致剩愧。
也許有人會想踢星，為什么不在Service層也設(shè)置成Map呢？我個人是不推薦這么做的隙咸，雖然為了方便沐悦，我在之前的項目中也大量采用了這種方式，但很明顯會給日后的維護工作帶來麻煩五督。因為這么做會使你整個MVC都依賴于Map模型藏否，這個模型其實是很不錯的，方便搭框架充包，但存在一個問題：僅僅看方法簽名副签，你不清楚Map中所擁有的參數(shù)個數(shù)、類型基矮、每個參數(shù)代表的含義淆储。
試想，你只對Service層變更家浇，或者DAO層變更本砰，你需要清楚整個流程中Map傳遞過來的參數(shù)，除非你注釋或者文檔良好钢悲，否則必須把每一層的代碼都了解清楚点额，你才知道傳遞了哪些參數(shù)。針對于簡單MVC莺琳，那倒也還好还棱，但如果層次復(fù)雜之后，代碼會變得異常復(fù)雜惭等，而且如果我增加一個參數(shù)珍手，需要把每一個層的注釋都添加上。相對于注釋，使用方法簽名來保證這種代碼可控性會來得更可行一些琳要，因為注釋有可能是過時的料扰，但方法簽名一般不太可能是陳舊的。
2焙蹭、盡量少用if choose等語句晒杈，降低維護的難度。
Mybatis的配置SQL時孔厉，盡量少用if choose 等標簽拯钻，能用SQL實現(xiàn)判斷的盡量用SQL來判斷(CASE WHEN ,DECODE等)，以便后期維護撰豺。否則粪般，一旦SQL膨脹，超級惡心污桦，如果需要調(diào)試Mybatis中的SQL亩歹，需要去除大量的判斷語句，非常麻煩凡橱。另一方面小作，大量的if判斷，會使生成的SQL中包含大量的空格稼钩，增加網(wǎng)絡(luò)傳輸?shù)臅r間顾稀，也不可取。
而且大量的if choose語句坝撑，不可避免地静秆，每次生成的SQL會不太一致，會導(dǎo)致ORACLE大量的硬解析巡李，也不可取抚笔。
我們來看看這樣的SQL：
這樣的if判斷，其實是完全沒有必要的,我們可以很簡單的采用DECODE來解決默認值問題：
當然有人會想侨拦，引入CASE WHEN,DECODE會導(dǎo)致需要ORACLE函數(shù)解析殊橙，會拖慢SQL執(zhí)行時間，有興趣的同學(xué)可以回去做一下測試阳谍，看看是否會有大的影響蛀柴。就個人經(jīng)驗而言螃概，在我的開發(fā)過程矫夯，沒有發(fā)現(xiàn)因為函數(shù)解析導(dǎo)致SQL變慢的情形。影響SQL執(zhí)行效率的一般情況下是JOIN吊洼、ORDER BY训貌、DISTINCT、PARTITATION BY等這些操作，這些操作一般與表結(jié)構(gòu)設(shè)計有很大的關(guān)聯(lián)递沪。相對于這些的效率影響程度豺鼻，函數(shù)解析對于SQL執(zhí)行速度影響應(yīng)該是可以忽略不計的。
另外一點款慨，對于一些默認值的賦值儒飒，像上面那條SQL，默認成當前日期什么的檩奠，其實可以完全提到Service層或Controller層做處理桩了，在Mybatis中應(yīng)該要少用這些判斷。因為埠戳，這樣的話井誉，很難做緩存處理。如果startdate為空整胃，在SQL上使用動態(tài)的SYSDATE颗圣，就無法確定緩存startdate日期的key應(yīng)該是什么了。所以參數(shù)最好在傳遞至Mybatis之前都處理好屁使，這樣Mybatis層也能減少部分if choose語句在岂，同時也方便做緩存處理。
當然不使用if choose也并不是絕對的蛮寂，有時候為了優(yōu)化SQL洁段，不得不使用if來解決，比如說LIKE語句共郭，當然一般不推薦使用LIKE祠丝，但如果存在使用的場景，盡可能在不需要使用時候去除LIKE除嘹，比如查詢文章標題写半，以提高查詢效率。 最好的方式是使用lucence等搜索引擎來解決這種全文索引的問題尉咕。
總的來說叠蝇，if與choose判斷分支是不可能完全去除的，但是推薦使用SQL原生的方式來解決一些動態(tài)問題年缎，而不應(yīng)該完全依賴Mybatis來完成動態(tài)分支的判斷悔捶，因為判斷分支過于復(fù)雜，而且難以維護单芜。
3蜕该、用XML注釋取代SQL注釋。
Mybatis中原SQL的注釋盡量不要保留洲鸠，注釋會引發(fā)一些問題堂淡，如果需要使用注釋馋缅，可以在XML中用來注釋，保證在生成的SQL中不會存在SQL注釋绢淀，從而降低問題出現(xiàn)的可能性萤悴。這樣做還有一個好處，就是在IDE中可以很清楚的區(qū)分注釋與SQL皆的。
現(xiàn)在來談?wù)勛⑨屢l(fā)的問題覆履，我做的一個項目中，分頁組件是基于Mybatis的费薄，它會在你寫的SQL腳本外面再套一層SELECT COUNT(*) ROWNUM_ FROM (….) 計算總記錄數(shù)内狗，同時有另一個嵌套SELECT * FROM(…) WHERE ROWNUM > 10 AND RONNUM < 10 * 2這種方式生成分頁信息，如果你的腳本中最后一行出現(xiàn)了注釋义锥，則添加的部分會成為注釋的一部分柳沙，執(zhí)行就會報錯。除此之外拌倍，某些情況下也可能導(dǎo)致部分條件被忽略赂鲤，如下面的情況：
即使傳入的參數(shù)中存在對應(yīng)的參數(shù)，實際也不會產(chǎn)生效果柱恤，因為后面的內(nèi)容實際上是被完全注釋了数初。這種錯誤，如果不經(jīng)過嚴格的測試梗顺，是很難發(fā)現(xiàn)的泡孩。一般情況下，XML注釋完全可以替代SQL注釋寺谤，因此這種行為應(yīng)該可以禁止掉仑鸥。
4、盡可能使用`#{}`变屁，而不是`${}`.
Mybatis中盡量不要使用${}眼俊，盡量這樣做很方便開發(fā)，但是有一個問題粟关，就是大量使用會導(dǎo)致ORACLE的硬解析疮胖，拖慢數(shù)據(jù)庫性能，運行越久闷板，數(shù)據(jù)庫性能會越差澎灸。對于一般多個字符串IN的處理，可以參考如下的解決方案:http://www.myexception.cn/sql/849573.html遮晚，基本可以解決大部分${}.
關(guān)于${}性昭，另一個誤用的地方就是LIKE，我這邊還有個案例：比如一些樹型菜單鹏漆，節(jié)點會設(shè)計成'01','0101',用兩位節(jié)點來區(qū)分層級巩梢，這時候创泄，如果需要查詢01節(jié)點下所有的節(jié)點艺玲，最簡單的SQL便是:SELECT * FROM TREE WHERE ID LIKE '01%',這種SQL其實無可厚非括蝠，因為它也能用到索引，所以不需要特別的處理饭聚，直接使用就行了忌警。但如果是文章標題，則需要額外注意了：SELECT * FROM T_NEWS_TEXT WHERE TITLE LIKE '%OSC%'秒梳，這是怎么也不會用到索引的法绵，上面說了，最好采用全文檢索酪碘。但如果離不開LIKE朋譬，就需要注意使用的方式： ID LIKE #{ID} || '%'而不是ID LIKE '
有人覺得使用||會增加ORACLE處理的時間，我覺得不要把ORACLE看得太傻兴垦，雖然有時候確實非常傻徙赢，有空可以再總結(jié)ORACLE傻不垃圾的地方，但是稍加測試便知：這種串聯(lián)方式探越，對于整個SQL的解析執(zhí)行狡赐，應(yīng)該是微乎其微的。
當然還有一些特殊情況是沒有辦法處理的钦幔，比如說動態(tài)注入列名枕屉、表名等。對于這些情況鲤氢，則比較棘手搀擂，沒有找到比較方便的手段。由于這種情況出現(xiàn)的可能性會比較少卷玉，所以使用ID有人覺得使用∣∣會增加ORACLE處理的時間哥倔，我覺得不要把ORACLE看得太傻，雖然有時候確實非常傻揍庄，有空可以再總結(jié)ORACLE傻不垃圾的地方咆蒿，但是稍加測試便知：這種串聯(lián)方式，對于整個SQL的解析執(zhí)行蚂子，應(yīng)該是微乎其微的沃测。當然還有一些特殊情況是沒有辦法處理的，比如說動態(tài)注入列名食茎、表名等蒂破。對于這些情況，則比較棘手别渔，沒有找到比較方便的手段附迷。由于這種情況出現(xiàn)的可能性會比較少惧互，所以使用{}倒也不至于有什么太大的影響。當然你如果有代碼潔癖的話喇伯，可以使用ORACLE的動態(tài)執(zhí)行SQL的機制Execute immediate喊儡，這樣就可以完全避免${}出現(xiàn)的可能性了。這樣會引入比較復(fù)雜的模型稻据，這個時候艾猜，你就需要取舍了。
針對于以上動態(tài)SQL所導(dǎo)致的問題捻悯，最激進的方式是全部采用存儲過程匆赃，用數(shù)據(jù)庫原生的方式來解決，方便開發(fā)調(diào)試今缚，當然也會帶來問題：對開發(fā)人員會有更高的要求算柳、存儲過程的管理等等，我這邊項目沒有采用過這種方式姓言，這里不做更多的展開瞬项。
5、簡單使用Mybatis事期。
Mybatis的功能相對而言還是比較弱的滥壕，缺少了好多必要的輔助庫，字符串處理等等兽泣，擴展也比較困難绎橘，一般也就可能對返回值進行一些處理。因此最好僅僅把它作為單純的SQL配置文件唠倦，以及簡單的ORM框架称鳞。不要嘗試在Mybatis中做過多的動態(tài)SQL，否則會導(dǎo)致后續(xù)的維護非常惡心稠鼻。
幾點技巧總結(jié)冈止；
1、查詢很多字段時可以提出來再引入到sql語句
提群虺荨：
id, type, shopCouId, imgPath, fromDate, toDate, insDate, insUserId, updDate, updUserId, delFlg
引入：
select
from adinfo
where id = #{id,jdbcType=INTEGER}
2熙暴、如果sql語句中需要使用<, >, "" 符號時，需要使用< > " 或者
3慌盯、緩存使用
在增刪查改時周霉，可以使用緩存屬性控制數(shù)據(jù)緩存
4、可以判斷傳進來的參數(shù)亚皂，再進行操作
and langCd = #{langCd,jdbcType=VARCHAR}
5俱箱、可以在sql語句中直接進行加減乘除計算，模糊查詢時灭必，需要注意使用方式
MyBatis把int類型的0處理成空串’’和mysql處理空串’’為0的問題
當數(shù)據(jù)庫字段類型是整數(shù)狞谱，如果參數(shù)變量為空字符串或者NULL乃摹，Mybatis會自動將參數(shù)賦值0，所以如果要判斷整數(shù)參數(shù)的多種狀態(tài)在傳遞數(shù)值到Mapper之前就要判斷是否為空字符串和NULL并將相應(yīng)的狀態(tài)數(shù)值賦值給該參數(shù)跟衅，否則參數(shù)值等于空字符串孵睬、NULL和0得到的結(jié)果是一樣的。
一般情況下与斤，涉及到int類型的操作的時候肪康，在Service中會統(tǒng)一把數(shù)字類型先變成字符串類型荚恶，然后再傳遞到Mapper中操作撩穿。
案例七：
使用mybatis 進行批量insert的時候 會自動封裝成一個map key是list 要存的數(shù)據(jù)變成了數(shù)組 需要注意在xml里面如果使用自己定義的collection要在傳參時定義一個mapkey是自己定義的變量名哦。
在使用resultMap的時候谒撼，要把ID寫在第一行食寡，否則的話，就會報錯廓潜。
優(yōu)缺點
總結(jié)下mybatis的優(yōu)缺點抵皱，以便大家對于mybatis的了解能更全面些。但我所說的優(yōu)缺點辩蛋，僅是我個人總結(jié)并結(jié)合使用體驗后得出的結(jié)果呻畸，并不能代表大眾想法，因此才以“淺談”作為文章標題悼院。如果大家的見解與我不同伤为，歡迎積極提出來一塊討論，我也借以彌補自己認識的不足和短見据途。
優(yōu)點：
易于上手和掌握绞愚。
sql寫在xml里，便于統(tǒng)一管理和優(yōu)化颖医。
解除sql與程序代碼的耦合位衩。
提供映射標簽，支持對象與數(shù)據(jù)庫的orm字段關(guān)系映射
提供對象關(guān)系映射標簽熔萧，支持對象關(guān)系組建維護
提供xml標簽糖驴，支持編寫動態(tài)sql。
缺點：
sql工作量很大佛致，尤其是字段多贮缕、關(guān)聯(lián)表多時，更是如此晌杰。
sql依賴于數(shù)據(jù)庫跷睦，導(dǎo)致數(shù)據(jù)庫移植性差。
由于xml里標簽id必須唯一肋演，導(dǎo)致DAO中方法不支持方法重載抑诸。
字段映射標簽和對象關(guān)系映射標簽僅僅是對映射關(guān)系的描述烂琴，具體實現(xiàn)仍然依賴于sql。（比如配置了一對多Collection標簽蜕乡，如果sql里沒有join子表或查詢子表的話奸绷，查詢后返回的對象是不具備對象關(guān)系的，即Collection的對象為null）
DAO層過于簡單层玲，對象組裝的工作量較大号醉。
不支持級聯(lián)更新、級聯(lián)刪除辛块。
編寫動態(tài)sql時,不方便調(diào)試畔派，尤其邏輯復(fù)雜時。
8 提供的寫動態(tài)sql的xml標簽功能簡單（連struts都比不上）润绵，編寫動態(tài)sql仍然受限线椰，且可讀性低。
若不查詢主鍵字段尘盼，容易造成查詢出的對象有“覆蓋”現(xiàn)象憨愉。
參數(shù)的數(shù)據(jù)類型支持不完善。（如參數(shù)為Date類型時卿捎，容易報沒有g(shù)et配紫、set方法，需在參數(shù)上加@param）
多參數(shù)時午阵，使用不方便躺孝，功能不夠強大。（目前支持的方法有map趟庄、對象括细、注解@param以及默認采用012索引位的方式）
緩存使用不當，容易產(chǎn)生臟數(shù)據(jù)戚啥。
總結(jié)：
mybatis的優(yōu)點其實也是mybatis的缺點奋单，正因為mybatis使用簡單，數(shù)據(jù)的可靠性猫十、完整性的瓶頸便更多依賴于程序員對sql的使用水平上了览濒。sql寫在xml里，雖然方便了修改拖云、優(yōu)化和統(tǒng)一瀏覽贷笛，但可讀性很低，調(diào)試也非常困難宙项，也非常受限乏苦，無法像jdbc那樣在代碼里根據(jù)邏輯實現(xiàn)復(fù)雜動態(tài)sql拼接。mybatis簡單看就是提供了字段映射和對象關(guān)系映射的jdbc，省去了數(shù)據(jù)賦值到對象的步驟而已汇荐，除此以外并無太多作為洞就，不要把它想象成hibernate那樣強大，簡單小巧易用上手掀淘，方便瀏覽修改sql就是它最大的優(yōu)點了旬蟋。
mybatis適用于小型且程序員能力較低的項目和人群使用，對于中大型項目來說我并不推薦使用革娄，如果覺得hibernate效率低的話（實際上也是使用不當所致倾贰，hibernate是實際上是不適用于擁有高負載的工程項目），還不如直接用spring提供的jdbc簡單框架（Template）拦惋，同樣支持對象映射匆浙。
擴展閱讀
