承淵政道個人主頁??個人專欄:《C語言基礎語法知識》 《數據結構與算法》 《C知識內容》 《Linux系統知識》 《算法刷題指南》 《測評文章活動推廣》 《大模型語言路線學習》 《MySQL數據庫學習》 《Python知識內容》?逆境不吐心中苦,順境不忘來時路!? 博主簡介:過去做數據庫適配時,我最常見的做法是修改 JDBC 驅動和連接地址,應用能夠啟動、SELECT 1可以執行,就先把數據庫已適配打上勾.但真正把業務代碼跑起來后才會發現,連接成功只是第一關:主鍵生成方式、分頁語法、保留字、標識符大小寫、事務回滾以及并發更新,都可能在后面埋坑.這次我選擇了一個更貼近實際開發的場景:在M4 Mac上運行 KingbaseES,用Spring Boot 3.5 MyBatis 3.0實現商品庫存和訂單接口.除了完成基本CRUD,我還特意制造了庫存不足和并發搶購兩個失敗場景,檢查訂單能否正確回滾,以及庫存會不會被扣成負數.整個過程并非一路順利.我原以為M4需要通過AMD64模擬運行數據庫,實際卻在官網下載到了原生 aarch64 鏡像;按照平時的習慣啟動容器,又在日志中碰到了權限告警;把MySQL DDL 直接搬過來時,AUTO_INCREMENT、保留字和大小寫問題也接連出現.本文記錄的就是這些真實操作、排查過程和解決辦法,希望能給正在進行國產數據庫適配的Java開發者提供一份可以直接參考的實測記錄.目錄一、我想驗證的,不只是能不能連上二、環境準備:M4可以直接跑ARM64版本三、第一次啟動的小坑:容器能跑,不代表啟動參數規范四、表結構先適配:別把MySQL DDL原封不動搬過來五、接入JDBC:我踩到的不是代碼坑,而是依賴來源坑六、數據源配置:驅動類和URL都要換,密碼不要落盤七、CRUD核心:主鍵回填、分頁和安全更新都走一遍八、事務實測:先寫訂單、后扣庫存,失敗時能否一起撤銷九、并發實測:10個庫存,同時來兩個買7個十、三個遷移時很容易撞上的SQL坑1. AUTO_INCREMENT不能照搬2. order是保留字3. 未加引號的標識符會折疊為小寫十一、我是怎樣判斷這次適配真的完成了十二、回頭看:框架改動不大,驗證方式才是重點參考資料一、我想驗證的,不只是能不能連上接觸一個不熟悉的數據庫時,最容易寫出的文章是建一個 Spring Boot 項目,改四行數據源配置,執行一條SELECT 1,然后宣布適配完成.但做過業務系統遷移的人都知道,連接成功只是起點.真正容易出問題的地方,往往藏在建表語法、主鍵回填、分頁、保留字、事務邊界和并發更新里.所以這次我沒有做Hello World,而是給自己定了一個更接近真實需求的小題目:用Spring Boot MyBatis寫一套商品庫存和訂單接口,覆蓋商品的增刪改查,再驗證兩個關鍵場景:訂單寫入后扣庫存失敗,訂單能否跟著回滾;兩個請求同時搶庫存時,會不會扣成負數.我原先還有一個判斷:M4是ARM架構,可能只能拉 x86 鏡像后用模擬運行.實際下載時這個判斷就被推翻了——金倉官網已經提供 aarch64 Docker 包.這個小插曲也提醒我,數據庫適配不要憑過去的印象寫方案,先以當前版本的官方介質為準.二、環境準備:M4可以直接跑ARM64版本我的本機環境如下.JDK選擇17,是因為本文使用Spring Boot 3.5.x;Docker 服務端本身也是 arm64.Hardware: Apple M4 / arm64 macOS: 26.6 Docker Engine: 29.6.2 / linux-arm64 Java: OpenJDK 17.0.20 Maven: 3.9.16我從金倉數據庫官網下載中心取得兩個文件KingbaseES_V009R001C010B0004_aarch64_Docker.tarKingbaseES_V009R001C010B0004_JDBC.zip這里要留意,Docker 數據庫鏡像和 JDBC 驅動是兩個獨立下載項,不能假設鏡像包里一定帶著應用側要用的 jar.下載后我先校驗了官網給出的 MD5,再加載鏡像md5 KingbaseES_V009R001C010B0004_aarch64_Docker.tar md5 KingbaseES_V009R001C010B0004_JDBC.zipdockerload-iKingbaseES_V009R001C010B0004_aarch64_Docker.tardockerimage inspect kingbase_v009r001c010b0004_single_arm:v1\--format{{.Os}}/{{.Architecture}}最后一條返回linux/arm64,不是通過 Rosetta 或 QEMU 跑起來的 AMD64 鏡像.對M系列Mac 來說,少一層模擬,啟動速度和資源占用都更踏實.三、第一次啟動的小坑:容器能跑,不代表啟動參數規范我第一次照著常見數據庫容器的方式啟動,沒有加--privileged.數據庫最終雖然起來了,日志中卻出現sudo: pam_open_session: Permission denied這類告警很容易被數據庫已經能連接掩蓋.我回看官方 Docker 安裝手冊,重新按容器運行要求創建,并把宿主機 54321 映射到容器 54321dockerrun-d\--namekes-v9-dev\--privileged\-p54321:54321\-eDB_MODEpg\-eDB_USERsystem\-eDB_PASSWORD初始化強密碼\-eNEED_STARTyes\-v本機數據目錄:/home/kingbase/userdata\kingbase_v009r001c010b0004_single_arm:v1DB_MODEpg表示這次按 PG 兼容模式驗證.掛載目錄不要隨便指向臨時路徑,否則刪容器后測試數據也一起沒了.口令也不要寫進 Git、文章附件或鏡像層,本文后面的應用配置統一從環境變量讀取.重新啟動后,日志出現server started.我又進入容器核對架構和客戶端版本,結果分別是aarch64與ksql (KingbaseES) V009R001C010.接著創建獨立業務用戶和數據庫.開發項目不要長期拿初始化管理員賬號直連,哪怕只是本機演示也應把這個習慣保留下來.CREATEUSERorder_appWITHPASSWORD業務賬號強密碼;CREATEDATABASEorder_demo OWNER order_app;四、表結構先適配:別把MySQL DDL原封不動搬過來示例只有兩張表product_stock保存可用庫存,purchase_order保存訂單.主鍵使用標準的 identity 寫法,庫存和數量則用CHECK保住數據底線.CREATETABLEproduct_stock(idBIGINTGENERATEDBYDEFAULTASIDENTITYPRIMARYKEY,skuVARCHAR(64)NOTNULLUNIQUE,product_nameVARCHAR(128)NOTNULL,available_stockINTEGERNOTNULLCHECK(available_stock0),versionINTEGERNOTNULLDEFAULT0,updated_atTIMESTAMPNOTNULLDEFAULTCURRENT_TIMESTAMP);CREATETABLEpurchase_order(idBIGINTGENERATEDBYDEFAULTASIDENTITYPRIMARYKEY,order_noVARCHAR(64)NOTNULLUNIQUE,skuVARCHAR(64)NOTNULL,quantityINTEGERNOTNULLCHECK(quantity0),statusVARCHAR(32)NOTNULL,created_atTIMESTAMPNOTNULLDEFAULTCURRENT_TIMESTAMP);CREATEINDEXidx_purchase_order_skuONpurchase_order(sku);這里我沒有給兩表加外鍵.不是說外鍵不能用,而是訂單記錄往往要保留業務發生時的 SKU,即使商品后來下架也不能讓歷史訂單消失.是否加外鍵應該服從業務生命周期,不能為了讓演示看起來規范硬綁關系.version字段也要解釋清楚本文只是讓它隨庫存變化遞增,方便觀察更新次數;真正防止超賣的是后面那條帶庫存條件的原子UPDATE,不能把這個字段包裝成已經實現了完整的樂觀鎖.五、接入JDBC:我踩到的不是代碼坑,而是依賴來源坑按慣性在 Maven Central 中寫一個驅動坐標,很可能得到依賴不存在的錯誤.我實際檢查時,com.kingbase8:kingbase8:9.0.0并不能從 Maven Central 直接取得.解決方法是使用官網下載的 JDBC 包,并把 jar 安裝到本機 Maven 倉庫;團隊環境則更適合上傳到公司 Nexus/Artifactory,統一管理版本.mvn install:install-file\-Dfilekingbase8-9.0.0.jar\-DgroupIdcom.kingbase8\-DartifactIdkingbase8\-Dversion9.0.0\-Dpackagingjarpom.xml的核心依賴如下parentgroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-parent/artifactIdversion3.5.16/version/parentpropertiesjava.version17/java.versionmybatis-spring-boot.version3.0.5/mybatis-spring-boot.version/propertiesdependenciesdependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependencydependencygroupIdorg.mybatis.spring.boot/groupIdartifactIdmybatis-spring-boot-starter/artifactIdversion${mybatis-spring-boot.version}/version/dependencydependencygroupIdcom.kingbase8/groupIdartifactIdkingbase8/artifactIdversion9.0.0/version/dependency/dependenciesSpring Boot 與 MyBatis 的版本并不是隨手拼的.Spring Boot 3.5.x 要求至少 Java 17;MyBatis Spring Boot Starter 3.0 系列覆蓋 Boot 3.23.5 和 Java 17 及以上.跨數據庫適配時,先把框架版本關系固定住,能避免把框架兼容問題誤診成數據庫問題.六、數據源配置:驅動類和URL都要換,密碼不要落盤我的application.yml如下spring:datasource:url:jdbc:kingbase8://localhost:54321/order_demousername:${KES_USERNAME:order_app}password:${KES_PASSWORD}driver-class-name:com.kingbase8.Driverhikari:maximum-pool-size:5minimum-idle:1connection-timeout:3000connection-test-query:SELECT 1mybatis:mapper-locations:classpath:/mapper/*.xmlconfiguration:map-underscore-to-camel-case:truelog-impl:org.apache.ibatis.logging.stdout.StdOutImpl啟動前用環境變量傳入口令exportKES_USERNAMEorder_appexportKES_PASSWORD業務賬號強密碼mvn spring-boot:run一開始我只看見 Spring Boot 正常啟動,還不敢把它算作驗證通過,于是專門寫了一個/api/database/info接口,從當前連接查詢數據庫版本、數據庫名和用戶.實際返回的是KingbaseES V009R001C010、order_demo、order_app.這一步能排除“應用其實連到了本機另一個 PostgreSQL 實例”之類的低級誤判.七、CRUD核心:主鍵回填、分頁和安全更新都走一遍MyBatis 接口沒有特殊注解技巧,真正決定適配性的仍然是SQL.新增商品使用 identity 主鍵,并讓驅動把生成的 id 回填到 Java 對象insertidinsertuseGeneratedKeystruekeyPropertyidINSERT INTO product_stock (sku, product_name, available_stock) VALUES (#{sku}, #{productName}, #{availableStock})/insertselectidselectPageresultTypecom.example.kingbase.domain.ProductStockSELECT id, sku, product_name, available_stock, version, updated_at FROM product_stock ORDER BY id LIMIT #{limit} OFFSET #{offset}/selectupdateidadjustStockUPDATE product_stock SET available_stock available_stock #{delta}, version version 1, updated_at CURRENT_TIMESTAMP WHERE sku #{sku} AND available_stock #{delta} 0/updatedeleteiddeleteBySkuDELETE FROM product_stock WHERE sku #{sku}/delete我給 REST 層準備了五組動作新增商品、按 SKU 查詢、分頁查詢、調整庫存、刪除商品.page和size沒有直接原樣傳給 SQL頁碼最小為1,每頁限制在 1100 之間,再計算OFFSET.這不是金倉獨有的要求,而是換庫時很容易順手遺漏的輸入邊界.# 新增curl-XPOST http://localhost:8080/api/products\-HContent-Type: application/json\-d{sku:KB-DEMO-001,productName:金倉數據庫實戰課,initialStock:10}# 加 5 個庫存curl-XPATCH http://localhost:8080/api/products/KB-DEMO-001/stock\-HContent-Type: application/json\-d{delta:5}# 分頁、刪除curlhttp://localhost:8080/api/products?page1size20curl-XDELETE http://localhost:8080/api/products/KB-TEMP-001實測中,首條商品返回id1,說明生成主鍵成功回填;庫存從10調到15,version從0變為1;臨時商品刪除返回 204,再查詢返回 404;重復SKU被統一映射為409,沒有把長串數據庫異常直接甩給前端.到這里可以確認普通 CRUD 沒問題,但這仍然只完成了基本可用.對訂單系統來說,下面兩項才是我最關心的.八、事務實測:先寫訂單、后扣庫存,失敗時能否一起撤銷訂單創建故意采用先插入訂單,再扣庫存的順序.這樣只要扣減失敗,最容易暴露事務是否真的生效.核心服務代碼如下ServicepublicclassOrderService{privatefinalPurchaseOrderMapperpurchaseOrderMapper;privatefinalProductStockMapperproductStockMapper;publicOrderService(PurchaseOrderMapperpurchaseOrderMapper,ProductStockMapperproductStockMapper){this.purchaseOrderMapperpurchaseOrderMapper;this.productStockMapperproductStockMapper;}TransactionalpublicPurchaseOrdercreate(CreateOrderRequestrequest){PurchaseOrderordernewPurchaseOrder();order.setOrderNo(request.orderNo());order.setSku(request.sku());order.setQuantity(request.quantity());order.setStatus(CREATED);purchaseOrderMapper.insert(order);intaffectedproductStockMapper.deductStock(request.sku(),request.quantity());if(affected!1){thrownewAppException(HttpStatus.CONFLICT,庫存不足或商品不存在);}returnrequireByOrderNo(request.orderNo());}}扣庫存不是先查余額,再在Java里判斷,再更新.那種寫法在并發下有時間窗口.我把條件放進同一條 SQLupdateiddeductStockUPDATE product_stock SET available_stock available_stock - #{quantity}, version version 1, updated_at CURRENT_TIMESTAMP WHERE sku #{sku} AND available_stock #{quantity}/update先用數量 3 創建訂單,HTTP 返回 201,庫存由15變為12.隨后用數量99創建ORD-ROLLBACK-001,接口返回 409.關鍵不是報錯本身,而是我再進數據庫查該訂單數量為 0,庫存仍是 12.說明前面已經執行的INSERT確實隨運行時異常回滾了,Spring 事務管理器、JDBC 驅動和 KingbaseES 的事務協作符合預期.這里還有一個常見誤區把Transactional加在同類內部調用的方法上,然后從另一個普通方法用this.create()調它.此時可能繞過 Spring 代理,注解看著在,事務卻沒進去.我的事務方法放在獨立Service的 public 方法上,由 Controller 經 Spring Bean 調用,避免了自調用失效.九、并發實測:10個庫存,同時來兩個買7個事務回滾通過后,我把庫存重置為10,同時發出兩筆各買7個的請求.理論上最多只能成功一筆;如果代碼存在先查后改的競態,兩筆都可能讀到10,最終產生超賣.curl-s-o/tmp/order-a.json-w%{http_code}\-XPOST http://localhost:8080/api/orders\-HContent-Type: application/json\-d{orderNo:ORD-CONCURRENT-A,sku:KB-DEMO-001,quantity:7}curl-s-o/tmp/order-b.json-w%{http_code}\-XPOST http://localhost:8080/api/orders\-HContent-Type: application/json\-d{orderNo:ORD-CONCURRENT-B,sku:KB-DEMO-001,quantity:7}wait實測結果是一筆 201、一筆 409;數據庫里只留下成功訂單,最終庫存為3,沒有負數,也沒有失敗訂單殘留.具體是哪一筆成功并不重要,調度順序本來就不應成為業務假設.這個方案依賴數據庫對單條條件更新的原子性,簡單而有效.如果業務還要處理多 SKU 鎖定、限時釋放、跨服務消息等場景,就需要繼續設計鎖順序、冪等鍵和補償機制;不能因為這個小測試通過,就推導出所有并發問題都解決了.十、三個遷移時很容易撞上的SQL坑為了確認兼容邊界,我沒有只跑正確 SQL,還把幾段常見的遷移語句故意送進數據庫.1. AUTO_INCREMENT不能照搬在本次 PG 兼容模式下執行CREATETABLEmysql_style(idBIGINTAUTO_INCREMENTPRIMARYKEY);數據庫在AUTO_INCREMENT附近報語法錯誤.我的處理是改成GENERATED BY DEFAULT AS IDENTITY.如果從MySQL遷移,除了 DDL,還要全量檢查ON DUPLICATE KEY UPDATE、反引號、無符號類型、時間函數等方言,不要等應用上線后逐條踩雷.2. order是保留字CREATE TABLE order (...)直接報錯.可以寫成帶雙引號的order,但之后每條 SQL 都得正確引用,維護成本很高.我最終把表名改成purchase_order.數據庫遷移里,改一個不沖突的業務名通常比到處加引號穩妥.3. 未加引號的標識符會折疊為小寫我創建了CaseDemo,再執行不帶引號的SELECT * FROM CaseDemo,實際查找的是casedemo,于是報關系不存在;寫成SELECT * FROM CaseDemo才成功.解決辦法不是要求團隊記住每一個大小寫,而是從建表開始統一使用小寫蛇形命名,MyBatis 再通過map-underscore-to-camel-case映射為 Java 駝峰字段.這三項都不是數據庫不好用,而是源庫方言和目標庫規則不同.有效的遷移流程應該先掃描對象和 SQL,再做兼容改寫,最后用回歸測試驗證,而不是把連接串換完就上線.十一、我是怎樣判斷這次適配真的完成了最終我給自己列了一張比應用啟動成功更嚴格的驗收表檢查項實測結果關注點原生架構通過鏡像與容器均為 aarch64JDBC 連接通過返回 KingbaseES 版本、業務庫和業務用戶新增與主鍵回填通過identity 主鍵回填id1查詢與分頁通過LIMIT/OFFSET正常參數有限界更新與刪除通過庫存不降為負數刪除后返回 404唯一鍵異常通過重復 SKU 轉為 409未暴露內部異常本地事務通過扣庫存失敗后訂單行回滾并發扣減通過10 個庫存下兩筆 7 個僅一筆成功構建與上下文測試通過1 個測試0 失敗、0 錯誤項目最后執行mvn test,Spring 上下文能夠用 JDK 17 啟動,測試結果為Tests run: 1, Failures: 0, Errors: 0,構建成功.如果要把這個示例推進到生產,我還會補四件事第一,用 Flyway 或 Liquibase 管理版本化 DDL,而不是人工執行腳本;第二,在測試環境用Testcontainers 或專用 KingbaseES 實例跑集成測試;第三,根據壓測結果設置連接池、慢 SQL 與超時,不照抄本文的5個連接;第四,梳理原系統的數據庫特有語法、存儲過程和類型映射,建立可重復執行的兼容清單.十二、回頭看:框架改動不大,驗證方式才是重點這次實測給我的結論很樸素對于采用常規 SQL 的 Spring Boot MyBatis 項目,接入 KingbaseES 的 Java 代碼改動并不大,主要變化集中在官方 JDBC 驅動、連接 URL 和目標庫方言.真正花時間的地方,不是把數據源配上,而是確認那些以前默認成立的事情在新數據庫上仍然成立.比如,M4 是否只能模擬 x86,要用鏡像架構回答;主鍵能不能回填,要看新增接口返回;事務有沒有生效,要制造一次中途失敗再查庫;并發會不會超賣,要讓兩個請求真的撞在一起.把這些問題變成可觀察、可復現的小實驗,數據庫適配才從我覺得可以變成我驗證過可以.這也是我認為國產數據庫適配最值得保留的方法少一點根據相似性做推斷,多一點以官方介質、真實 SQL 和失敗場景為證據.連接成功值得高興,但敢于主動制造失敗,才更接近生產可用.參考資料KingbaseES 官網下載中心KingbaseES Docker 安裝手冊KingbaseES JDBC 使用文檔Spring Boot 3.5 系統要求MyBatis Spring Boot Starter 官方說明真正的勇者不是流淚的人,而是含淚奔跑的人!敬請期待下一篇文章內容每日心靈雞湯: 當你開始害怕別人不開心,其實是在保護過去的自己!當你因為他人語氣不好、態度不耐煩而下意識緊張、自我懷疑時,這往往不是當下的問題,而是過去經驗留下的自動反應.你曾經為了在不穩定的環境中保護自己,學會把別人的情緒當作一種危險信號,于是通過討好、壓抑來換取安全感.但這種機制只是童年時期的生存策略,并不適用于現在的你.真正重要的是意識到:當下的你已經有能力區分現實與過去,不需要再用過度敏感來保護自己.別人的情緒屬于他們自己,你不需要為此負責;你只需要穩住自己,專注于自己的感受與選擇. 【金倉數據庫征文】M4 Mac上把Spring Boot + MyBatis接到KingbaseES:一次帶事務和并發扣庫存的實測
承淵政道個人主頁??個人專欄:《C語言基礎語法知識》 《數據結構與算法》 《C知識內容》 《Linux系統知識》 《算法刷題指南》 《測評文章活動推廣》 《大模型語言路線學習》 《MySQL數據庫學習》 《Python知識內容》?逆境不吐心中苦,順境不忘來時路!? 博主簡介:過去做數據庫適配時,我最常見的做法是修改 JDBC 驅動和連接地址,應用能夠啟動、SELECT 1可以執行,就先把數據庫已適配打上勾.但真正把業務代碼跑起來后才會發現,連接成功只是第一關:主鍵生成方式、分頁語法、保留字、標識符大小寫、事務回滾以及并發更新,都可能在后面埋坑.這次我選擇了一個更貼近實際開發的場景:在M4 Mac上運行 KingbaseES,用Spring Boot 3.5 MyBatis 3.0實現商品庫存和訂單接口.除了完成基本CRUD,我還特意制造了庫存不足和并發搶購兩個失敗場景,檢查訂單能否正確回滾,以及庫存會不會被扣成負數.整個過程并非一路順利.我原以為M4需要通過AMD64模擬運行數據庫,實際卻在官網下載到了原生 aarch64 鏡像;按照平時的習慣啟動容器,又在日志中碰到了權限告警;把MySQL DDL 直接搬過來時,AUTO_INCREMENT、保留字和大小寫問題也接連出現.本文記錄的就是這些真實操作、排查過程和解決辦法,希望能給正在進行國產數據庫適配的Java開發者提供一份可以直接參考的實測記錄.目錄一、我想驗證的,不只是能不能連上二、環境準備:M4可以直接跑ARM64版本三、第一次啟動的小坑:容器能跑,不代表啟動參數規范四、表結構先適配:別把MySQL DDL原封不動搬過來五、接入JDBC:我踩到的不是代碼坑,而是依賴來源坑六、數據源配置:驅動類和URL都要換,密碼不要落盤七、CRUD核心:主鍵回填、分頁和安全更新都走一遍八、事務實測:先寫訂單、后扣庫存,失敗時能否一起撤銷九、并發實測:10個庫存,同時來兩個買7個十、三個遷移時很容易撞上的SQL坑1. AUTO_INCREMENT不能照搬2. order是保留字3. 未加引號的標識符會折疊為小寫十一、我是怎樣判斷這次適配真的完成了十二、回頭看:框架改動不大,驗證方式才是重點參考資料一、我想驗證的,不只是能不能連上接觸一個不熟悉的數據庫時,最容易寫出的文章是建一個 Spring Boot 項目,改四行數據源配置,執行一條SELECT 1,然后宣布適配完成.但做過業務系統遷移的人都知道,連接成功只是起點.真正容易出問題的地方,往往藏在建表語法、主鍵回填、分頁、保留字、事務邊界和并發更新里.所以這次我沒有做Hello World,而是給自己定了一個更接近真實需求的小題目:用Spring Boot MyBatis寫一套商品庫存和訂單接口,覆蓋商品的增刪改查,再驗證兩個關鍵場景:訂單寫入后扣庫存失敗,訂單能否跟著回滾;兩個請求同時搶庫存時,會不會扣成負數.我原先還有一個判斷:M4是ARM架構,可能只能拉 x86 鏡像后用模擬運行.實際下載時這個判斷就被推翻了——金倉官網已經提供 aarch64 Docker 包.這個小插曲也提醒我,數據庫適配不要憑過去的印象寫方案,先以當前版本的官方介質為準.二、環境準備:M4可以直接跑ARM64版本我的本機環境如下.JDK選擇17,是因為本文使用Spring Boot 3.5.x;Docker 服務端本身也是 arm64.Hardware: Apple M4 / arm64 macOS: 26.6 Docker Engine: 29.6.2 / linux-arm64 Java: OpenJDK 17.0.20 Maven: 3.9.16我從金倉數據庫官網下載中心取得兩個文件KingbaseES_V009R001C010B0004_aarch64_Docker.tarKingbaseES_V009R001C010B0004_JDBC.zip這里要留意,Docker 數據庫鏡像和 JDBC 驅動是兩個獨立下載項,不能假設鏡像包里一定帶著應用側要用的 jar.下載后我先校驗了官網給出的 MD5,再加載鏡像md5 KingbaseES_V009R001C010B0004_aarch64_Docker.tar md5 KingbaseES_V009R001C010B0004_JDBC.zipdockerload-iKingbaseES_V009R001C010B0004_aarch64_Docker.tardockerimage inspect kingbase_v009r001c010b0004_single_arm:v1\--format{{.Os}}/{{.Architecture}}最后一條返回linux/arm64,不是通過 Rosetta 或 QEMU 跑起來的 AMD64 鏡像.對M系列Mac 來說,少一層模擬,啟動速度和資源占用都更踏實.三、第一次啟動的小坑:容器能跑,不代表啟動參數規范我第一次照著常見數據庫容器的方式啟動,沒有加--privileged.數據庫最終雖然起來了,日志中卻出現sudo: pam_open_session: Permission denied這類告警很容易被數據庫已經能連接掩蓋.我回看官方 Docker 安裝手冊,重新按容器運行要求創建,并把宿主機 54321 映射到容器 54321dockerrun-d\--namekes-v9-dev\--privileged\-p54321:54321\-eDB_MODEpg\-eDB_USERsystem\-eDB_PASSWORD初始化強密碼\-eNEED_STARTyes\-v本機數據目錄:/home/kingbase/userdata\kingbase_v009r001c010b0004_single_arm:v1DB_MODEpg表示這次按 PG 兼容模式驗證.掛載目錄不要隨便指向臨時路徑,否則刪容器后測試數據也一起沒了.口令也不要寫進 Git、文章附件或鏡像層,本文后面的應用配置統一從環境變量讀取.重新啟動后,日志出現server started.我又進入容器核對架構和客戶端版本,結果分別是aarch64與ksql (KingbaseES) V009R001C010.接著創建獨立業務用戶和數據庫.開發項目不要長期拿初始化管理員賬號直連,哪怕只是本機演示也應把這個習慣保留下來.CREATEUSERorder_appWITHPASSWORD業務賬號強密碼;CREATEDATABASEorder_demo OWNER order_app;四、表結構先適配:別把MySQL DDL原封不動搬過來示例只有兩張表product_stock保存可用庫存,purchase_order保存訂單.主鍵使用標準的 identity 寫法,庫存和數量則用CHECK保住數據底線.CREATETABLEproduct_stock(idBIGINTGENERATEDBYDEFAULTASIDENTITYPRIMARYKEY,skuVARCHAR(64)NOTNULLUNIQUE,product_nameVARCHAR(128)NOTNULL,available_stockINTEGERNOTNULLCHECK(available_stock0),versionINTEGERNOTNULLDEFAULT0,updated_atTIMESTAMPNOTNULLDEFAULTCURRENT_TIMESTAMP);CREATETABLEpurchase_order(idBIGINTGENERATEDBYDEFAULTASIDENTITYPRIMARYKEY,order_noVARCHAR(64)NOTNULLUNIQUE,skuVARCHAR(64)NOTNULL,quantityINTEGERNOTNULLCHECK(quantity0),statusVARCHAR(32)NOTNULL,created_atTIMESTAMPNOTNULLDEFAULTCURRENT_TIMESTAMP);CREATEINDEXidx_purchase_order_skuONpurchase_order(sku);這里我沒有給兩表加外鍵.不是說外鍵不能用,而是訂單記錄往往要保留業務發生時的 SKU,即使商品后來下架也不能讓歷史訂單消失.是否加外鍵應該服從業務生命周期,不能為了讓演示看起來規范硬綁關系.version字段也要解釋清楚本文只是讓它隨庫存變化遞增,方便觀察更新次數;真正防止超賣的是后面那條帶庫存條件的原子UPDATE,不能把這個字段包裝成已經實現了完整的樂觀鎖.五、接入JDBC:我踩到的不是代碼坑,而是依賴來源坑按慣性在 Maven Central 中寫一個驅動坐標,很可能得到依賴不存在的錯誤.我實際檢查時,com.kingbase8:kingbase8:9.0.0并不能從 Maven Central 直接取得.解決方法是使用官網下載的 JDBC 包,并把 jar 安裝到本機 Maven 倉庫;團隊環境則更適合上傳到公司 Nexus/Artifactory,統一管理版本.mvn install:install-file\-Dfilekingbase8-9.0.0.jar\-DgroupIdcom.kingbase8\-DartifactIdkingbase8\-Dversion9.0.0\-Dpackagingjarpom.xml的核心依賴如下parentgroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-parent/artifactIdversion3.5.16/version/parentpropertiesjava.version17/java.versionmybatis-spring-boot.version3.0.5/mybatis-spring-boot.version/propertiesdependenciesdependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependencydependencygroupIdorg.mybatis.spring.boot/groupIdartifactIdmybatis-spring-boot-starter/artifactIdversion${mybatis-spring-boot.version}/version/dependencydependencygroupIdcom.kingbase8/groupIdartifactIdkingbase8/artifactIdversion9.0.0/version/dependency/dependenciesSpring Boot 與 MyBatis 的版本并不是隨手拼的.Spring Boot 3.5.x 要求至少 Java 17;MyBatis Spring Boot Starter 3.0 系列覆蓋 Boot 3.23.5 和 Java 17 及以上.跨數據庫適配時,先把框架版本關系固定住,能避免把框架兼容問題誤診成數據庫問題.六、數據源配置:驅動類和URL都要換,密碼不要落盤我的application.yml如下spring:datasource:url:jdbc:kingbase8://localhost:54321/order_demousername:${KES_USERNAME:order_app}password:${KES_PASSWORD}driver-class-name:com.kingbase8.Driverhikari:maximum-pool-size:5minimum-idle:1connection-timeout:3000connection-test-query:SELECT 1mybatis:mapper-locations:classpath:/mapper/*.xmlconfiguration:map-underscore-to-camel-case:truelog-impl:org.apache.ibatis.logging.stdout.StdOutImpl啟動前用環境變量傳入口令exportKES_USERNAMEorder_appexportKES_PASSWORD業務賬號強密碼mvn spring-boot:run一開始我只看見 Spring Boot 正常啟動,還不敢把它算作驗證通過,于是專門寫了一個/api/database/info接口,從當前連接查詢數據庫版本、數據庫名和用戶.實際返回的是KingbaseES V009R001C010、order_demo、order_app.這一步能排除“應用其實連到了本機另一個 PostgreSQL 實例”之類的低級誤判.七、CRUD核心:主鍵回填、分頁和安全更新都走一遍MyBatis 接口沒有特殊注解技巧,真正決定適配性的仍然是SQL.新增商品使用 identity 主鍵,并讓驅動把生成的 id 回填到 Java 對象insertidinsertuseGeneratedKeystruekeyPropertyidINSERT INTO product_stock (sku, product_name, available_stock) VALUES (#{sku}, #{productName}, #{availableStock})/insertselectidselectPageresultTypecom.example.kingbase.domain.ProductStockSELECT id, sku, product_name, available_stock, version, updated_at FROM product_stock ORDER BY id LIMIT #{limit} OFFSET #{offset}/selectupdateidadjustStockUPDATE product_stock SET available_stock available_stock #{delta}, version version 1, updated_at CURRENT_TIMESTAMP WHERE sku #{sku} AND available_stock #{delta} 0/updatedeleteiddeleteBySkuDELETE FROM product_stock WHERE sku #{sku}/delete我給 REST 層準備了五組動作新增商品、按 SKU 查詢、分頁查詢、調整庫存、刪除商品.page和size沒有直接原樣傳給 SQL頁碼最小為1,每頁限制在 1100 之間,再計算OFFSET.這不是金倉獨有的要求,而是換庫時很容易順手遺漏的輸入邊界.# 新增curl-XPOST http://localhost:8080/api/products\-HContent-Type: application/json\-d{sku:KB-DEMO-001,productName:金倉數據庫實戰課,initialStock:10}# 加 5 個庫存curl-XPATCH http://localhost:8080/api/products/KB-DEMO-001/stock\-HContent-Type: application/json\-d{delta:5}# 分頁、刪除curlhttp://localhost:8080/api/products?page1size20curl-XDELETE http://localhost:8080/api/products/KB-TEMP-001實測中,首條商品返回id1,說明生成主鍵成功回填;庫存從10調到15,version從0變為1;臨時商品刪除返回 204,再查詢返回 404;重復SKU被統一映射為409,沒有把長串數據庫異常直接甩給前端.到這里可以確認普通 CRUD 沒問題,但這仍然只完成了基本可用.對訂單系統來說,下面兩項才是我最關心的.八、事務實測:先寫訂單、后扣庫存,失敗時能否一起撤銷訂單創建故意采用先插入訂單,再扣庫存的順序.這樣只要扣減失敗,最容易暴露事務是否真的生效.核心服務代碼如下ServicepublicclassOrderService{privatefinalPurchaseOrderMapperpurchaseOrderMapper;privatefinalProductStockMapperproductStockMapper;publicOrderService(PurchaseOrderMapperpurchaseOrderMapper,ProductStockMapperproductStockMapper){this.purchaseOrderMapperpurchaseOrderMapper;this.productStockMapperproductStockMapper;}TransactionalpublicPurchaseOrdercreate(CreateOrderRequestrequest){PurchaseOrderordernewPurchaseOrder();order.setOrderNo(request.orderNo());order.setSku(request.sku());order.setQuantity(request.quantity());order.setStatus(CREATED);purchaseOrderMapper.insert(order);intaffectedproductStockMapper.deductStock(request.sku(),request.quantity());if(affected!1){thrownewAppException(HttpStatus.CONFLICT,庫存不足或商品不存在);}returnrequireByOrderNo(request.orderNo());}}扣庫存不是先查余額,再在Java里判斷,再更新.那種寫法在并發下有時間窗口.我把條件放進同一條 SQLupdateiddeductStockUPDATE product_stock SET available_stock available_stock - #{quantity}, version version 1, updated_at CURRENT_TIMESTAMP WHERE sku #{sku} AND available_stock #{quantity}/update先用數量 3 創建訂單,HTTP 返回 201,庫存由15變為12.隨后用數量99創建ORD-ROLLBACK-001,接口返回 409.關鍵不是報錯本身,而是我再進數據庫查該訂單數量為 0,庫存仍是 12.說明前面已經執行的INSERT確實隨運行時異常回滾了,Spring 事務管理器、JDBC 驅動和 KingbaseES 的事務協作符合預期.這里還有一個常見誤區把Transactional加在同類內部調用的方法上,然后從另一個普通方法用this.create()調它.此時可能繞過 Spring 代理,注解看著在,事務卻沒進去.我的事務方法放在獨立Service的 public 方法上,由 Controller 經 Spring Bean 調用,避免了自調用失效.九、并發實測:10個庫存,同時來兩個買7個事務回滾通過后,我把庫存重置為10,同時發出兩筆各買7個的請求.理論上最多只能成功一筆;如果代碼存在先查后改的競態,兩筆都可能讀到10,最終產生超賣.curl-s-o/tmp/order-a.json-w%{http_code}\-XPOST http://localhost:8080/api/orders\-HContent-Type: application/json\-d{orderNo:ORD-CONCURRENT-A,sku:KB-DEMO-001,quantity:7}curl-s-o/tmp/order-b.json-w%{http_code}\-XPOST http://localhost:8080/api/orders\-HContent-Type: application/json\-d{orderNo:ORD-CONCURRENT-B,sku:KB-DEMO-001,quantity:7}wait實測結果是一筆 201、一筆 409;數據庫里只留下成功訂單,最終庫存為3,沒有負數,也沒有失敗訂單殘留.具體是哪一筆成功并不重要,調度順序本來就不應成為業務假設.這個方案依賴數據庫對單條條件更新的原子性,簡單而有效.如果業務還要處理多 SKU 鎖定、限時釋放、跨服務消息等場景,就需要繼續設計鎖順序、冪等鍵和補償機制;不能因為這個小測試通過,就推導出所有并發問題都解決了.十、三個遷移時很容易撞上的SQL坑為了確認兼容邊界,我沒有只跑正確 SQL,還把幾段常見的遷移語句故意送進數據庫.1. AUTO_INCREMENT不能照搬在本次 PG 兼容模式下執行CREATETABLEmysql_style(idBIGINTAUTO_INCREMENTPRIMARYKEY);數據庫在AUTO_INCREMENT附近報語法錯誤.我的處理是改成GENERATED BY DEFAULT AS IDENTITY.如果從MySQL遷移,除了 DDL,還要全量檢查ON DUPLICATE KEY UPDATE、反引號、無符號類型、時間函數等方言,不要等應用上線后逐條踩雷.2. order是保留字CREATE TABLE order (...)直接報錯.可以寫成帶雙引號的order,但之后每條 SQL 都得正確引用,維護成本很高.我最終把表名改成purchase_order.數據庫遷移里,改一個不沖突的業務名通常比到處加引號穩妥.3. 未加引號的標識符會折疊為小寫我創建了CaseDemo,再執行不帶引號的SELECT * FROM CaseDemo,實際查找的是casedemo,于是報關系不存在;寫成SELECT * FROM CaseDemo才成功.解決辦法不是要求團隊記住每一個大小寫,而是從建表開始統一使用小寫蛇形命名,MyBatis 再通過map-underscore-to-camel-case映射為 Java 駝峰字段.這三項都不是數據庫不好用,而是源庫方言和目標庫規則不同.有效的遷移流程應該先掃描對象和 SQL,再做兼容改寫,最后用回歸測試驗證,而不是把連接串換完就上線.十一、我是怎樣判斷這次適配真的完成了最終我給自己列了一張比應用啟動成功更嚴格的驗收表檢查項實測結果關注點原生架構通過鏡像與容器均為 aarch64JDBC 連接通過返回 KingbaseES 版本、業務庫和業務用戶新增與主鍵回填通過identity 主鍵回填id1查詢與分頁通過LIMIT/OFFSET正常參數有限界更新與刪除通過庫存不降為負數刪除后返回 404唯一鍵異常通過重復 SKU 轉為 409未暴露內部異常本地事務通過扣庫存失敗后訂單行回滾并發扣減通過10 個庫存下兩筆 7 個僅一筆成功構建與上下文測試通過1 個測試0 失敗、0 錯誤項目最后執行mvn test,Spring 上下文能夠用 JDK 17 啟動,測試結果為Tests run: 1, Failures: 0, Errors: 0,構建成功.如果要把這個示例推進到生產,我還會補四件事第一,用 Flyway 或 Liquibase 管理版本化 DDL,而不是人工執行腳本;第二,在測試環境用Testcontainers 或專用 KingbaseES 實例跑集成測試;第三,根據壓測結果設置連接池、慢 SQL 與超時,不照抄本文的5個連接;第四,梳理原系統的數據庫特有語法、存儲過程和類型映射,建立可重復執行的兼容清單.十二、回頭看:框架改動不大,驗證方式才是重點這次實測給我的結論很樸素對于采用常規 SQL 的 Spring Boot MyBatis 項目,接入 KingbaseES 的 Java 代碼改動并不大,主要變化集中在官方 JDBC 驅動、連接 URL 和目標庫方言.真正花時間的地方,不是把數據源配上,而是確認那些以前默認成立的事情在新數據庫上仍然成立.比如,M4 是否只能模擬 x86,要用鏡像架構回答;主鍵能不能回填,要看新增接口返回;事務有沒有生效,要制造一次中途失敗再查庫;并發會不會超賣,要讓兩個請求真的撞在一起.把這些問題變成可觀察、可復現的小實驗,數據庫適配才從我覺得可以變成我驗證過可以.這也是我認為國產數據庫適配最值得保留的方法少一點根據相似性做推斷,多一點以官方介質、真實 SQL 和失敗場景為證據.連接成功值得高興,但敢于主動制造失敗,才更接近生產可用.參考資料KingbaseES 官網下載中心KingbaseES Docker 安裝手冊KingbaseES JDBC 使用文檔Spring Boot 3.5 系統要求MyBatis Spring Boot Starter 官方說明真正的勇者不是流淚的人,而是含淚奔跑的人!敬請期待下一篇文章內容每日心靈雞湯: 當你開始害怕別人不開心,其實是在保護過去的自己!當你因為他人語氣不好、態度不耐煩而下意識緊張、自我懷疑時,這往往不是當下的問題,而是過去經驗留下的自動反應.你曾經為了在不穩定的環境中保護自己,學會把別人的情緒當作一種危險信號,于是通過討好、壓抑來換取安全感.但這種機制只是童年時期的生存策略,并不適用于現在的你.真正重要的是意識到:當下的你已經有能力區分現實與過去,不需要再用過度敏感來保護自己.別人的情緒屬于他們自己,你不需要為此負責;你只需要穩住自己,專注于自己的感受與選擇.