做SAP開發(fā)的人大概都經(jīng)歷過這種場景物料號帶前導(dǎo)零、接口日志里大小寫混雜、報(bào)表上要把物料號和描述拼成一行顯示。早些年我的處理方式非?！袄蠈?shí)”——先把數(shù)據(jù)從數(shù)據(jù)庫整批撈回ABAP內(nèi)表再用一堆字符處理函數(shù)在循環(huán)里慢慢磨一個(gè)報(bào)表寫下來動(dòng)不動(dòng)就是一兩百行代碼運(yùn)行起來還慢。后來我把ABAP Open SQL里的字符串函數(shù)系統(tǒng)地用了一遍才意識到很多活其實(shí)在SELECT語句里就能干完代碼短了數(shù)據(jù)量也小了一圈。這篇文章就圍繞ABAP SQL的字符串函數(shù)展開把常用函數(shù)的語法、參數(shù)、版本差異和真實(shí)業(yè)務(wù)場景串一遍重點(diǎn)講清楚哪些地方容易踩坑以及我實(shí)際項(xiàng)目里的取舍。適合剛接觸ABAP的初學(xué)者也適合寫了好幾年老式報(bào)表、想把手頭SQL寫得再利索一點(diǎn)的同行。1. 先在SQL里處理還是拉回內(nèi)存再算我為什么選前者1.1 少傳數(shù)據(jù)、少寫循環(huán)SQL下推天然高效先說一個(gè)容易被忽略的事實(shí)數(shù)據(jù)庫拿到的數(shù)據(jù)遠(yuǎn)比報(bào)表最終展示出來的多。比如一個(gè)ALV報(bào)表要從MARA查300萬條物料最后用戶只想看物料號和創(chuàng)建人姓名的大寫形式。如果在ABAP內(nèi)存里處理你得先把300萬條記錄拖回來再LOOP一遍做大小寫轉(zhuǎn)換不僅占用大量內(nèi)存循環(huán)耗時(shí)也不短。實(shí)際我遇過不少老程序就是一個(gè)簡單的大小寫統(tǒng)一也要先取數(shù)再內(nèi)表循環(huán)純屬把活從數(shù)據(jù)庫搬到了應(yīng)用服務(wù)器。SQL字符串函數(shù)的價(jià)值在于“下推”把計(jì)算交給數(shù)據(jù)庫引擎返回結(jié)果前數(shù)據(jù)已經(jīng)被加工成你要的樣子。這就像去肉鋪買肉你直接在鋪?zhàn)永锇葱枰某叽缜泻迷倌没丶叶皇强敢徽^豬回去自己剁。數(shù)據(jù)庫擅長這種批量運(yùn)算你省下來的就是ABAP內(nèi)存和程序運(yùn)行時(shí)間。用得好的話一個(gè)本來要寫幾十行LOOP的邏輯一個(gè)SELECT就結(jié)束了。1.2 ABAP版本不同能用的函數(shù)差在哪很多新手看到網(wǎng)上教程里的SQL函數(shù)拿到自己系統(tǒng)里一編譯卻報(bào)錯(cuò)第一反應(yīng)是自己寫錯(cuò)了。其實(shí)未必更可能是ABAP版本和底層數(shù)據(jù)庫差異導(dǎo)致的。SAP從ABAP 7.40開始在Open SQL里全面引入了SQL表達(dá)式和一大批內(nèi)置函數(shù)比如UPPER、LOWER、CONCAT、SUBSTRING、REPLACE、LENGTH這些。到了7.50以后又補(bǔ)充了更多函數(shù)加上S/4HANA普遍使用HANA數(shù)據(jù)庫LPAD、RPAD、LEFT、RIGHT這類函數(shù)用的頻率也越來越高。但如果你是老ECC系統(tǒng)底層還是DB2、Oracle或者ASE部分函數(shù)的行為就會(huì)有所區(qū)別個(gè)別函數(shù)甚至不會(huì)下推語法檢查能過運(yùn)行時(shí)卻報(bào)數(shù)據(jù)庫錯(cuò)誤。所以我的建議很直接先確認(rèn)你手里的底牌?？聪到y(tǒng)版本、看底層數(shù)據(jù)庫再?zèng)Q定能用哪些函數(shù)。不要因?yàn)橥略赟/4HANA上寫了一個(gè)漂亮SQL就原封不動(dòng)往ECC里搬搬之前先驗(yàn)證一下。1.3 字符串函數(shù)速查表先列一張我平時(shí)用得最多的速查表后面每一條都會(huì)展開講。函數(shù)作用常見寫法注意事項(xiàng)UPPER / LOWER轉(zhuǎn)大寫 / 轉(zhuǎn)小寫UPPER( field )注意Unicode環(huán)境下對非英文字符的處理CONCAT字符串拼接CONCAT( field1, field2 )拼接多個(gè)字段要嵌套不能用或SUBSTRING按位置截取SUBSTRING( field, start, len )start從1開始不是0LEFT / RIGHT從左側(cè)/右側(cè)截取LEFT( field, len )適用于從兩端取固定長度LOCATE / FIND查找子串位置LOCATE( field, AB )返回從1開始的位置查不到返回0REPLACE替換子串REPLACE( field, A, B )替換所有出現(xiàn)的位置不是只替換第一個(gè)LPAD / RPAD左填充 / 右填充LPAD( field, 18, 0 )常用于補(bǔ)前導(dǎo)零填充字符盡量用單字符LENGTH返回字符個(gè)數(shù)LENGTH( field )與BYTE_LENGTH區(qū)分中文場景尤其注意CHAR_LENGTH / BYTE_LENGTH字符長度 / 字節(jié)長度BYTE_LENGTH( field )按字節(jié)計(jì)算時(shí)中文會(huì)占多個(gè)字節(jié)2. 核心字符串函數(shù)逐個(gè)講透2.1 UPPER與LOWER大小寫統(tǒng)一真的這么簡單這兩個(gè)函數(shù)是所有SQL字符串函數(shù)里最沒門檻的但很多人都只會(huì)在SELECT列表里用它不知道在WHERE條件里也能用也不了解不同數(shù)據(jù)庫在Unicode環(huán)境下的細(xì)微差別。最常見的用法是統(tǒng)一字母大小寫。比如ERP系統(tǒng)里從外部接口進(jìn)來的客戶名稱有的是大寫的“ACME”有的是首字母大寫的“Acme”還有的是小寫“acme”。如果直接按名稱找客戶一個(gè)簡單的“‘ACME’”可能什么都查不到。用UPPER統(tǒng)一一下再比較就穩(wěn)了SQL看起來是這個(gè)樣子SELECT kunnr, name1 FROM kna1 WHERE UPPER( name1 ) ACME INTO TABLE DATA(lt_customer).這里有個(gè)容易忽略的細(xì)節(jié)UPPER在疊了系統(tǒng)不同的排序規(guī)則collation時(shí)對ASCII字符效果一致但對帶變音符的字符不同數(shù)據(jù)庫的表現(xiàn)可能不一樣。比如德語中的“?”在HANA、DB2上的轉(zhuǎn)換結(jié)果可能存在差異。如果只是處理物料號、供應(yīng)商編碼這類純ASCII數(shù)據(jù)可以放心用如果處理自然語言姓名、描述先在小數(shù)據(jù)量上驗(yàn)證一下再上生產(chǎn)。另外一個(gè)小技巧UPPER/LOWER也經(jīng)常配合其他函數(shù)使用比如先UPPER再REPLACE把“ACME-CORP”和“acme corp”統(tǒng)一成“ACME-CORP”再匹配。這種多函數(shù)嵌套在ABAP SQL里是完全合法的只要?jiǎng)e嵌套太深讓人讀不懂就行。2.2 CONCAT嵌套寫法與“加號”的誘惑CONCAT是字符串拼接的官方函數(shù)語法很直白CONCAT( field1, field2 )但初學(xué)者往往會(huì)栽在一個(gè)地方我拼三個(gè)字段能不能CONCAT( a, b, c )答案是不能。ABAP Open SQL的CONCAT是二元函數(shù)只能接收兩個(gè)參數(shù)。想拼三個(gè)字段必須嵌套CONCAT( CONCAT( field1, field2 ), field3 )我在評審代碼時(shí)看到過不少這樣的寫法第一眼會(huì)覺得“哇高手”但看多了就發(fā)現(xiàn)嵌套一深代碼閱讀成本就開始上升。所以如果拼接邏輯特別復(fù)雜比如五個(gè)字段加三個(gè)分隔符我通常會(huì)建議在SQL層只做簡單拼接太復(fù)雜的邏輯放回ABAP內(nèi)表處理用字符串模板|...|可讀性會(huì)好很多。還有兩點(diǎn)要特別提醒。第一別用加號或做拼接。那是ABAP內(nèi)存里的操作符甚至有代碼在SQL里寫field1 field2想拼字符串結(jié)果被當(dāng)成數(shù)值相加直接運(yùn)行時(shí)異常。SQL層拼接就老實(shí)寫CONCAT。第二CONCAT和NULL的規(guī)則標(biāo)準(zhǔn)SQL里只要有一個(gè)參數(shù)是NULL整個(gè)結(jié)果就是NULL。SAP的表字段大多數(shù)情況下不會(huì)出現(xiàn)NULL因?yàn)锳BAP字典的CHAR字段默認(rèn)是空格填充但如果你直接查數(shù)據(jù)庫視圖或者自定義表字段可能允許NULL。穩(wěn)妥起見拼接之前先用COALESCE把NULL換成空串比如CONCAT( COALESCE( field1, ), COALESCE( field2, ) )再補(bǔ)一個(gè)常見錯(cuò)誤CONCAT返回的字符串長度是參數(shù)長度之和。如果目標(biāo)內(nèi)表字段定義成了最大長度18你拼了兩個(gè)長度分別為18和4的字段運(yùn)行時(shí)就會(huì)報(bào)“字段過長導(dǎo)致數(shù)據(jù)丟失”的錯(cuò)誤。這類問題經(jīng)常在ALV展示拼接字段時(shí)出現(xiàn)后面場景部分我再細(xì)說。2.3 SUBSTRING、LEFT、RIGHT截取時(shí)最容易搞混的參數(shù)截取是日常開發(fā)里最頻繁的操作沒有之一。比如一個(gè)編碼的前4位代表產(chǎn)品系列后2位代表版本中間5位是流水號你要分別取出來做統(tǒng)計(jì)這時(shí)候就是截取函數(shù)的主場。SUBSTRING是最靈活的一個(gè)語法是SUBSTRING( field, start, len )它的含義是從第start個(gè)字符開始取len個(gè)字符。一個(gè)重點(diǎn)起始位置從1開始不是從0開始。別給Python習(xí)慣帶偏了很多Java/Python背景的同事第一次用SUBSTRING都寫過SUBSTRING( field, 0, 2 )在部分?jǐn)?shù)據(jù)庫上返回的結(jié)果完全不符合預(yù)期甚至在DB2上直接報(bào)錯(cuò)。把SUBSTRING寫對效果是這樣SELECT SUBSTRING( matnr, 1, 4 ) AS series, SUBSTRING( matnr, 8, 2 ) AS version FROM mara INTO TABLE DATA(lt_part) UP TO 100 ROWS.第三個(gè)參數(shù)len可以省略表示一直取到末尾。比如SUBSTRING( matnr, 5 )就是從第5個(gè)字符開始把剩下的全取出來。這個(gè)寫法我經(jīng)常用比硬算剩余長度省事。LEFT和RIGHT則更簡單就是從左邊或右邊取固定長度的字符。當(dāng)你想取物料號左邊4位或者右邊2位時(shí)用LEFT/RIGHT比SUBSTRING更直觀代碼也更短SELECT LEFT( matnr, 4 ) AS first4, RIGHT( matnr, 2 ) AS last2需要留意的是截取函數(shù)的長度單位是字符不是字節(jié)。對純中文的文本SUBSTRING( text, 1, 2 )取出來就是兩個(gè)漢字這在多字節(jié)環(huán)境下非常安全。如果你要按字節(jié)數(shù)做截?cái)啾热缃涌谧侄问亲止?jié)長度限制就要先想清楚用哪個(gè)長度函數(shù)這就是后面要講的LENGTH家族。2.4 LOCATE與FIND定位子串的正確姿勢很多場景里我們想知道一個(gè)字符串里是否包含另一個(gè)字符串或者要按子串出現(xiàn)的位置做后續(xù)截取。這時(shí)候LOCATE和FIND就派上用場了。LOCATE的基本語義是在一個(gè)文本里找某個(gè)子串第一次出現(xiàn)的位置。位置也是從1開始如果找不到就返回0。我平時(shí)的寫法長這樣SELECT config_id, LOCATE( config_code, X12 ) AS pos_x12 FROM zconfig INTO TABLE DATA(lt_config) UP TO 100 ROWS.FIND和LOCATE功能基本重疊在CDS視圖里你幾乎只能看到FIND在Open SQL里兩者都可能會(huì)遇到。不同內(nèi)核版本、不同數(shù)據(jù)庫這兩個(gè)函數(shù)的參數(shù)順序偶爾會(huì)讓人抓狂有的幫助文檔寫LOCATE( 文本, 子串 )有的寫著LOCATE( 子串, 文本 )。我在項(xiàng)目里就吃過這個(gè)虧在DB2上跑得好好的遷到HANA后發(fā)現(xiàn)位置始終不對最后查系統(tǒng)幫助才發(fā)現(xiàn)參數(shù)順序?qū)υ摂?shù)據(jù)庫的翻譯有差異。真遇到這種情況怎么辦我習(xí)慣的做法是先在系統(tǒng)里用一條單行SQL驗(yàn)證函數(shù)結(jié)果相當(dāng)于拿數(shù)據(jù)庫當(dāng)計(jì)算器用。具體驗(yàn)證方法在第5章會(huì)寫這里先記住一個(gè)原則凡是LOCATE/FIND這種參數(shù)順序容易搞混的函數(shù)落庫之前先測一次。LOCATE本身不提供正則能力。如果要在SQL里做正則匹配Open SQL原生支持非常有限更常見的是配合LIKE做模糊搜索或者把數(shù)據(jù)取回ABAP層用FIND REGEX處理。硬要在SQL里塞正則代碼會(huì)失去可移植性這是要抵制的。2.5 REPLACE與LPAD/RPAD替換和填充的組合拳REPLACE用來替換字符串中的指定子串標(biāo)準(zhǔn)行為是替換所有匹配位置不是只替換第一次出現(xiàn)。比如要把編碼里的橫杠全去掉SELECT REPLACE( config_code, -, ) AS clean_code如果字段里有多個(gè)不同的特殊字符比如既有橫杠又有斜杠那就需要嵌套多個(gè)REPLACE。嵌套層數(shù)一多代碼容易難看我的建議是控制在一兩層再多就放到ABAP內(nèi)存里處理或者寫一個(gè)可復(fù)用的FOR語句逐個(gè)替換。LPAD和RPAD是一對填充函數(shù)作用是在字符串左側(cè)或右側(cè)補(bǔ)充字符讓結(jié)果達(dá)到指定長度。語法是LPAD( field, target_length, fill_char )一個(gè)最典型的應(yīng)用是物料號內(nèi)碼轉(zhuǎn)補(bǔ)零。SAP的物料號在MARA表里存儲(chǔ)為18位CHAR字段通常左補(bǔ)零。外部接口給的物料號可能是10位的“1234567890”要變成內(nèi)部存儲(chǔ)格式直接用LPAD補(bǔ)零LPAD( 1234567890, 18, 0 )結(jié)果就是“000000001234567890”。這里有個(gè)小坑填充字符最好用單字符。雖然某些數(shù)據(jù)庫允許傳入多個(gè)字符的字符串做填充但行為不完全一致用單字符永遠(yuǎn)是最穩(wěn)的。我對這個(gè)參數(shù)的要求很簡單寫LPAD/RPAD填充位就寫一個(gè)字符別去秀花活。2.6 LENGTH家族別把字符數(shù)當(dāng)字節(jié)數(shù)LENGTH返回的是字符串的字符個(gè)數(shù)。對英文、數(shù)字來說它和字節(jié)數(shù)一樣對中文來說一個(gè)漢字的字符數(shù)是1字節(jié)數(shù)可能是2或者3。所以碰到中文字段用LENGTH取的是字符數(shù)用BYTE_LENGTH取的才是字節(jié)數(shù)。舉一個(gè)我實(shí)際遇到的場景客戶給一個(gè)接口報(bào)文里某個(gè)字段限制50字節(jié)而系統(tǒng)里存的是中文描述。如果你用LENGTH去檢查長度一個(gè)“你好”判斷下來才2個(gè)字符以為沒問題塞進(jìn)報(bào)文后才發(fā)現(xiàn)一個(gè)漢字占3個(gè)字節(jié)實(shí)際長度已經(jīng)超標(biāo)了。這時(shí)候必須用BYTE_LENGTHSELECT BYTE_LENGTH( description ) AS byte_lenCHAR_LENGTH和LENGTH在大多數(shù)ABAP版本中等價(jià)。既然這樣搜索條件里寫LENGTH就夠了見到CHAR_LENGTH也別慌知道是一個(gè)意思就行。搞懂長度配合SUBSTRING做截?cái)鄷r(shí)會(huì)更有的放矢。比如要按字節(jié)數(shù)截?cái)嘤植幌肭袛酀h字中間你可以先BYTE_LENGTH判斷再結(jié)合字符長度做安全截取。這類問題SQL不能完美解決處理復(fù)雜文本還是要靠ABAP層這個(gè)判斷我放在第4章再說。3. 常見業(yè)務(wù)場景實(shí)操3.1 物料號內(nèi)碼轉(zhuǎn)外碼與補(bǔ)零物料號的補(bǔ)零與去零是SAP開發(fā)里最經(jīng)典的字符串場景沒有之一。內(nèi)部存儲(chǔ)的18位物料號全是左補(bǔ)零的展示給用戶的卻是去掉前導(dǎo)零的“外碼”。這兩個(gè)格式之間的轉(zhuǎn)換SAP其實(shí)有標(biāo)準(zhǔn)功能模塊CONVERSION_EXIT_MATN1_OUTPUT和CONVERSION_EXIT_MATN1_INPUT但很多情況下我們并不需要調(diào)用它們。從外碼轉(zhuǎn)內(nèi)碼也就是補(bǔ)零到18位直接在SQL里用LPAD就能高效完成SELECT LPAD( lv_external_matnr, 18, 0 ) AS internal_matnr FROM t000 WHERE mandt sy-mandt INTO DATA(lv_internal_matnr).這段代碼同時(shí)也是一個(gè)很好的“SQL函數(shù)計(jì)算器”示例借助單行表T000算完立刻得到結(jié)果不用真的去查一大張物料表。反方向內(nèi)碼轉(zhuǎn)外碼也就是去掉前導(dǎo)零我反而不推薦在SQL里硬做。原因很簡單物料號不一定全是數(shù)字可能是字母開頭的自定義編碼也可能中間夾著其他字符。你用CAST轉(zhuǎn)數(shù)字再轉(zhuǎn)回字符一步小心就報(bào)類型轉(zhuǎn)換錯(cuò)誤用REPLACE一個(gè)個(gè)去零又可能把正常位置的零也去掉。這種邏輯放在ABAP層用SHIFT或標(biāo)準(zhǔn)轉(zhuǎn)換功能模塊處理比在SQL里堆函數(shù)安全得多。原則就是補(bǔ)零交給SQL去零交給ABAP各干各擅長的。3.2 ALV展示字段的拼接與按位截?cái)嘧鯝LV報(bào)表時(shí)經(jīng)常要把物料號和物料描述拼在一個(gè)字段里展示比如“100000000000000010 - 螺栓”。最笨的方法是在數(shù)據(jù)取回后加一個(gè)循環(huán)一行行去拼。用上CONCAT以后整個(gè)邏輯在SQL里一步完成SELECT a.matnr, CONCAT( a.matnr, CONCAT( - , b.maktx ) ) AS matnr_desc FROM mara AS a INNER JOIN makt AS b ON b.matnr a.matnr AND b.spras sy-langu INTO TABLE DATA(lt_alv_data) UP TO 100 ROWS.這個(gè)寫法至少比循環(huán)拼接少十幾行代碼而且數(shù)據(jù)在進(jìn)入ALV之前就已經(jīng)是最終展示形態(tài)。但這里有一個(gè)隱蔽的坑maktx物料描述允許長度為40a.matnr長度為18中間再放一個(gè)“ - ”拼接結(jié)果最長是60個(gè)字符。如果你在ALV的字段目錄里把這個(gè)字段定義成40字符運(yùn)行時(shí)就會(huì)爆“數(shù)據(jù)被截?cái)唷钡腻e(cuò)誤。我在第2章提到過CONCAT返回長度是參數(shù)長度之和這一點(diǎn)在ALV場景格外要命。一個(gè)穩(wěn)妥的辦法是拼接完成后再用LEFT或SUBSTRING截?cái)嗟侥阈枰恼故鹃L度。比如只取前40個(gè)字符LEFT( CONCAT( a.matnr, CONCAT( - , b.maktx ) ), 40 )這樣展示字段定義成CHAR40就不會(huì)出錯(cuò)了。對于報(bào)表展示寧可主動(dòng)截?cái)嘁膊蛔屵\(yùn)行時(shí)去截?cái)唷?.3 數(shù)據(jù)清洗大小寫、特殊符號、前后綴接口數(shù)據(jù)和手工維護(hù)的主數(shù)據(jù)永遠(yuǎn)是臟數(shù)據(jù)的高發(fā)區(qū)?？蛻裘Q一會(huì)兒大寫一會(huì)兒小寫供應(yīng)商編碼里帶著橫杠和空格地址字段混著亂七八糟的標(biāo)點(diǎn)。清洗邏輯如果全寫在ABAP層內(nèi)表循環(huán)會(huì)很長簡單清洗在SQL層就能解決程序會(huì)干凈很多。比如統(tǒng)一客戶名稱的大小寫并去掉名稱里的特殊字符SELECT kunnr, REPLACE( REPLACE( UPPER( name1 ), -, ), /, ) AS cleaned_name FROM kna1 INTO TABLE DATA(lt_clean) UP TO 100 ROWS.這就是前面講的REPLACE嵌套外層的REPLACE再把斜杠清掉。嵌套控制在兩層代碼還能看懂如果遇到要清理的字符超過三四個(gè)我建議還是回ABAP層寫個(gè)循環(huán)否則SQL的可讀性會(huì)急劇下降。順帶提一個(gè)經(jīng)驗(yàn)數(shù)據(jù)清洗的SQL函數(shù)盡量不要直接在UPDATE語句里使用。你可能會(huì)想“既然能在SELECT里清洗那直接在UPDATE里把所有臟數(shù)據(jù)改干凈不是更爽”但很多臟數(shù)據(jù)是有規(guī)律可言的比如名稱里既有橫杠又有空格處理順序不同結(jié)果就不同直接UPDATE會(huì)留下不可逆的破壞。我的習(xí)慣是先在SELECT里驗(yàn)證清洗邏輯確認(rèn)結(jié)果無誤后再考慮改成UPDATE每次UPDATE之前備份表。3.4 字符串去重統(tǒng)計(jì)DISTINCT搭配UPPER的妙用去重統(tǒng)計(jì)在報(bào)表里很常見尤其是統(tǒng)計(jì)日志表里到底有多少條不同的錯(cuò)誤消息。如果直接用COUNT(DISTINCT message_text)因?yàn)榇笮懖煌⑶昂罂崭癫煌瑯拥腻e(cuò)誤可能被當(dāng)成好幾條。一個(gè)巧妙的做法是先把字符串統(tǒng)一成大寫再去重SELECT COUNT( DISTINCT UPPER( message_text ) ) AS unique_msg_cnt FROM zlog INTO DATA(lv_cnt).如果想看具體是哪些文本還能配合GROUP BYSELECT UPPER( message_text ) AS msg_upper, COUNT(*) AS cnt FROM zlog GROUP BY UPPER( message_text ) ORDER BY cnt DESC INTO TABLE DATA(lt_grouped).這個(gè)寫法在統(tǒng)計(jì)接口錯(cuò)誤、Batch Job失敗原因時(shí)特別好用。它把大小寫差異折疊了統(tǒng)計(jì)口徑更貼近“業(yè)務(wù)上是不是同一個(gè)錯(cuò)誤”。需要注意COUNT(DISTINCT UPPER(...))在底層數(shù)據(jù)庫會(huì)生成一個(gè)相對復(fù)雜的執(zhí)行計(jì)劃。日志表如果特別大比如上千萬行這種語句會(huì)掃全表性能不一定好。解決方案通常是建一張統(tǒng)計(jì)匯總表在數(shù)據(jù)寫入時(shí)順便維護(hù)一個(gè)“大寫后的錯(cuò)誤碼”字段查詢直接走這個(gè)字段沒必要每次都全表掃。3.5 模糊搜索與定位組合使用LIKE模糊搜索是另一個(gè)高頻場景比如按名稱的一部分找物料或者按編碼中包含的某個(gè)片段找配置項(xiàng)。它的性能特點(diǎn)要心里有數(shù)前綴匹配LIKE ABC%在有些數(shù)據(jù)庫上能走索引后綴或中間匹配LIKE %ABC%基本只能全表掃。用LOCATE也能實(shí)現(xiàn)類似效果SELECT config_id FROM zconfig WHERE LOCATE( config_code, X12 ) 0這個(gè)寫法表達(dá)的是“只要某編碼包含X12就查出來”比LIKE寫起來更靈活因?yàn)樗梢灾苯颖容^位置是否大于0還能和其他條件組合。但性能上和LIKE中間匹配一樣都是全表掃描數(shù)據(jù)量大時(shí)別指望它快。如果經(jīng)常要做這種“包含”匹配更好的做法是建冗余字段在數(shù)據(jù)寫入時(shí)把編碼里的關(guān)鍵詞單獨(dú)拆出來存一列或者直接在HANA上建函數(shù)索引讓SQL函數(shù)查詢能走到索引。函數(shù)索引不是SAP默認(rèn)幫你做的需要數(shù)據(jù)庫管理員配合普通ABAP開發(fā)環(huán)境里一般不會(huì)配。所以我的結(jié)論很務(wù)實(shí)小表隨便用LOCATE大表要謹(jǐn)慎能改成前綴匹配就改。4. 性能優(yōu)化與版本兼容避坑4.1 不要在WHERE里隨便套函數(shù)這個(gè)坑我年輕時(shí)踩過無數(shù)次先說結(jié)論WHERE條件里寫SQL函數(shù)很可能讓索引失效數(shù)據(jù)庫只能老老實(shí)實(shí)全表掃。打個(gè)比方你的表在某列上建了索引索引相當(dāng)于一本按字母順序排列的電話簿。你現(xiàn)在想找一個(gè)人但條件不是按姓查而是按“姓的反序”查這時(shí)候電話簿的排序就沒用了只能從頭翻一遍。SQL函數(shù)就是這樣它改變了字段的原始值索引里存的還是原始值數(shù)據(jù)庫沒法直接利用索引去匹配計(jì)算結(jié)果。比如這段代碼功能上完全沒問題SELECT * FROM kna1 WHERE UPPER( name1 ) ACME但如果你經(jīng)常按這個(gè)條件查而KNA1又是個(gè)大表每次都是全表掃性能一定扛不住。我的建議是如果這種查詢很頻繁最好在表里加一個(gè)冗余字段寫入的時(shí)候就把大寫后的名稱存好查詢直接比較原始字段或者要求用戶輸入時(shí)就統(tǒng)一成大寫別讓大寫在SQL層臨時(shí)算。反過來SELECT列表里的字符串函數(shù)通常不太影響性能因?yàn)樗鼈兪窃诮Y(jié)果集生成時(shí)計(jì)算而不是在篩選時(shí)計(jì)算。所以我的原則很簡單能用函數(shù)做展示、做加工盡管用能在WHERE之外做就不放到WHERE里。4.2 NULL與空字符串要分開處理跟字符串函數(shù)搭配時(shí)NULL是個(gè)隱形殺手。前面說過SQL里任何函數(shù)遇到NULL參數(shù)結(jié)果基本都是NULL。很多SAP開發(fā)剛接觸自定義表時(shí)以為字段沒值就是空字符串實(shí)際上在標(biāo)準(zhǔn)SQL語義里未定義值和空字符串是兩回事。假設(shè)zlog表里有個(gè)字段remark允許NULL。你執(zhí)行SELECT CONCAT( remark, -end ) FROM zlog如果某行remark為NULL那這一行結(jié)果就是NULL而不是“-end”。等你把結(jié)果寫進(jìn)ALV顯示出來是空白的排查半天可能都找不到原因。最簡單的解決方式是COALESCE把NULL統(tǒng)一成空串CONCAT( COALESCE( remark, ), -end )COALESCE可以接收多個(gè)參數(shù)返回第一個(gè)非NULL值。順帶一提它在很多數(shù)據(jù)庫引擎里也能優(yōu)化得很好不會(huì)帶來明顯的性能損失。在SAP的ABAP字典里大部分CHAR字段不允許NULL定義為NOT NULL默認(rèn)填充空格所以嚴(yán)格來說不會(huì)觸發(fā)這個(gè)坑。但只要你的SELECT來自數(shù)據(jù)庫視圖、CDS視圖或自定義數(shù)據(jù)庫表字段定義稍有疏忽就可能為NULL。我寫SQL的習(xí)慣是凡是可能出現(xiàn)NULL的字段先COALESCE再塞進(jìn)字符串函數(shù)寧可多寫幾層也不讓運(yùn)行時(shí)異常來找我。4.3 從ECC到S/4HANA遷移時(shí)的函數(shù)行為差異這幾年做系統(tǒng)升級的項(xiàng)目很多很多代碼從ECC搬到S/4HANA上看起來沒問題跑起來卻出錯(cuò)。字符串函數(shù)也是重災(zāi)區(qū)之一。原因在于ECC時(shí)代可能跑的DB2或Oracle底層對字符串函數(shù)的實(shí)現(xiàn)邏輯和HANA不完全一致。舉幾個(gè)我實(shí)際見過的差異LPAD/RPAD在DB2上的填充參數(shù)行為與HANA略有不同SUBSTRING起點(diǎn)為0時(shí)DB2可能返回從1開始的結(jié)果HANA還可能直接拋錯(cuò)FIND和LOCATE的參數(shù)順序兩邊也可能對不上。這類問題靠讀文檔其實(shí)很難徹底發(fā)現(xiàn)我推薦的排查手段是事務(wù)代碼ST05打開SQL跟蹤讓程序跑一遍看看SAP實(shí)際下發(fā)給數(shù)據(jù)庫的SQL長什么樣。如果函數(shù)沒被正確翻譯成底層方言運(yùn)行結(jié)果基本就會(huì)出問題跟蹤結(jié)果里也能看到具體的報(bào)錯(cuò)。提前預(yù)防的方法其實(shí)很簡單升級前把代碼里所有用到字符串函數(shù)的SQL摘出來逐個(gè)在目標(biāo)系統(tǒng)上用單行表做一次函數(shù)驗(yàn)證確認(rèn)返回值和參數(shù)順序都符合預(yù)期。這個(gè)動(dòng)作看著笨但能省掉上生產(chǎn)之后半夜被叫起來的痛苦。4.4 什么場景該SQL層做什么場景該回ABAP層講了這么多SQL字符串函數(shù)的優(yōu)點(diǎn)但要防止“有了錘子看什么都像釘子”。我的原則是問四個(gè)問題第一結(jié)果集會(huì)不會(huì)很大如果查詢結(jié)果有幾萬行SQL層做好處明顯如果本來就只有幾十行拼不拼接其實(shí)差別不大可讀性優(yōu)先。第二有沒有調(diào)用SAP標(biāo)準(zhǔn)轉(zhuǎn)換例程的需求比如物料號去前導(dǎo)零這種邏輯在SQL里拼REPLACE又危險(xiǎn)又長直接用ABAP里的CONVERSION_EXIT_MATN1_OUTPUT更可靠標(biāo)準(zhǔn)的東西不要自己造輪子。第三是否涉及復(fù)雜正則。Open SQL正則能力有限CDS里的FIND也不支持完整正則語法這種場景直接回ABAP層用FIND REGEX代碼會(huì)好寫很多。第四SQL寫了三層以上嵌套還能不能一眼看懂不能的話拆到ABAP層用中間變量分步處理可維護(hù)性比“一行神跡”重要得多。一句話總結(jié)能用SQL做盡量做但別為了炫技而炫技SQL寫得像天書三個(gè)月后你自己也得重新研究。5. 常見問題與故障排查技巧實(shí)錄5.1 編譯錯(cuò)誤與嚴(yán)格模式ABAP從7.40開始對Open SQL采用嚴(yán)格模式一些數(shù)據(jù)庫特有的方言函數(shù)會(huì)被語法檢查直接攔下比如Oracle的DECODE、TO_CHAR老代碼里很常見新代碼里基本不允許。解決辦法是改成標(biāo)準(zhǔn)SQL表達(dá)式比如DECODE改成CASE WHENTO_CHAR的類型轉(zhuǎn)換用CAST。如果你遇到類似“The function is not allowed here”的報(bào)錯(cuò)先別急著懷疑代碼按這個(gè)順序排查報(bào)錯(cuò)方向可能原因處理思路語法檢查報(bào)函數(shù)不允許用了數(shù)據(jù)庫方言函數(shù)改成ABAP Open SQL內(nèi)置函數(shù)函數(shù)名不存在或未定義當(dāng)前內(nèi)核版本過低確認(rèn)ABAP版本換用版本支持的內(nèi)置函數(shù)函數(shù)放在了不支持的語句位置比如某些版本不支持在WHERE里用調(diào)整寫法把計(jì)算移到SELECT列表或用CASEGROUP BY/ORDER BY里函數(shù)導(dǎo)致報(bào)錯(cuò)使用聚合函數(shù)或別名問題用表達(dá)式本身排序而不是用別名排序5.2 類型不匹配和運(yùn)行時(shí)錯(cuò)誤字符串函數(shù)返回的結(jié)果類型很明確但不少新手栽在這上面。LENGTH、BYTE_LENGTH、LOCATE返回的是整數(shù)如果INTO到一個(gè)字符類型變量里類型轉(zhuǎn)換錯(cuò)誤會(huì)直接拋出來。解決方法很簡單用DATA自動(dòng)推導(dǎo)或者明確聲明成整數(shù)類型。CONCAT返回的字符串長度等于參數(shù)長度之和如果INTO目標(biāo)變量長度不夠輕則數(shù)據(jù)丟失重則運(yùn)行時(shí)異常。我見過一個(gè)經(jīng)典案例有人把拼接好的字段寫進(jìn)ALV的字段目錄但字段目錄長度定義成20實(shí)際數(shù)據(jù)有30程序在刷新ALV時(shí)直接崩潰。處理方式前面也提到拼接后結(jié)合LEFT或SUBSTRING主動(dòng)截?cái)嘧寯?shù)據(jù)長度和目標(biāo)字段定義完全對齊。SUBSTRING的參數(shù)非法也會(huì)報(bào)錯(cuò)起點(diǎn)為0或負(fù)數(shù)、長度為負(fù)數(shù)不同數(shù)據(jù)庫反應(yīng)不一有的報(bào)錯(cuò)有的返回意外結(jié)果。寫SUBSTRING時(shí)先確認(rèn)變量值不會(huì)出現(xiàn)這種邊界情況或者在ABAP層做參數(shù)校驗(yàn)。5.3 用T000做“SQL函數(shù)計(jì)算器”字符串函數(shù)最大的麻煩是“結(jié)果不直觀”。你寫完一個(gè)復(fù)雜嵌套函數(shù)心里沒底不知道返回的到底是什么。最好是有一個(gè)快速驗(yàn)證的方法。我的做法是在SE38里寫個(gè)臨時(shí)測試程序用T000表作為單行來源把函數(shù)結(jié)果直接SELECT出來打印DATA(lv_test) AbC-DEF_123. SELECT SINGLE UPPER( lv_test ) AS upper_val, LOWER( lv_test ) AS lower_val, LENGTH( lv_test ) AS len_val, LEFT( lv_test, 3 ) AS left3, LOCATE( lv_test, DEF ) AS pos_def, CONCAT( lv_test, ok ) AS concat_val FROM t000 WHERE mandt sy-mandt INTO DATA(ls_result). WRITE: ls_result-upper_val, ls_result-lower_val, ls_result-len_val, ls_result-left3, ls_result-pos_def, ls_result-concat_val.T000是系統(tǒng)表正常系統(tǒng)都有且只有當(dāng)前客戶端一行數(shù)據(jù)用WHERE mandt sy-mandt限定后相當(dāng)于一個(gè)穩(wěn)定的“單行計(jì)算器”。這個(gè)方法比去業(yè)務(wù)表里翻數(shù)據(jù)快得多也安全得多。有人會(huì)問為什么不用DUMMY表ABAP Open SQL里沒有標(biāo)準(zhǔn)DUMMY表那是HANA原生的玩法在ABAP里直接用會(huì)報(bào)錯(cuò)。T000是我試驗(yàn)后最順手的替代。這個(gè)技巧對驗(yàn)證參數(shù)順序特別有用。比如拿不準(zhǔn)LOCATE參數(shù)順序就在這個(gè)程序里分別試LOCATE(lv_test,DEF)和LOCATE(DEF,lv_test)看看哪個(gè)返回正確位置一次就能確認(rèn)當(dāng)前系統(tǒng)行為。5.4 排查慢SQL的實(shí)用步驟最后分享一下排查字符串函數(shù)導(dǎo)致慢SQL的完整思路這套方法我用了很多年基本能覆蓋八成問題。第一步從簡單字段開始做最小復(fù)現(xiàn)。把SELECT里的字符串函數(shù)一個(gè)個(gè)拆掉只留下基本字段先確認(rèn)基表本身查詢是否慢。如果基表查詢也要幾十秒那就不是函數(shù)問題是表設(shè)計(jì)和索引問題。第二步用ST05打開SQL跟蹤跑一遍目標(biāo)程序找到實(shí)際下發(fā)的SQL語句。這一步能看清SAP把Open SQL翻譯成了什么函數(shù)到底有沒有正確下推有沒有生成臨時(shí)計(jì)算列。第三步把函數(shù)逐步加回去每加一個(gè)函數(shù)就再跑一次SQL跟蹤觀察執(zhí)行時(shí)間變化。通常會(huì)發(fā)現(xiàn)某個(gè)特定函數(shù)是性能拐點(diǎn)比如WHERE里的UPPER或者GROUP BY里的SUBSTRING。第四步針對性能拐點(diǎn)做方案優(yōu)化能改成冗余字段就改冗余字段能改成前綴匹配就改前綴匹配實(shí)在改不了就把這部分的計(jì)算邏輯移到ABAP層只對預(yù)處理過的結(jié)果集做字符串處理。這套排查法我每次都能用上尤其是系統(tǒng)從ECC遷到S/4HANA后數(shù)據(jù)庫換了很多以前“靠運(yùn)氣跑得動(dòng)”的SQL現(xiàn)在直接慢到不可接受挨個(gè)排查下來基本都能找到函數(shù)使用不當(dāng)?shù)脑?。寫在最后掏個(gè)我自己的笨辦法每學(xué)一個(gè)新的SQL函數(shù)先在測試程序里用T000這個(gè)“單行計(jì)算器”跑一遍看到返回值再往正式代碼里粘。這個(gè)方法幫我避免了很多次在質(zhì)量系統(tǒng)里改完代碼、傳輸上去又被退回來的尷尬。字符串函數(shù)確實(shí)好用但別用得過度一個(gè)SELECT嵌套五六層函數(shù)能看懂的人沒幾個(gè)出了問題也不好查。SQL的價(jià)值在于清晰描述數(shù)據(jù)加工邏輯把代碼寫得像流水線一樣簡潔明了才是長久之道。