簡介InterBase 6.0 數(shù)據庫安裝包與開發(fā)示例合集面向使用 Delphi 6 構建客戶端/服務器數(shù)據庫應用的開發(fā)者及數(shù)據庫學習者可用于搭建本地測試環(huán)境、研究早期 RDBMS 的部署結構與 API 調用方式。壓縮包共 130 個文件約 4.86MB含 33 個 C 源碼、15 個可執(zhí)行程序、8 個動態(tài)庫以及頭文件、庫文件、幫助文檔、SQL 腳本和 gdb、gbk 示例數(shù)據庫覆蓋安裝、卸載、運行配置與基礎數(shù)據操作。已有 341 人學習下載對遺留系統(tǒng)維護和舊版 Delphi 數(shù)據訪問研究仍有參考價值。讀者可獲得較完整的安裝組件、數(shù)據庫引擎依賴文件、編程接口示例和初始數(shù)據庫樣本便于理解 BDE、ODBC 等連接方式背后的文件組成也可用于排查舊項目運行環(huán)境缺失、數(shù)據庫初始化與許可配置等問題。1. 接手一個只剩 .GDB 文件的老系統(tǒng)才明白 InterBase 6.0 是什么形態(tài)交付包里沒有安裝手冊只有一個 4MB 出頭的.GDB文件和一堆 Delphi 控件源碼這是不少人第一次接觸 InterBase 6.0 時的真實場景。它并不是那種需要獨立 DBA 運維的數(shù)據庫服務整個庫就是一個文件拷到目標機器、配好連接串、把控件拖到窗體上就能讀寫。這份資源的價值也在這里服務端、客戶端連接庫、控件源碼和示例應用湊成一套拿下來就能把一個數(shù)據庫應用從前端到存儲層全部跑通。這篇按我拆包的順序寫先講清 InterBase 6.0 的事務模型和文件組織再把它在本機跑起來然后把生成器、觸發(fā)器、存儲過程、UDF 這幾塊核心實現(xiàn)逐段拆開最后落在「拿到控件源碼之后改哪里」這個實際問題上。手里攥著老項目要維護的人和想拿一個輕量嵌入式數(shù)據庫練手的人都能照著走一遍。2. 技術底座MGA 架構下的事務版本與頁面組織2.1 多代版本架構讀不擋寫寫不擋讀先糾正一個很容易帶偏的認知InterBase 6.0 不是靠回滾段做并發(fā)的。執(zhí)行 UPDATE 時它不原地覆蓋那一行而是把記錄的新版本寫進數(shù)據頁舊版本留在原處只在記錄頭里把「替換事務號」標成當前事務。別的讀事務只要自己的快照事務號比這個替換號小就繼續(xù)讀到舊版本一點都不會被卡住。這就是所謂多代版本架構MGA它的直接結果是讀事務永遠不用等寫事務寫事務也不會因為有人在掃表而排隊。沒有回滾段帶來的另一個差別在回滾語義上。執(zhí)行 ROLLBACK 時數(shù)據庫并不做「反向補償」它只是把那個事務在事務清單里標記為已死這個事務寫下的所有版本立刻變成垃圾數(shù)據等著被回收。所以回滾一個剛插了十萬行的事務幾乎瞬間完成不會像日志型數(shù)據庫那樣還要回放一遍。這套設計的代價也很明確垃圾版本不會自動消失需要靠 sweep 機制回收而 sweep 能不能推進取決于「最老活躍事務」OIT和「最老事務」OAT這兩個水位線能不能往前走。這就引出了老項目里最典型的一類故障。只要有一個連接開著事務不提交——哪怕它只是SELECT了一下——OAT 就被釘在原地比它新的所有垃圾版本都回收不了庫文件只漲不縮查詢越來越慢。我在一個工控項目上見過庫文件從 200MB 漲到 3GB最后查出來是一個報表模塊的TIBTransaction忘了Commit掛了半個月。所以看一個 InterBase 庫健不健康第一件事不是看數(shù)據量是看 OIT 和 OAT 差了多遠。還有一點要注意事務隔離級別在 InterBase 里是通過 TPB事務參數(shù)塊傳的isc_tpb_concurrency是快照隔離最常用isc_tpb_read_committed配isc_tpb_rec_version是讀已提交而isc_tpb_consistency會加表級鎖除非你在做批處理維護否則別碰它一旦用錯整個系統(tǒng)的并發(fā)直接降到單線程。2.2 單文件、頁與事務計數(shù)器的物理組成.GDB文件內部是按頁組織的頁大小在建庫時定死可選 1024、2048、4096、8192 字節(jié)。第 0 頁是數(shù)據庫頭記錄了頁大小、事務水位、影子文件信息往后是頁分配頁、事務清單頁TIP、指針頁、數(shù)據頁、索引頁和 BLOB 頁。理解這套分層最實用的工具是gstat它不做任何修改只讀取元信息。# 只看庫頭頁大小、OAT/OIT、下一個事務號、影子文件 gstat -h /opt/data/demo.gdb # 看數(shù)據頁的填充率和高水位判斷是不是碎片太多 gstat -d /opt/data/demo.gdb | more # 看索引深度深度從 3 變成 4 通常意味著索引膨脹 gstat -i /opt/data/demo.gdb-h的輸出里有幾個參數(shù)值得記住Page size決定了單頁能放多少行也間接決定了 BLOB 的讀取效率Oldest transaction就是 OATOldest active是 OIT兩者相差幾百以內算正常差到幾十萬說明有長事務在拖后腿Next transaction是一直遞增的事務號漲到 20 億附近會有溢出風險正規(guī)做法是做一次備份還原把事務號重置回低位。-d看的是數(shù)據頁的填充率如果大量頁只填了 30%說明刪除和更新留下的空洞多該做一次gbak備份還原把空間收回來。頁大小定下來之后想改唯一的辦法是gbak備份再gbak -c -p 8192還原沒有在線改的路徑。所以建庫前要想清楚如果表里有一堆VARCHAR(200)加上幾個 BLOB 字段用 4096 或 8192 能少很多跨頁讀如果只是幾百張配置表、單行很小1024 反而更省內存。單個文件大到一定程度就得拆成多文件-- 追加第二個數(shù)據文件起始頁號接在主文件之后 ALTER DATABASE ADD FILE /opt/data/demo_02.gdb STARTING AT PAGE 200000 LENGTH 200000;這條語句里的STARTING AT PAGE是主文件的頁號邊界不是字節(jié)數(shù)寫錯會導致新文件永遠用不上。我一般只在受文件系統(tǒng)單文件上限限制的場景下才拆拆完一定要用gstat -h確認Database files那一行變成了兩個否則等于白寫。2.3 服務形態(tài)本地直連還是 TCP 遠程InterBase 6.0 的一個特點是同一個客戶端庫既能連本地文件也能連遠程服務區(qū)別只在連接串怎么寫。這一點經常被忽略然后在部署時踩坑——因為遠程連接里那個路徑是「服務端視角」的不是你自己機器上的路徑。連接串寫法走的協(xié)議適用場景C:\data\demo.gdb本地直連單機工具、免裝服務端、數(shù)據不外發(fā)localhost:C:\data\demo.gdbTCP 回環(huán)本機調試但要驗證服務端權限和鎖192.168.1.20:C:\data\demo.gdbTCP 遠程多人共用一臺庫服務器srv01:/opt/data/demo.gdbTCP 遠程跨平臺部署服務端是 Linux本地直連省掉了網絡往返和權限校驗啟動快、部署簡單很適合隨應用程序一起分發(fā)的單機版。但它的并發(fā)模型比遠程弱得多多個進程同時寫同一個文件時鎖沖突會很難排查所以只要業(yè)務里有第二個人同時寫就別圖省事老老實實裝服務端走 TCP。遠程連接的另一個前提是服務名要能解析?？蛻舳藥炷J用gds_db這個服務名去找端口主機上必須有一行登記# 服務端和客戶端的 services 文件里都要有這行端口默認 3050 gds_db 3050/tcp # InterBase 服務名與監(jiān)聽端口 # 改完確認端口真的在監(jiān)聽 netstat -an | grep 3050注意客戶端報unavailable database時先別懷疑庫文件損壞八成是這行沒登記或者被防火墻攔了。3. 跑起來從服務啟動到控件發(fā)出第一個查詢3.1 安裝與最小可用配置服務端裝完之后要先確認三件事進程在跑、端口在聽、SYSDBA能登進去。很多人卡在第一步是因為把客戶端和服務端裝混了——客戶端只需要一個連接庫Windows 上是gds32.dll服務端才有后臺進程。# 1) 確認服務端進程存在 ps -ef | grep -i interbase # 2) 確認 3050 端口處于 LISTEN netstat -anp | grep 3050 # 3) 用命令行工具直連驗證 SYSDBA 能過 isql -user SYSDBA -password masterkeyisql是隨服務端一起提供的命令行客戶端它同時也是一個 SQL 腳本執(zhí)行器后面建庫、灌表結構、跑遷移腳本都靠它。第三步如果提示用戶名口令錯誤說明安裝時設的SYSDBA口令不是默認值得找當時的部署記錄如果提示unavailable database回到 2.3 節(jié)查服務名登記。Windows 上還有一個常見問題應用程序目錄里的gds32.dll和系統(tǒng)目錄里的版本不一致。客戶端庫的版本必須和服務端大致匹配混用不同版本時表現(xiàn)是能連上、能查詢但一取 BLOB 或者一調存儲過程就崩排查成本極高。我的習慣是把服務端自帶的那份客戶端庫直接拷到 exe 同目錄讓它優(yōu)先加載別指望系統(tǒng)的搜索路徑。3.2 isql 建庫建表跑通第一個庫CREATE DATABASE是客戶端工具語句不是服務端 SQL所以必須在isql里執(zhí)行。路徑同樣按服務端視角寫。# 建庫頁大小和字符集在這里定死后面改不了 isql -user SYSDBA -password masterkey EOF CREATE DATABASE /opt/data/demo.gdb USER SYSDBA PASSWORD masterkey PAGE_SIZE 8192 DEFAULT CHARACTER SET UNICODE_FSS; EOF # 灌表結構腳本開頭先 CONNECT保證連的是目標庫 isql -user SYSDBA -password masterkey -i schema.sqlschema.sql里第一句必須是CONNECT /opt/data/demo.gdb;后面才是 DDL。PAGE_SIZE和DEFAULT CHARACTER SET建庫時定死UNICODE_FSS是 6.0 里能存多字節(jié)字符的字符集存中文就別用NONE否則排序和長度計算都會出問題。建表這塊有兩個 6.0 時代特有的寫法值得用上DEFAULT NOW這種上下文變量以及 64 位整型主鍵。CONNECT /opt/data/demo.gdb; CREATE TABLE T_ORDER ( ID BIGINT NOT NULL, ORDER_NO VARCHAR(32) NOT NULL, AMOUNT NUMERIC(18,2) DEFAULT 0 NOT NULL, STATUS SMALLINT DEFAULT 0 NOT NULL, CREATED_AT TIMESTAMP DEFAULT NOW NOT NULL, CONSTRAINT PK_T_ORDER PRIMARY KEY (ID) ); -- 訂單號唯一單獨建索引查詢走索引而不是全表 CREATE UNIQUE INDEX IDX_ORDER_NO ON T_ORDER (ORDER_NO);DEFAULT NOW是服務端求值的取的是數(shù)據庫服務器時間不是客戶端時間這一點在跨時區(qū)的多客戶端場景里很關鍵——用客戶端賦時間會出現(xiàn)同一批數(shù)據時間倒掛。BIGINT是 64 位整型只在 dialect 3 下可用用它做主鍵是為了避免幾百萬行之后INTEGER溢出。NUMERIC(18,2)在 dialect 3 下映射到 64 位整型存儲精度不會丟做金額字段比DOUBLE PRECISION靠譜得多。3.3 控件對接連接、事務邊界與參數(shù)化查詢Delphi 那套控件里連 InterBase 最直接的是 IBXInterBase Express它不依賴 BDE直連客戶端庫部署時少一層中間件。核心是三個控件TIBDatabase管連接TIBTransaction管事務TIBQuery管數(shù)據集。// 數(shù)據庫連接路徑前綴決定走本地直連還是 TCP IBDB.DatabaseName : localhost:/opt/data/demo.gdb; IBDB.Params.Clear; IBDB.Params.Add(user_nameSYSDBA); IBDB.Params.Add(passwordmasterkey); IBDB.Params.Add(lc_ctypeUNICODE_FSS); // 必須和建庫時一致 IBDB.SQLDialect : 3; // dialect 對不上會報類型轉換錯 IBDB.LoginPrompt : False; IBDB.Connected : True; // 事務顯式控制別指望自動提交 IBTrans.DefaultDatabase : IBDB; IBTrans.Params.Clear; IBTrans.Params.Add(isc_tpb_write); // 讀寫事務 IBTrans.Params.Add(isc_tpb_concurrency); // 快照隔離讀不阻塞寫 IBTrans.Params.Add(isc_tpb_wait); // 遇鎖等待而不是立刻拋異常 IBTrans.StartTransaction;lc_ctype是客戶端字符集它必須和服務端建庫時的DEFAULT CHARACTER SET對上對不上的表現(xiàn)是中文變問號或者VARCHAR(32)明明只存了 20 個漢字卻報超長。isc_tpb_wait和isc_tpb_nowait的選擇直接影響用戶體驗nowait遇到鎖沖突立刻拋lock conflict on no wait transaction適合后臺批處理快速失敗wait會掛起等待適合交互界面。查詢部分建議全部走參數(shù)化別拼字符串IBQuery1.Close; IBQuery1.SQL.Text : SELECT ID, ORDER_NO, AMOUNT FROM T_ORDER WHERE STATUS :S AND CREATED_AT :D ORDER BY ID; IBQuery1.ParamByName(S).AsInteger : 1; IBQuery1.ParamByName(D).AsDateTime : Date - 7; IBQuery1.Open; while not IBQuery1.Eof do begin // 讀字段用 FieldByName別用下標后面加字段不會崩 Memo1.Lines.Add(IBQuery1.FieldByName(ORDER_NO).AsString); IBQuery1.Next; end; IBQuery1.Close; IBTrans.Commit; // 讀事務也要提交不然 OAT 卡住最后那句Commit是重點。IBX 里TIBTransaction默認不自動提交一個TIBQuery打開又關掉事務仍然是活的它對應的快照事務號就一直掛在 OIT 上。前面說的庫文件瘋長源頭往往就是這種「只讀了一下」的代碼。如果一次操作要寫多張表用TIBUpdateSQL配合TIBQuery的緩存更新把提交點收在業(yè)務動作結束那一刻比一條 SQL 一次提交安全得多。4. 核心模塊拆解生成器、觸發(fā)器、存儲過程與 UDF4.1 生成器與主鍵發(fā)號GEN_ID 的正確用法生成器Generator是 InterBase 里的獨立計數(shù)器和表無關專門用來發(fā)號。CREATE GENERATOR GEN_ORDER_ID; SET GENERATOR GEN_ORDER_ID TO 0; -- 取下一個號第二個參數(shù)是步長 SELECT GEN_ID(GEN_ORDER_ID, 1) FROM RDB$DATABASE;GEN_ID的第二個參數(shù)是增量正常情況下傳 1需要一次預留一段號比如批量導入時傳 N。RDB$DATABASE是系統(tǒng)表永遠只有一行用來把函數(shù)當查詢跑。這里有一個必須記住的性質生成器不受事務控制。取號這個動作在事務回滾后不會退回所以號一定有空洞。很多人拿它直接當訂單號展示給用戶看結果發(fā)現(xiàn)編號不連續(xù)被業(yè)務方追著問。我的做法是生成器只做物理主鍵業(yè)務單號單獨用「日期 序列」拼序列另有自己的表去維護。反過來如果業(yè)務真的要求連號那就不能靠生成器得在一張T_SEQ表上做UPDATE ... SET CUR CUR 1并配合行鎖代價是并發(fā)性能直線下降這個取舍要提前跟業(yè)務說清楚。4.2 觸發(fā)器把業(yè)務約束下沉到數(shù)據庫層觸發(fā)器在 InterBase 里分 BEFORE 和 AFTER還分行級和語句級。行級觸發(fā)器里能用NEW和OLD兩個上下文變量分別代表新值和舊值。-- 自定義異常拋出時客戶端能拿到這條消息 CREATE EXCEPTION E_AMOUNT_INVALID 訂單金額必須大于 0; -- 主鍵發(fā)號BEFORE INSERT在約束檢查之前把 ID 填上 CREATE TRIGGER TR_ORDER_BI FOR T_ORDER ACTIVE BEFORE INSERT POSITION 0 AS BEGIN IF (NEW.ID IS NULL) THEN NEW.ID GEN_ID(GEN_ORDER_ID, 1); END; -- 業(yè)務校驗POSITION 1 保證排在發(fā)號之后執(zhí)行 CREATE TRIGGER TR_ORDER_BIU FOR T_ORDER ACTIVE BEFORE INSERT OR UPDATE POSITION 1 AS BEGIN IF (NEW.AMOUNT 0) THEN EXCEPTION E_AMOUNT_INVALID; END;POSITION決定同一個表上多個同類觸發(fā)器的執(zhí)行順序編號小的先跑。上面這兩個觸發(fā)器必須按 0、1 排否則校驗里拿到的NEW.ID還是空。EXCEPTION拋出去之后客戶端TIBQuery會收到一條EIBErrorMessage里帶的就是E_AMOUNT_INVALID那條文本這是把校驗規(guī)則放在數(shù)據庫層最實際的好處——不管前端是 Delphi、Java 還是命令行工具規(guī)則都跑不掉。需要注意BEFORE 觸發(fā)器里改NEW的字段是有效的AFTER 觸發(fā)器里改就沒有意義了因為記錄已經落盤。另外語句級觸發(fā)器FOR EACH STATEMENT在行級操作里拿不到NEW/OLD它主要用來POST_EVENT做業(yè)務邏輯時千萬別用它。4.3 可選中存儲過程與事件通知存儲過程分兩種一種用EXECUTE PROCEDURE調用、只做副作用另一種帶SUSPEND可以被SELECT當表查叫可選中存儲過程。CREATE PROCEDURE SP_ORDER_LIST (P_STATUS SMALLINT) RETURNS (ID BIGINT, ORDER_NO VARCHAR(32), AMOUNT NUMERIC(18,2)) AS BEGIN FOR SELECT O.ID, O.ORDER_NO, O.AMOUNT FROM T_ORDER O WHERE O.STATUS :P_STATUS ORDER BY O.ID INTO :ID, :ORDER_NO, :AMOUNT DO SUSPEND; -- 每處理一行掛起一次客戶端才能逐行取到 END;SUSPEND是這段代碼的核心。沒有它存儲過程會把所有行算完只返回最后一組值有了它服務端每算出一行就掛起客戶端取一行再喚醒內存占用是常數(shù)級別的。FOR SELECT ... INTO里的變量名前必須加冒號這是 PSQL 里區(qū)分「字段名」和「變量名」的語法漏了冒號會報「列名不明確」。客戶端調用有兩種// 方式一當表查最靈活能帶排序和過濾 IBQuery1.SQL.Text : SELECT * FROM SP_ORDER_LIST(:S) ORDER BY ID; IBQuery1.ParamByName(S).AsInteger : 1; IBQuery1.Open; // 方式二TIBStoredProc適合無返回集的存儲過程 IBSP.StoredProcName : SP_ORDER_CLOSE; IBSP.ParamByName(P_ID).AsLargeInt : 1024; IBSP.ExecProc;配套的還有事件機制用來做「數(shù)據變了通知所有客戶端刷新」。服務端在觸發(fā)器里POST_EVENT客戶端注冊同名事件CREATE TRIGGER TR_ORDER_EVENT FOR T_ORDER ACTIVE AFTER INSERT OR UPDATE POSITION 0 AS BEGIN POST_EVENT ORDER_CHANGED; END;IBEvents1.Database : IBDB; IBEvents1.Events.Text : ORDER_CHANGED; // 多個事件名用換行分隔 IBEvents1.OnEventAlert : DoOrderChanged; IBEvents1.Registered : True; // 注冊之后服務端才會推POST_EVENT的名字建議用大寫短名老版本對事件名長度限制得比較緊不要寫成一句描述。更關鍵的是OnEventAlert回調是在客戶端庫的后臺線程里觸發(fā)的在里面直接操作 VCL 控件會因為跨線程訪問出玄學崩潰正確做法是TThread.Queue或者PostMessage把刷新動作丟回主線程。我第一次用事件通知時就在這里翻過車表現(xiàn)為「偶爾」崩查了兩天才定位到線程上。4.4 UDF拿到源碼后自己編一個外部函數(shù)庫內置函數(shù)不夠用時InterBase 支持外部函數(shù)UDF把 C 函數(shù)編成動態(tài)庫在數(shù)據庫里聲明之后就能在 SQL 里調用。/* myudf.c —— 編成動態(tài)庫后由服務端加載 */ #include string.h /* 參數(shù)用 CSTRING 聲明時收到的是以 \0 結尾的字符串指針 */ long STRLEN_UDF(char *s) { if (s NULL) return 0; return (long) strlen(s); }# Linux 下編成 .so位數(shù)必須和服務端一致32 位服務端只認 32 位庫 gcc -shared -fPIC -O2 -o myudf.so myudf.c # Windows 下編成 DLL cl /LD myudf.c /Fe:myudf.dll編出來之后丟到服務端的 UDF 目錄然后在庫里聲明DECLARE EXTERNAL FUNCTION STRLEN_UDF CSTRING(256) RETURNS INTEGER BY VALUE ENTRY_POINT STRLEN_UDF MODULE_NAME myudf;三個參數(shù)各有講究CSTRING(256)告訴服務端按定長字符串傳參如果用VARCHAR(256)聲明傳進去的是帶長度前綴的結構體指針函數(shù)簽名就得跟著改BY VALUE表示返回值按值傳整型必須加這個漏了會讀到一個野指針ENTRY_POINT是導出符號名MODULE_NAME是不帶擴展名的庫名。改完庫之后必須重啟服務端連接才會重新加載改完函數(shù)不重啟是最常見的「明明改了卻沒生效」。5. 避坑與排查五個把項目拖進坑里的細節(jié)5.1 恢復之后主鍵沖突集中爆發(fā)現(xiàn)象從生產庫備份出來恢復到測試環(huán)境應用一插數(shù)據就報violation of PRIMARY or UNIQUE KEY constraint但表里明明只有幾百行。原因gbak做完整備份還原時會把生成器的當前值一起帶過去但如果這次恢復用的是只導結構的 DDL 腳本或者用-m只恢復元數(shù)據生成器的值就回到了建庫時的初始狀態(tài)。而數(shù)據行是從別處灌進來的ID已經用到了幾千兩邊一撞就沖突。解決恢復完之后先對齊每個生成器再讓應用跑起來。-- 把生成器重置到當前最大 ID批量做的時候用腳本生成這段 SET GENERATOR GEN_ORDER_ID TO 0; SELECT GEN_ID(GEN_ORDER_ID, COALESCE(MAX(ID), 0)) FROM T_ORDER;第二句借GEN_ID的步長參數(shù)一次性把計數(shù)器頂?shù)組AX(ID)比SET GENERATOR ... TO 具體數(shù)字少一次人工查數(shù)。我現(xiàn)在的習慣是恢復腳本最后必須帶這一段每個生成器一行缺一個就等著線上報沖突。5.2 庫文件只漲不縮sweep 跑不動現(xiàn)象刪了幾百萬行歷史數(shù)據磁盤占用一點沒降查詢一天比一天慢跑gfix -sweep跑了幾個小時還在跑。原因刪除在 MGA 里只是把版本標記成死真正回收要靠 sweep。而 sweep 能推進的前提是 OAT 能往前走只要有一個長事務不提交回收立刻停擺。第二個原因是 sweep 本身是協(xié)作式的它和正常業(yè)務搶資源業(yè)務壓力大時會一直退讓。解決先查 OIT 和 OAT 的差距定位長事務再決定是手動 sweep 還是干脆做一次備份還原。# 看水位線差距差幾十萬說明有長事務 gstat -h /opt/data/demo.gdb | grep -i oldest # 手動觸發(fā)回收最好放在業(yè)務低峰 gfix -sweep /opt/data/demo.gdb -user SYSDBA -password masterkey # 徹底方案備份還原空間能真正收回來 gbak -b /opt/data/demo.gdb /tmp/demo.fbk -user SYSDBA -password masterkey -v gbak -c -p 8192 /tmp/demo.fbk /opt/data/demo_new.gdb -user SYSDBA -password masterkey -vsweep只回收頁內空間文件大小不會縮只有備份還原才會重寫整個文件、把空間真正交還給文件系統(tǒng)。所以計劃里應該把「定期備份還原」當成運維動作而不是只當災備。5.3 Dialect 混用DATE 變成 TIMESTAMP雙引號變成標識符現(xiàn)象客戶端查出來的日期字段多出了時間部分一條WHERE NAME ABC忽然報「列名不明確」NUMERIC(18,2)的金額在小數(shù)位上丟精度。原因這是 dialect 1 和 dialect 3 的語義差異。dialect 1 里DATE實際是帶時間的 TIMESTAMP雙引號包起來的是本文還有配套的精品資源點擊獲取