原文連結

ibatis本是apache的一個開源專案，2010年這個專案由apache software foundation 遷移到了google code，並且改名為mybatis。

1、Mybatis實現了介面繫結，使用更加方便。
在ibatis2.x中我們需要在DAO的實現類中指定具體對應哪個xml對映檔案，
而Mybatis實現了DAO介面與xml對映檔案的繫結，自動為我們生成介面的具體實現，使用時不需要通過SqlMapClient去指定namespace 和 sql statement id， 只需要在 sql map config 檔案中指定介面的 namespace, 並且sql statement id 和 介面的名字意義對應，然後呼叫對一個介面即可。

注意：

雖然Mybatis支援在介面中直接使用annotation的配置方式來簡化配置，
不過強烈建議仍然使用xml配置的方式。畢竟annotation的配置方式功能有限且程式碼入侵性太強。使用xml配置方式才能體現出Mybatis的優勢所在

2、物件關係對映的改進，效率更高
相信很多在使用ibatis2.x的朋友並沒有通過ibatis的xml對映檔案來實現物件間的關係對映。其實也確實沒有必要那麼做，因為ibatis2.x採用的是“巢狀查詢”的方式將物件之間的關係通過查詢語句的直接拼裝來實現，其效果和在DAO或Service中自行封裝是一樣的。
不過這種方式存在“N+1查詢問題”。
概括地講，N+1查詢問題可以是這樣引起的：
? 你執行了一個單獨的SQL語句來獲取結果列表（就是+1）。
? 對返回的每條記錄，你執行了一個查詢語句來為每個載入細節（就是N）。
這個問題會導致成百上千的SQL語句被執行。這通常不是期望的。

而在Mybatis中，除了相容ibatis2.x中的“巢狀查詢”方式外，還提供了直接“巢狀結果”的方式，其效果相當於直接通過一句sql將查詢出的dto物件自動封裝成所需的物件。
具體實現方法請自行參考Mybatis官方使用手冊，不在此累述.

不過實際上這一改進所帶來的好處也是很有限的。因為這一方式在使用分頁的時候並不起作用，或者說巢狀物件的結果集是不允許進行分頁的。這一點在Mybatis框架中已經做出了明確的限制（org.apache.ibatis.executor.resultset.NestedResultSetHandler裡34行），而實際專案中需要分頁的情況又特別多……
仔細一想，一對多對映確實不能通過配置檔案來分頁，因為這時查詢出的記錄數並不等於實際返回物件的size，不過一對一對映為什麼也不允許就不太明白了。可能是因為一對一是一對多的特例，而在設計框架的時候並沒有考慮去處理或是難於處理這一特例吧。

3、MyBatis採用功能強大的基於OGNL的表示式來消除其他元素。
熟悉struts2的人應該對OGNL表示式不會感到陌生，
MyBatis採用OGNL表示式簡化了配置檔案的複雜性，使用起來更簡潔。


補充：比較遺憾的是，Mybatis的分頁繼續沿用ibatis2.x的邏輯分頁方式，依賴於JDBC的規範。大資料量時會出現效能問題，要想實現物理分頁還得自己想辦法改了。

mybatis和ibatis在配置上的一些具體的差別：http://blog.csdn.net/techbirds_bao/article/details/9235309