“這個(gè)WHERE條件明明能查出數(shù)據(jù)怎么一加運(yùn)算符就全空了”——上周五下午隔壁組的同事小周抱著筆記本沖過來屏幕上是一個(gè)簡(jiǎn)單的SELECT條件就兩個(gè)LV_BUKRS ‘1000’再加一個(gè)金額字段的判斷。他查了半天最后發(fā)現(xiàn)是運(yùn)算符優(yōu)先級(jí)把整個(gè)條件邏輯帶偏了。ABAP里的WHERE和運(yùn)算符看起來像SQL實(shí)際坑起來比SQL還隱蔽今天就把這些年踩過的雷一并倒出來。先說說最基礎(chǔ)的等值條件。大多數(shù)人寫的第一條ABAP SQL大概是SELECT * FROM MARA WHERE MTART ‘FERT’。這里有個(gè)習(xí)慣性的壞毛病把變量寫在左邊字段寫在右邊。比如WHERE LV_MTART MTART。ABAP的Open SQL在語法上允許你兩邊互換但性能上有區(qū)別嗎老實(shí)說在ABAP里差別不大可讀性卻差很多。我自己的習(xí)慣永遠(yuǎn)是字段在左變量在右這樣一眼就能看出是“哪個(gè)表字段和哪個(gè)變量比較”而且和ABAP內(nèi)表操作的寫法保持一致。你要是敢把變量放左邊半年后回頭看自己代碼保準(zhǔn)愣三秒。等值之外最常用的就是范圍條件了。BETWEEN是個(gè)好東西但注意它包含邊界值。WHERE DATUB BETWEEN LV_BEGDA AND LV_ENDDA這表示DATUB LV_BEGDA AND DATUB LV_ENDDA。很多新手會(huì)忘掉邊界包含這回事第二天突然多出來第一天和最后一天的數(shù)據(jù)別問我怎么知道的。還有BETWEEN后面跟著的兩個(gè)值如果LV_BEGDA比LV_ENDDA大那查出來就是空這種邏輯錯(cuò)誤在調(diào)試時(shí)很難一眼看出來所以寫完之后最好加個(gè)斷言或者IF檢查一下。運(yùn)算符這塊最容易翻車的是反邏輯。你想查“金額不等于1000”的憑證下意識(shí)寫WHERE ZZMONEY 1000。在Open SQL里這個(gè)沒問題但如果你用了內(nèi)表FILTER或者FOR ALL ENTRIES情況立刻變得微妙。記住一個(gè)鐵則SQL的NULL不參與任何比較運(yùn)算。如果某行ZZMONEY是NULL那么ZZMONEY 1000這個(gè)條件永遠(yuǎn)不成立那行會(huì)被過濾掉。也就是說用不等號(hào)查不出NULL的值。解決辦法要么在SELECT里加WHERE ZZMONEY IS NOT NULL要么把不等條件改成ZZMONEY 1000再在程序里做反向差集。后者更穩(wěn)妥因?yàn)镹ULL的語義在不同數(shù)據(jù)庫(kù)上實(shí)在不統(tǒng)一。再來看LIKE運(yùn)算符。這是模糊查詢的老朋友但ABAP的LIKE和SQL標(biāo)準(zhǔn)有個(gè)微妙差異轉(zhuǎn)義字符。比如你想查包含百分號(hào)%的文本直接寫WHERE NAME LIKE %%%‘是不行的因?yàn)锳BAP里轉(zhuǎn)義符默認(rèn)不是反斜杠。正確寫法是先聲明轉(zhuǎn)義字符WHERE NAME LIKE ‘%|%%’ ESCAPE ‘|’。這里有個(gè)坑ESCAPE后面的字符必須用單引號(hào)括起來而且只能是一位字符。還有下劃線_在LIKE里是通配符表示任意單字符如果你真要匹配下劃線也得用轉(zhuǎn)義。舉例查物料號(hào)第二字符是’1’寫WHERE MATNR LIKE ‘_1%’如果查物料號(hào)本身包含下劃線那必須用ESCAPE不然結(jié)果會(huì)比你想象的多得多。IN運(yùn)算符和FOR ALL ENTRIES的恩怨可能每個(gè)ABAPer都經(jīng)歷過。內(nèi)表大幾千行直接SELECT … FOR ALL ENTRIES IN ITAB WHERE FIELD ITAB-FIELD這是常規(guī)操作。但很多人不知道FOR ALL ENTRIES會(huì)在條件一多時(shí)自動(dòng)把IN條件展開成OR而且當(dāng)內(nèi)表為空時(shí)會(huì)忽略所有WHERE條件直接全表掃這就是著名的“空內(nèi)表陷阱”。我有個(gè)血的教訓(xùn)當(dāng)時(shí)在報(bào)表里忘了清空內(nèi)表一運(yùn)行直接查了全公司的主數(shù)據(jù)數(shù)據(jù)庫(kù)差點(diǎn)報(bào)警。所以無論你用什么條件只要用了FOR ALL ENTRIES請(qǐng)先判斷內(nèi)表是否為空。另外FOR ALL ENTRIES生成的SQL會(huì)把多個(gè)字段條件合并成OR這會(huì)讓普通索引失效如果性能敏感建議改用內(nèi)表JOIN或者分批查詢。關(guān)于WHERE里的括號(hào)這才是小周翻車的罪魁禍?zhǔn)?。ABAP的Open SQL里括號(hào)可以用于分組邏輯但和算術(shù)運(yùn)算一樣AND優(yōu)先級(jí)高于OR。如果你寫WHERE TYPE ‘A’ OR TYPE ‘B’ AND STATUS ‘X’實(shí)際執(zhí)行的是TYPE ‘A’ OR (TYPE ‘B’ AND STATUS ‘X’)因?yàn)锳ND綁得更緊。這很容易漏數(shù)據(jù)。想查類型A或B中狀態(tài)為X的必須加括號(hào)WHERE ( TYPE ‘A’ OR TYPE ‘B’ ) AND STATUS ‘X’。千萬別省括號(hào)也別依賴記憶中的優(yōu)先級(jí)。即使你覺得很清楚過兩周改需求的人不一定清楚。寫進(jìn)代碼里的括號(hào)就是給未來的自己看的。還有字符串比較的坑。ABAP默認(rèn)的字符串比較是區(qū)分大小寫的嗎在Open SQL里取決于數(shù)據(jù)庫(kù)設(shè)置通常不區(qū)分。但如果你在HANA上默認(rèn)行為可能不同。更麻煩的是尾部空格。DB2上CHAR類型比較會(huì)忽略尾部空格VARCHAR不會(huì)。你用WHERE NAME TOM 左邊的表字段是CHAR(10)那’TOM’存進(jìn)去自動(dòng)補(bǔ)了7個(gè)空格兩個(gè)值一比較數(shù)據(jù)庫(kù)說相等但如果你用內(nèi)表排序或者去重ABAP卻認(rèn)為不相等。這種不一致會(huì)讓人抓狂。我的建議是所有關(guān)鍵字段統(tǒng)一使用STRING或固定長(zhǎng)度的類型永遠(yuǎn)不要在程序里依賴“自動(dòng)補(bǔ)空格”來匹配。日期和時(shí)間條件的寫法值得單獨(dú)說。在ABAP里日期不能直接和字符串比較除非你寫對(duì)格式。WHERE BUDAT ‘20240101’這沒問題因?yàn)镈ATS類型內(nèi)部就是8位字符。但如果你寫B(tài)UDAT ‘2024-01-01’那就廢了格式不匹配啥也查不到。還有日期加運(yùn)算符的坑WHERE BUDAT SY-DATUM - 30這種寫法看起來是30天前但SY-DATUM是DATS類型整數(shù)減法會(huì)把日期當(dāng)成數(shù)字算遇到月初就會(huì)出大問題。比如20240101減去30等于20240071這不是合法日期。正確做法是用計(jì)算函數(shù)WHERE BUDAT SY-DATUM - 30其實(shí)在HANA上這個(gè)可以因?yàn)槿掌谠试S數(shù)字加減但跨月時(shí)真的會(huì)錯(cuò)。我一般用ADD_DAYS_TO_DATE或者直接算好日期范圍再傳入。說到括號(hào)再補(bǔ)一個(gè)ABAP內(nèi)表行號(hào)條件的奇怪用法。你想取每組的最大值可能會(huì)寫WHERE ( AUFNR, VERSION ) ( SELECT … )這語法在ABAP新版本里支持多字段元組比較。但注意元組比較中每個(gè)字段的順序必須和表字段一致而且括號(hào)不要多也不要少。調(diào)試時(shí)如果發(fā)現(xiàn)“無效的表字段”錯(cuò)誤八成是元組里的字段名寫錯(cuò)或者順序亂了。這種寫法高級(jí)是高級(jí)但可讀性差我寧可拆成兩個(gè)條件也沒問題真的性能瓶頸不在這種地方。運(yùn)算符還有一個(gè)容易忽略的點(diǎn)CASE語句只能在SELECT列表里用不能直接放在WHERE里。很多人想寫WHERE CASE WHEN … THEN … END ‘X’ABAP會(huì)直接報(bào)語法錯(cuò)。解決辦法是把它包在子查詢里或者用OR組合條件。別跟數(shù)據(jù)庫(kù)原生SQL比ABAP有自己的限制該繞彎就繞彎。調(diào)試真實(shí)問題的時(shí)候還有一種情況是SQL的隱式轉(zhuǎn)換。比如某個(gè)字段是NUMC類型你拿一個(gè)字符串變量去比較只要字符串全是數(shù)字ABAP通常會(huì)轉(zhuǎn)換但如果有字母就會(huì)報(bào)“類型沖突”或者產(chǎn)生意想不到的結(jié)果。我碰到過一個(gè)Z字段是CHAR10里面存了’00123’程序里用LV_NUM 123去比較WHERE ZFIELD LV_NUM結(jié)果發(fā)現(xiàn)查不出來。因?yàn)锳BAP把LV_NUM轉(zhuǎn)成’000123’和’00123’位數(shù)不一樣永遠(yuǎn)不等。這個(gè)坑很讓人崩潰。所以老老實(shí)實(shí)類型轉(zhuǎn)換WHERE ZFIELD |{ LV_NUM WIDTH 10 ALIGN RIGHT }|或者直接CONCATENATE出來。最后說一個(gè)老生常談但永遠(yuǎn)有人犯的錯(cuò)把內(nèi)表字段直接和變量比較時(shí)忘記“表別名”。在FOR ALL ENTRIES里內(nèi)表字段必須帶上表別名不語法上不需要。但是當(dāng)你在WHERE里同時(shí)引用內(nèi)表字段和數(shù)據(jù)庫(kù)表字段而且字段名相同時(shí)系統(tǒng)可能認(rèn)為是同一個(gè)字段造成條件恒成立。比如SELECT * FROM BKPF FOR ALL ENTRIES IN ITAB WHERE BUKRS ITAB-BUKRS AND BUKRS ITAB-BUKRS這樣寫只會(huì)讓數(shù)據(jù)庫(kù)認(rèn)為BUKRS BUKRS永遠(yuǎn)真。這種低級(jí)錯(cuò)誤我見過不止一次。正確做法是給數(shù)據(jù)庫(kù)表起別名FROM BKPF AS A WHERE A~BUKRS ITAB-BUKRS。這樣才清楚?？偨Y(jié)不寫了。給你一個(gè)我自己的習(xí)慣寫WHERE條件前先把所有可能為空的值處理掉寫運(yùn)算符時(shí)能加括號(hào)就加括號(hào)別管優(yōu)先級(jí)寫比較時(shí)永遠(yuǎn)假設(shè)數(shù)據(jù)庫(kù)字段可能有NULL和尾部空格寫完立刻跑一次帶極端數(shù)據(jù)的測(cè)試比如空字符串、全空格、00開頭、和NULL。這些才是ABAP調(diào)試的真相。等你被NULL坑過三次被日期加減坑過兩次被空內(nèi)表坑過一次你自然就會(huì)記得住。到那時(shí)候你也能坐在電腦前一邊敲WHERE一邊笑當(dāng)年自己傻得可愛。