2. 程式人生 > >Mybatis的快取機制（二）

Mybatis的快取機制（二）

阿新 • • 發佈：2019-01-28

0.寫在前面

        MyBatis是一個簡單，小巧但功能非常強大的ORM開源框架，它的功能強大也體現在它的快取機制上。MyBatis提供了一級快取、二級快取 這兩個快取機制，能夠很好地處理和維護快取，以提高系統的效能。本文的目的則是向讀者詳細介紹MyBatis的一級快取，深入原始碼，解析MyBatis一級快取的實現原理，並且針對一級快取的特點提出了在實際使用過程中應該注意的事項。
讀完本文，你將會學到：

1、什麼是一級快取？為什麼使用一級快取？

2、MyBatis的一級快取是怎樣組織的？（即SqlSession物件中的快取是怎樣組織的？）

3、一級快取的生命週期有多長？

4、Cache介面的設計以及CacheKey的定義

5、一級快取的效能分析以及應該注意的事項

        

1. 什麼是一級快取？ 為什麼使用一級快取？

     每當我們使用MyBatis開啟一次和資料庫的會話，MyBatis會創建出一個SqlSession物件表示一次資料庫會話。

      在對資料庫的一次會話中，我們有可能會反覆地執行完全相同的查詢語句，如果不採取一些措施的話，每一次查詢都會查詢一次資料庫,而我們在極短的時間內做了完全相同的查詢，那麼它們的結果極有可能完全相同，由於查詢一次資料庫的代價很大，這有可能造成很大的資源浪費。

      為了解決這一問題，減少資源的浪費，MyBatis會在表示會話的SqlSession

物件中建立一個簡單的快取，將每次查詢到的結果結果快取起來，當下次查詢的時候，如果判斷先前有個完全一樣的查詢，會直接從快取中直接將結果取出，返回給使用者，不需要再進行一次資料庫查詢了。

     如下圖所示，MyBatis會在一次會話的表示----一個SqlSession物件中建立一個本地快取(local cache)，對於每一次查詢，都會嘗試根據查詢的條件去本地快取中查詢是否在快取中，如果在快取中，就直接從快取中取出，然後返回給使用者；否則，從資料庫讀取資料，將查詢結果存入快取並返回給使用者。


      對於會話（Session）級別的資料快取，我們稱之為一級資料快取，簡稱一級快取。

2. MyBatis中的一級快取是怎樣組織的？（即SqlSession中的快取是怎樣組織的？）

      由於MyBatis使用SqlSession物件表示一次資料庫的會話，那麼，對於會話級別的一級快取也應該是在SqlSession中控制的。

      實際上, MyBatis只是一個MyBatis對外的介面，SqlSession將它的工作交給了Executor執行器這個角色來完成，負責完成對資料庫的各種操作。當建立了一個SqlSession物件時，MyBatis會為這個SqlSession物件建立一個新的Executor執行器，而快取資訊就被維護在這個Executor執行器中，MyBatis將快取和對快取相關的操作封裝成了Cache介面中。SqlSession、Executor、Cache之間的關係如下列類圖所示：


      如上述的類圖所示，Executor介面的實現類BaseExecutor中擁有一個Cache介面的實現類PerpetualCache，則對於BaseExecutor物件而言，它將使用PerpetualCache物件維護快取。

綜上，SqlSession物件、Executor物件、Cache物件之間的關係如下圖所示：

由於Session級別的一級快取實際上就是使用PerpetualCache維護的，那麼PerpetualCache是怎樣實現的呢？

PerpetualCache實現原理其實很簡單，其內部就是通過一個簡單的HashMap<k,v> 來實現的，沒有其他的任何限制。如下是PerpetualCache的實現程式碼：

[java] view plain copy print?
  1. package org.apache.ibatis.cache.impl;  
  2. import java.util.HashMap;  
  3. import java.util.Map;  
  4. import java.util.concurrent.locks.ReadWriteLock;  
  5. import org.apache.ibatis.cache.Cache;  
  6. import org.apache.ibatis.cache.CacheException;  
  7. /** 
  8.  * 使用簡單的HashMap來維護快取 
  9.  * @author Clinton Begin 
  10.  */
  11. publicclass PerpetualCache implements Cache {  
  12.   private String id;  
  13.   private Map<Object, Object> cache = new HashMap<Object, Object>();  
  14.   public PerpetualCache(String id) {  
  15.     this.id = id;  
  16.   }  
  17.   public String getId() {  
  18.     return id;  
  19.   }  
  20.   publicint getSize() {  
  21.     return cache.size();  
  22.   }  
  23.   publicvoid putObject(Object key, Object value) {  
  24.     cache.put(key, value);  
  25.   }  
  26.   public Object getObject(Object key) {  
  27.     return cache.get(key);  
  28.   }  
  29.   public Object removeObject(Object key) {  
  30.     return cache.remove(key);  
  31.   }  
  32.   publicvoid clear() {  
  33.     cache.clear();  
  34.   }  
  35.   public ReadWriteLock getReadWriteLock() {  
  36.     returnnull;  
  37.   }  
  38.   publicboolean equals(Object o) {  
  39.     if (getId() == null) thrownew CacheException("Cache instances require an ID.");  
  40.     if (this == o) returntrue;  
  41.     if (!(o instanceof Cache)) returnfalse;  
  42.     Cache otherCache = (Cache) o;  
  43.     return getId().equals(otherCache.getId());  
  44.   }  
  45.   publicint hashCode() {  
  46.     if (getId() == null) thrownew CacheException("Cache instances require an ID.");  
  47.     return getId().hashCode();  
  48.   }  
  49. }  

3.一級快取的生命週期有多長？

a. MyBatis在開啟一個數據庫會話時，會 建立一個新的SqlSession物件，SqlSession物件中會有一個新的Executor物件，Executor物件中持有一個新的PerpetualCache物件；當會話結束時，SqlSession物件及其內部的Executor物件還有PerpetualCache物件也一併釋放掉。

b. 如果SqlSession呼叫了close()方法，會釋放掉一級快取PerpetualCache物件，一級快取將不可用；

c. 如果SqlSession呼叫了clearCache()，會清空PerpetualCache物件中的資料，但是該物件仍可使用；

d.SqlSession中執行了任何一個update操作(update()、delete()、insert()) ，都會清空PerpetualCache物件的資料，但是該物件可以繼續使用；


4. SqlSession 一級快取的工作流程：

1.對於某個查詢，根據statementId,params,rowBounds來構建一個key值，根據這個key值去快取Cache中取出對應的key值儲存的快取結果；

2. 判斷從Cache中根據特定的key值取的資料資料是否為空，即是否命中；

3. 如果命中，則直接將快取結果返回；

4. 如果沒命中：

        4.1  去資料庫中查詢資料，得到查詢結果；

        4.2  將key和查詢到的結果分別作為key,value對儲存到Cache中；

        4.3. 將查詢結果返回；

5. 結束。

[關於上述工作過程中 key值的構建，我們將在第下一節中重點探討，這也是MyBatis快取機制中非常重要的一個概念。]


5. Cache介面的設計以及CacheKey的定義（非常重要）

      如下圖所示，MyBatis定義了一個org.apache.ibatis.cache.Cache介面作為其Cache提供者的SPI(Service Provider Interface) ，所有的MyBatis內部的Cache快取，都應該實現這一介面。MyBatis定義了一個PerpetualCache實現類實現了Cache介面，實際上，在SqlSession物件裡的Executor 物件內維護的Cache型別例項物件，就是PerpetualCache子類建立的。

    （MyBatis內部還有很多Cache介面的實現，一級快取只會涉及到這一個PerpetualCache子類，Cache的其他實現將會放到二級快取中介紹）。


我們知道，Cache最核心的實現其實就是一個Map，將本次查詢使用的特徵值作為key，將查詢結果作為value儲存到Map中。

現在最核心的問題出現了：怎樣來確定一次查詢的特徵值？

換句話說就是：怎樣判斷某兩次查詢是完全相同的查詢？

也可以這樣說：如何確定Cache中的key值？

MyBatis認為，對於兩次查詢，如果以下條件都完全一樣，那麼就認為它們是完全相同的兩次查詢：

1. 傳入的 statementId

2. 查詢時要求的結果集中的結果範圍 （結果的範圍通過rowBounds.offset和rowBounds.limit表示）；

3. 這次查詢所產生的最終要傳遞給JDBC java.sql.Preparedstatement的Sql語句字串（boundSql.getSql()）

4. 傳遞給java.sql.Statement要設定的引數值

現在分別解釋上述四個條件：

1. 傳入的statementId，對於MyBatis而言，你要使用它，必須需要一個statementId，它代表著你將執行什麼樣的Sql；

2. MyBatis自身提供的分頁功能是通過RowBounds來實現的，它通過rowBounds.offset和rowBounds.limit來過濾查詢出來的結果集，這種分頁功能是基於查詢結果的再過濾，而不是進行資料庫的物理分頁；

由於MyBatis底層還是依賴於JDBC實現的，那麼，對於兩次完全一模一樣的查詢，MyBatis要保證對於底層JDBC而言，也是完全一致的查詢才行。而對於JDBC而言，兩次查詢，只要傳入給JDBC的SQL語句完全一致，傳入的引數也完全一致，就認為是兩次查詢是完全一致的。

上述的第3個條件正是要求保證傳遞給JDBC的SQL語句完全一致；第4條則是保證傳遞給JDBC的引數也完全一致；

3、4講的有可能比較含糊，舉一個例子：

[html] view plain copy print?
  1. <selectid="selectByCritiera"parameterType="java.util.Map"resultMap="BaseResultMap">
  2.       select employee_id,first_name,last_name,email,salary  
  3.       from louis.employees  
  4.       where  employee_id = #{employeeId}  
  5.       and first_name= #{firstName}  
  6.       and last_name = #{lastName}  
  7.       and email = #{email}  
  8. </select>
如果使用上述的"selectByCritiera"進行查詢，那麼，MyBatis會將上述的SQL中的#{}都替換成 ? 如下： [sql] view plain copy print?
  1. select employee_id,first_name,last_name,email,salary  
  2. from louis.employees  
  3. where  employee_id = ?  
  4. and first_name= ?  
  5. and last_name = ?  
  6. and email = ?  
MyBatis最終會使用上述的SQL字串建立JDBC的java.sql.PreparedStatement物件，對於這個PreparedStatement物件，還需要對它設定引數，呼叫setXXX()來完成設值，第4條的條件，就是要求對設定JDBC的PreparedStatement的引數值也要完全一致。

          即3、4兩條MyBatis最本質的要求就是：

                  呼叫JDBC的時候，傳入的SQL語句要完全相同，傳遞給JDBC的引數值也要完全相同。

綜上所述,CacheKey由以下條件決定：

                                     statementId  + rowBounds  + 傳遞給JDBC的SQL  + 傳遞給JDBC的引數值

CacheKey的建立

對於每次的查詢請求，Executor都會根據傳遞的引數資訊以及動態生成的SQL語句，將上面的條件根據一定的計算規則，建立一個對應的CacheKey物件。

我們知道建立CacheKey的目的，就兩個：

    1. 根據CacheKey作為key,去Cache快取中查詢快取結果；

    2. 如果查詢快取命中失敗，則通過此CacheKey作為key，將從資料庫查詢到的結果作為value，組成key,value對儲存到Cache快取中。

CacheKey的構建被放置到了Executor介面的實現類BaseExecutor中，定義如下：

[java] view plain copy print?
  1. /** 
  2.  * 所屬類:  org.apache.ibatis.executor.BaseExecutor 
  3.  * 功能   :   根據傳入資訊構建CacheKey 
  4.  */
  5. public CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql) {  
  6.   if (closed) thrownew ExecutorException("Executor was closed.");  
  7.   CacheKey cacheKey = new CacheKey();  
  8.   //1.statementId
  9.   cacheKey.update(ms.getId());  
  10.   //2. rowBounds.offset
  11.   cacheKey.update(rowBounds.getOffset());  
  12.   //3. rowBounds.limit
  13.   cacheKey.update(rowBounds.getLimit());  
  14.   //4. SQL語句
  15.   cacheKey.update(boundSql.getSql());  
  16.   //5. 將每一個要傳遞給JDBC的引數值也更新到CacheKey中
  17.   List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();  
  18.   TypeHandlerRegistry typeHandlerRegistry = ms.getConfiguration().getTypeHandlerRegistry();  
  19.   for (int i = 0; i < parameterMappings.size(); i++) { // mimic DefaultParameterHandler logic
  20.     ParameterMapping parameterMapping = parameterMappings.get(i);  
  21.     if (parameterMapping.getMode() != ParameterMode.OUT) {  
  22.       Object value;  
  23.       String propertyName = parameterMapping.getProperty();  
  24.       if (boundSql.hasAdditionalParameter(propertyName)) {  
  25.         value = boundSql.getAdditionalParameter(propertyName);  
  26.       } elseif (parameterObject == null) {  
  27.         value = null;  
  28.       } elseif (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) {  
  29.         value = parameterObject;  
  30.       } else {  
  31.         MetaObject metaObject = configuration.newMetaObject(parameterObject);  
  32.         value = metaObject.getValue(propertyName);  
  33.       }  
  34.       //將每一個要傳遞給JDBC的引數值也更新到CacheKey中
  35.       cacheKey.update(value);  
  36.     }  
  37.   }  
  38.   return cacheKey;  
  39. }      
CacheKey的hashcode生成演算法

剛才已經提到，Cache介面的實現，本質上是使用的HashMap<k,v>,而構建CacheKey的目的就是為了作為HashMap<k,v>中的key值。而HashMap是通過key值的hashcode 來組織和儲存的，那麼，構建CacheKey的過程實際上就是構造其hashCode的過程。下面的程式碼就是CacheKey的核心hashcode生成演算法，感興趣的話可以看一下：

[java] view plain copy print?
  1. publicvoid update(Object object) {  
  2.    if (object != null && object.getClass().isArray()) {  
  3.      int length = Array.getLength(object);  
  4.      for (int i = 0; i < length; i++) {  
  5.        Object element = Array.get(object, i);  
  6.        doUpdate(element);  
  7.      }  
  8.    } else {  
  9.      doUpdate(object);  
  10.    }  
  11.  }  
  12.  privatevoid doUpdate(Object object) {  
  13. //1. 得到物件的hashcode;  
  14.    int baseHashCode = object == null ? 1 : object.hashCode();  
  15.    //物件計數遞增
  16.    count++;  
  17.    checksum += baseHashCode;  
  18.    //2. 物件的hashcode 擴大count倍
  19.    baseHashCode *= count;  
  20.    //3. hashCode * 拓展因子（預設37）+拓展擴大後的物件hashCode值
  21.    hashcode = multiplier * hashcode + baseHashCode;  
  22.    updateList.add(object);  
  23.  }  

一級快取的效能分析

我將從兩個 一級快取的特性來討論SqlSession的一級快取效能問題：

1.MyBatis對會話（Session）級別的一級快取設計的比較簡單，就簡單地使用了HashMap來維護，並沒有對HashMap的容量和大小進行限制。

讀者有可能就覺得不妥了：如果我一直使用某一個SqlSession物件查詢資料，這樣會不會導致HashMap太大，而導致 java.lang.OutOfMemoryError錯誤啊？ 讀者這麼考慮也不無道理，不過MyBatis的確是這樣設計的。

MyBatis這樣設計也有它自己的理由：

a.  一般而言SqlSession的生存時間很短。一般情況下使用一個SqlSession物件執行的操作不會太多，執行完就會消亡；

b.  對於某一個SqlSession物件而言，只要執行update操作（update、insert、delete），都會將這個SqlSession物件中對應的一級快取清空掉，所以一般情況下不會出現快取過大，影響JVM記憶體空間的問題；

c.  可以手動地釋放掉SqlSession物件中的快取。

2.  一級快取是一個粗粒度的快取，沒有更新快取和快取過期的概念

      MyBatis的一級快取就是使用了簡單的HashMap，MyBatis只負責將查詢資料庫的結果儲存到快取中去， 不會去判斷快取存放的時間是否過長、是否過期，因此也就沒有對快取的結果進行更新這一說了。

根據一級快取的特性，在使用的過程中，我認為應該注意：

1、對於資料變化頻率很大，並且需要高時效準確性的資料要求，我們使用SqlSession查詢的時候，要控制好SqlSession的生存時間，SqlSession的生存時間越長，它其中快取的資料有可能就越舊，從而造成和真實資料庫的誤差；同時對於這種情況，使用者也可以手動地適時清空SqlSession中的快取；

2、對於只執行、並且頻繁執行大範圍的select操作的SqlSession物件，SqlSession物件的生存時間不應過長。


舉例：

例1、看下面這個例子，下面的例子使用了同一個SqlSession指令了兩次完全一樣的查詢，將兩次查詢所耗的時間打印出來，結果如下：

[java] view plain copy print?
  1. package com.louis.mybatis.test;  
  2. import java.io.InputStream;  
  3. import java.util.Date;  
  4. import java.util.HashMap;  
  5. import java.util.List;  
  6. import java.util.Map;  
  7. import org.apache.commons.logging.Log;  
  8. import org.apache.commons.logging.LogFactory;  
  9. import org.apache.ibatis.executor.BaseExecutor;  
  10. import org.apache.ibatis.io.Resources;  
  11. import org.apache.ibatis.session.SqlSession;  
  12. import org.apache.ibatis.session.SqlSessionFactory;  
  13. import org.apache.ibatis.session.SqlSessionFactoryBuilder;  
  14. import org.apache.log4j.Logger;  
  15. import com.louis.mybatis.model.Employee;  
  16. /** 
  17.  * SqlSession 簡單查詢演示類 
  18.  * @author louluan 
  19.  */

  20. 相關推薦

    Mybatis的快取機制（二）

    0.寫在前面         MyBatis是一個簡單，小巧但功能非常強大的ORM開源框架，它的功能強大也體現在它的快取機制上。MyBatis提供了一級快取、二級快取 這兩個快取機制，能夠很好地處理和維護快取，以提高系統的效能。本文的目的則是向讀者詳細介紹MyBatis的一

    MyBatis快取機制（一級快取，二級快取）

    一，MyBatis一級快取（本地快取） 　　My Batis 一級快取存在於 SqlSession 的生命週期中，是SqlSession級別的快取。在操作資料庫時需要構造SqlSession物件，在物件中有一個數據結構用來儲存快取資料。不同的SqlSession之間的資料快取是不能共享的。 　　在同一個Sql

    Redis快取篇（二）淘汰機制：快取滿了怎麼辦？

    上一講提到，快取的容量總是小於後端資料庫的。隨著業務系統的使用，快取資料會撐滿記憶體空間，該怎麼處理呢？ 本節我們來學習記憶體淘汰機制。在Redis 4.0之前有6種記憶體淘汰策略，之後又增加2種，一共8種，如下圖所示： noeviction策略：記憶體空間達到maxmemory時，不會淘汰資料，有新寫入

    .NET垃圾回收機制（二）

    sel 結點 是個 pac public 良好的 方案 環境 哪裏 一、GC的必要性 　　1、應用程序對資源操作，通常簡單分為以下幾個步驟：為對應的資源分配內存 → 初始化內存 → 使用資源 → 清理資源 → 釋放內存。 　　2、應用程序對資源（內存使用）管理的方式，常見的

    mybatis 詳解（二）------入門實例（基於XML）

    ssi 開發模式 文件中 Coding import 拼接 upd baidu actor 　　通過上一小節，mybatis 和 jdbc 的區別：http://www.cnblogs.com/ysocean/p/7271600.html，我們對 mybatis有了一個大致

    spring 內部工作機制（二）

    出了 流水線 tor 應用程序 java反射機制 post 技術 process 加載 本章節講Spring容器從加載配置文件到創建出一個完整Bean的作業流程及參與的角色。 Spring 啟動時讀取應用程序提供的Bean配置信息，並在Spring容器中生成一份相應

    Mybatis學習系列（二）Mapper映射文件

    tst 轉換 tin 是個 sql註入 eas 屬性。 object spl Mapper映射文件，作用是用來配置SQL映射語句，根據不同的SQL語句性質，使用不同的標簽，mapper文件中常用的標簽有<iselect>、<insert>、<

    Android包管理機制（二）PackageInstaller安裝APK

    tac _id cas 賦值 complete get Owner 執行 context 前言 在本系列上一篇文章Android包管理機制（一）PackageInstaller的初始化中我們學習了PackageInstaller是如何初始化的，這一篇文章我們接著學習Pack

    WPF的消息機制（二）- WPF內部的5個窗口之隱藏消息窗口

    release 直接 3.0 函數 行為 交互 sdn temp spl 原文:WPF的消息機制（二）- WPF內部的5個窗口之隱藏消息窗口 版權聲明：本文為博主原創文章，未經博主允許不得轉載。 https://blog.csdn.n

    WPF的訊息機制（二）- WPF內部的5個視窗之隱藏訊息視窗

    原文: WPF的訊息機制（二）- WPF內部的5個視窗之隱藏訊息視窗   目錄 WPF的訊息機制（一）-讓應用程式動起來 WPF的訊息機制（二）-WPF內部的5個視窗 （1）隱藏訊息視窗 （2）處理啟用和關閉的訊息的視窗和系統資源通知視窗 （3）用於

    Android 學習之《第一行程式碼》第二版 筆記（十二）詳解廣播機制（二）

    廣播的最佳實踐——實現強制下線功能 思路：在介面上彈出一個對話方塊，讓使用者無法進行任何操作，必須點選對話方塊中的確定按鈕，然後回到登入介面即可。 一、效果圖 1. 登入介面並輸入賬號密碼 2. 登陸後的介面 3. 強制下線 4. 退回登陸的介面

    Mybait快取機制（四）

    MyBatis同大多數ORM框架一樣，提供了一級快取和二級快取的支援。 一級快取：其作用域為session範圍內，當session執行flush或close方法後，一級快取會被清空。 二級快取：二級快取和一級快取機制相同，但是可以自定義其作用範圍，如Ehcache。 一級快取 在預設情況下mybati

    mybatis基礎系列（二）——基礎語法、別名、輸入對映、輸出對映

    增刪改查 <mapper>根節點及其子節點 mybatis框架需要讀取對映檔案建立會話工廠，對映檔案是以<mapper>作為根節點，在根節點中支援9個元素，分別為insert、update、delete、select（增刪改查）;cache、cache-ref、resultMap、

    Dubbo的SPI機制（二）（Dubbo優化後的SPI實現）

    上一篇部落格： https://blog.csdn.net/Dongguabai/article/details/84345871 相關部落格： https://blog.csdn.net/Dongguabai/article/details/83754289  

    Windows程式和訊息機制（二）：訊息有關的函式

    不同視窗程式可以通過訊息進行互動，主要用到的函式如下： FindWindow 獲取一個視窗的控制代碼。 HWND FindWindow( LPCTSTR lpClassName,// 類名 LPCTSTR lpWindowName//

    深入Mysql鎖機制（二）讀鎖和寫鎖

    深入Mysql鎖機制（二）讀鎖和寫鎖 這篇文章主要來介紹一下MySQL資料庫中的表級鎖。 本文提到的讀鎖和寫鎖都是MySQL資料庫的MyISAM引擎支援的表鎖的。而對於行級鎖的共享讀鎖和互斥寫鎖請閱讀MySQL中的共享鎖與排他鎖。我習慣在描述表鎖的時候按照讀寫來區分，在表

    快取篇（二）- JetCache

    本文將由淺入深，從基本特性介紹，從簡單demo使用，到JetCache原始碼分析，到Spring Aop的原始碼分析，到如何利用這些知識去自己嘗試寫一個自己的cache小demo，去做一個全面的概括。 *背景和特性 *用法demo *JetCache原始碼分析 *Spring Aop

    深入理解java虛擬機器之自動記憶體管理機制（二）

    垃圾收集演算法 　　　　java中的記憶體是交給虛擬機器管理的。要實現垃圾回收，必須考慮如下三個問題： 　　　　1. 哪些記憶體需要回收？ 　　　　2. 什麼時候回收？ 　　　　3. 怎麼回收？ 　　　　對於第一點，往大了來說，是堆和方法區的記憶體需要回收。往具體了來說，是堆中哪些物件的記憶體可以回

    MyBatis的學習（二）——MyBatis事務核心物件及配置

    一、獲取SqlSession物件 MyBatis框架中涉及到的幾個API SqlSessionFactoryBuilder：該物件負責根據MyBatis配置檔案mybatis-config.xml構建SqlSessionFactory例項  負責生產session SqlSes

    複習之MyBatis基礎用法（二）——ResultMap用法詳解

    ResultMap – 是最複雜也是最強大的元素 它就是讓你遠離 90%的需要從結果集中取出資料的 JDBC 程式碼的那個東西, 而且在一些情形下允許你做一些 JDBC 不支援的事情。事實上, 編寫相似於對複雜語句聯合對映這些等同的程式碼, 也許可以跨過上千行的