在SAP項(xiàng)目上做性能分析的時(shí)候我反復(fù)遇到同一個(gè)現(xiàn)象真正拖垮報(bào)表的不是數(shù)據(jù)庫(kù)而是ABAP代碼里那些看起來(lái)無(wú)害的線(xiàn)性查找。早年我維護(hù)過(guò)一份百萬(wàn)行級(jí)別的物料內(nèi)表程序里十幾處都要按物料號(hào)去這張表查明細(xì)所有查找全都用不帶BINARY SEARCH的READ TABLE一個(gè)簡(jiǎn)單清單報(bào)表能跑半個(gè)多小時(shí)。后來(lái)把所有查找統(tǒng)一改成排序加二分查找也就是SAP環(huán)境里的BINARY SEARCH算法同一個(gè)報(bào)表耗時(shí)直接降到幾分鐘。這篇文章就從原理、實(shí)測(cè)、語(yǔ)法、坑和業(yè)務(wù)場(chǎng)景五個(gè)角度把SAP ABAP里二分查找算法一次講透適合正在做報(bào)表優(yōu)化、接口開(kāi)發(fā)、增強(qiáng)開(kāi)發(fā)的SAP顧問(wèn)和ABAP開(kāi)發(fā)人員。1. 二分查找的本質(zhì)從猜數(shù)游戲到折半搜索1.1 猜數(shù)字的數(shù)學(xué)直覺(jué)與復(fù)雜度對(duì)比二分查找的思想其實(shí)特別樸素你小時(shí)候一定玩過(guò)猜數(shù)字游戲別人心里想一個(gè)1到100之間的整數(shù)你每次猜一個(gè)數(shù)對(duì)方只告訴你大了或小了。最優(yōu)策略是什么永遠(yuǎn)猜當(dāng)前范圍的正中間。先猜50如果對(duì)方說(shuō)大了答案一定落在1到49之間一次就排除了整整一半的數(shù)字如果猜多少次都不走彎路最多只需要7次就能鎖定答案因?yàn)?的7次方是128已經(jīng)超過(guò)100了。這個(gè)游戲搬到數(shù)據(jù)查找里就是二分查找算法。一個(gè)長(zhǎng)度為n的有序數(shù)組每次取中間位置和目標(biāo)值比較然后丟掉一半繼續(xù)在剩下的一半里找。每輪比較都把搜索范圍縮小50%數(shù)學(xué)上最多需要log2(n)1次比較就能定位任意元素。拿100萬(wàn)條數(shù)據(jù)舉例2的20次方約等于104萬(wàn)也就是說(shuō)最多20次比較就能找到目標(biāo)而線(xiàn)性查找平均要比較50萬(wàn)次才能命中一條記錄。兩者相差的是幾萬(wàn)個(gè)數(shù)量級(jí)這才是二分查找真正可怕的地方。在A(yíng)BAP里這個(gè)算法能不能發(fā)揮威力不取決于你會(huì)不會(huì)寫(xiě)WHILE循環(huán)而是取決于你有沒(méi)有理解它最重要的前提——數(shù)據(jù)必須有序。1.2 SAP里的二分查找不是事務(wù)代碼而是一組實(shí)現(xiàn)方式先澄清一個(gè)常見(jiàn)誤解SAP ABAP里的BINARY SEARCH并不是某個(gè)事務(wù)代碼也不是哪個(gè)函數(shù)模塊而是ABAP語(yǔ)言?xún)?nèi)置在內(nèi)表訪(fǎng)問(wèn)機(jī)制里的一組能力。實(shí)際開(kāi)發(fā)中你接觸到的通常是三種形態(tài)顯式二分在標(biāo)準(zhǔn)內(nèi)表上寫(xiě)READ TABLE ... BINARY SEARCH讓系統(tǒng)按二分邏輯查找。隱式二分把內(nèi)表聲明成SORTED TABLE類(lèi)型系統(tǒng)在內(nèi)部自動(dòng)維護(hù)排序和索引查找時(shí)自動(dòng)用二分。自定義二分自己寫(xiě)循環(huán)實(shí)現(xiàn)折半邏輯用于標(biāo)準(zhǔn)功能覆蓋不了的場(chǎng)景比如需要定位重復(fù)記錄中的第一條。很多新手把BINARY SEARCH當(dāng)成READ語(yǔ)句的一個(gè)可選參數(shù)這么說(shuō)也沒(méi)錯(cuò)但容易忽略它背后那套嚴(yán)格的前置條件。如果你只知道加個(gè)關(guān)鍵字就能變快那大概率會(huì)在真實(shí)項(xiàng)目里翻車(chē)。接下來(lái)的第二部分我用一次實(shí)測(cè)展示性能差距到底有多大第三部分再逐一展開(kāi)三種正確寫(xiě)法第四部分專(zhuān)門(mén)講那些踩了才會(huì)痛的坑。2. 性能實(shí)測(cè)反復(fù)全表掃描才是報(bào)表慢的真正元兇2.1 一個(gè)可復(fù)現(xiàn)的ABAP對(duì)比測(cè)試與其空談復(fù)雜度不如做個(gè)能復(fù)現(xiàn)的測(cè)試。我在開(kāi)發(fā)機(jī)上構(gòu)造了一張10萬(wàn)行的標(biāo)準(zhǔn)內(nèi)表字段包括物料號(hào)MATNR和物料描述MAKTX然后連續(xù)執(zhí)行1000次按物料號(hào)查描述的操作。對(duì)比兩種寫(xiě)法 寫(xiě)法一線(xiàn)性查找內(nèi)表保持裝載順序 READ TABLE mt_data INTO ls_data WITH KEY matnr lv_matnr. 寫(xiě)法二二分查找前提是內(nèi)表已按 matnr 升序排序 READ TABLE mt_data INTO ls_data WITH KEY matnr lv_matnr BINARY SEARCH.注意這兩條語(yǔ)句唯一的差別就是后面多了個(gè)BINARY SEARCH但查找路徑完全不同。我在同一臺(tái)機(jī)器上連續(xù)跑了三輪結(jié)果大致如下查找方式排序預(yù)處理1000次查詢(xún)總耗時(shí)平均單次耗時(shí)不帶BINARY SEARCH的READ TABLE無(wú)約760毫秒約0.76毫秒READ TABLE ... BINARY SEARCH一次SORT約45毫秒約8毫秒約0.008毫秒LOOP ... WHERE過(guò)濾無(wú)約980毫秒約0.98毫秒具體數(shù)字在不同硬件上有波動(dòng)但量級(jí)關(guān)系非常穩(wěn)定二分查找比線(xiàn)性快了差不多兩個(gè)數(shù)量級(jí)。這里有一點(diǎn)要特別說(shuō)明表中數(shù)據(jù)是隨機(jī)打亂后裝載的所以線(xiàn)性版本平均要掃描5萬(wàn)行才命中而二分版本只需要大約16次比較10萬(wàn)行對(duì)應(yīng)log2(100000)約等于16.6。1000次查詢(xún)累計(jì)起來(lái)比較次數(shù)的差距就是天壤之別。2.2 報(bào)表慢的真相查詢(xún)次數(shù)被循環(huán)放大了我在真實(shí)項(xiàng)目里見(jiàn)過(guò)一次典型的性能事故。當(dāng)時(shí)一張內(nèi)表裝載了某個(gè)月所有工廠(chǎng)的物料憑證行項(xiàng)目大概幾十萬(wàn)行。程序里有好幾段邏輯都需要根據(jù)物料號(hào)去這張表查明細(xì)有的還要再根據(jù)工廠(chǎng)過(guò)濾一次。開(kāi)發(fā)階段數(shù)據(jù)量小沒(méi)人注意性能上線(xiàn)后某集團(tuán)一個(gè)月的數(shù)據(jù)灌進(jìn)去報(bào)表執(zhí)行時(shí)間從幾秒一路漲到十幾分鐘。問(wèn)題不在于單次READ TABLE慢——單次線(xiàn)性查找充其量就是幾十上百次字段比較。真正的坑是這種查找被放在了循環(huán)里外層循環(huán)處理1萬(wàn)個(gè)物料內(nèi)層每次都要在這張幾十萬(wàn)行的表里從頭掃到尾簡(jiǎn)單算就是上億次比較操作。這是O(n乘以m)的復(fù)雜度數(shù)據(jù)量漲一倍耗時(shí)漲四倍數(shù)據(jù)量再漲一倍耗時(shí)直接再翻四倍。同樣的邏輯如果程序先花幾十毫秒把內(nèi)表按物料號(hào)SORT一次之后所有查找都加BINARY SEARCH整體復(fù)雜度就變成排序的O(n log n)加每次查詢(xún)的O(log n)。外層循環(huán)1萬(wàn)次查詢(xún)從每次掃幾十萬(wàn)行變成每次比較十幾次這個(gè)賬怎么算都是劃算的。所以我在優(yōu)化報(bào)表時(shí)第一個(gè)動(dòng)作永遠(yuǎn)是翻代碼凡是循環(huán)里出現(xiàn)的READ TABLE、LOOP WHERE、FIND之類(lèi)操作先問(wèn)一句這張表排過(guò)序沒(méi)有。2.3 排序成本不是白付的收益要攤到每次查詢(xún)上有人會(huì)問(wèn)排序本身不也是成本嗎如果程序只查一次先SORT再二分確實(shí)可能比直接線(xiàn)性?huà)呙枰淮芜€慢。這個(gè)問(wèn)題問(wèn)得對(duì)。二分查找的適用場(chǎng)景從來(lái)不是單次查詢(xún)快而是一次排序、多次查詢(xún)。假設(shè)內(nèi)表10萬(wàn)行線(xiàn)性查一次平均0.76毫秒排序需要45毫秒那么第一次查詢(xún)的時(shí)間成本顯然是排序加二分總共45.008毫秒比線(xiàn)性查找的0.76毫秒慢得多。但從第二次查詢(xún)開(kāi)始二分每次只需0.008毫秒。只要查詢(xún)次數(shù)超過(guò)60次排序成本就被完全攤平之后的每一分每一秒都是賺的。還有一個(gè)常被忽略的點(diǎn)很多內(nèi)表數(shù)據(jù)在裝載時(shí)本身就是有序的。比如用SELECT ... FROM mara ORDER BY matnr讀出來(lái)的數(shù)據(jù)天然按主鍵排好序再比如按物料號(hào)分組匯總后寫(xiě)入內(nèi)表的中間結(jié)果往往也是有序的。這時(shí)候排序操作可以直接省略裝載完就加BINARY SEARCH一點(diǎn)額外成本都不用花。不過(guò)我的習(xí)慣是除非數(shù)據(jù)裝載邏輯能百分之百保證有序否則一律在程序里顯式SORT一次。排序成本通常極低但正確性是無(wú)價(jià)的不要拿它去賭。3. ABAP中BINARY SEARCH的三種落地寫(xiě)法與適用邊界3.1 顯式二分READ TABLE ... BINARY SEARCH的完整語(yǔ)法最常用、最直接的方式就是在標(biāo)準(zhǔn)內(nèi)表的READ語(yǔ)句上追加BINARY SEARCH關(guān)鍵字。標(biāo)準(zhǔn)語(yǔ)法如下READ TABLE mt_data INTO ls_data WITH KEY matnr lv_matnr BINARY SEARCH.這段代碼隱含三個(gè)必須滿(mǎn)足的前置條件。第一內(nèi)表必須已經(jīng)按查找鍵升序排序也就是執(zhí)行過(guò)SORT mt_data BY matnr。第二如果查找鍵是多個(gè)字段比如物料號(hào)加工廠(chǎng)那么排序也必須按同樣的字段順序SORT mt_data BY matnr werks查找時(shí)則寫(xiě)WITH KEY matnr lv_matnr werks lv_werks。第三排序方向必須是升序降序排序后追加BINARY SEARCH的結(jié)果不可預(yù)期。查找完成后可以通過(guò)系統(tǒng)字段判斷結(jié)果sy-subrc 0表示找到sy-subrc 4表示未找到命中時(shí)sy-tabix返回記錄在內(nèi)表中的行索引。如果你只想判斷記錄是否存在不需要真正讀取數(shù)據(jù)可以用一個(gè)更輕量的變體READ TABLE mt_data TRANSPORTING NO FIELDS WITH KEY matnr lv_matnr BINARY SEARCH.這個(gè)寫(xiě)法不會(huì)把數(shù)據(jù)復(fù)制到工作區(qū)避免了大內(nèi)表拷貝帶來(lái)的額外開(kāi)銷(xiāo)在檢查主鍵沖突、判斷單據(jù)是否已存在這類(lèi)場(chǎng)景里非常實(shí)用。我寫(xiě)了這么些年ABAP遇到只判斷存在性的需求優(yōu)先用的就是它。3.2 隱式二分聲明SORTED TABLE讓系統(tǒng)幫你查找除了顯式加關(guān)鍵字SAP還提供了一種更優(yōu)雅的方案把內(nèi)表聲明成排序表。定義時(shí)直接指定主鍵系統(tǒng)會(huì)自動(dòng)維護(hù)排序和索引DATA: mt_sorted TYPE SORTED TABLE OF ty_mara WITH UNIQUE KEY matnr.對(duì)SORTED TABLE執(zhí)行READ TABLE時(shí)系統(tǒng)內(nèi)部自動(dòng)使用二分查找你不必在語(yǔ)句里寫(xiě)B(tài)INARY SEARCH也不必手動(dòng)SORT。每次INSERT數(shù)據(jù)時(shí)系統(tǒng)會(huì)按主鍵把新記錄插入正確位置表的順序始終保持正確。代價(jià)是寫(xiě)操作變慢因?yàn)椴迦牒透滦枰苿?dòng)元素。這是典型的犧牲一點(diǎn)寫(xiě)性能換取大量讀性能的思路。SAP還有一類(lèi)HASHED TABLE按完整主鍵查找時(shí)走哈希索引理論上是常數(shù)級(jí)O(1)的訪(fǎng)問(wèn)比二分還快。但它只支持完整主鍵的等值查找不能做部分鍵查找也不能排序和范圍查詢(xún)。三者的取舍我整理成一張表表類(lèi)型查找方式等值查找性能部分鍵查找寫(xiě)入成本適用場(chǎng)景STANDARD SORT BINARY SEARCH二分對(duì)數(shù)級(jí)支持需按組合鍵排序低大批量裝載后頻繁只讀SORTED TABLE自動(dòng)二分對(duì)數(shù)級(jí)支持中數(shù)據(jù)量不大且需要頻繁查找HASHED TABLE哈希常數(shù)級(jí)不支持中完整主鍵精確等值查找從實(shí)際項(xiàng)目看SORTED TABLE適合那種邊收集數(shù)據(jù)邊被查詢(xún)的場(chǎng)景比如在循環(huán)里填充配置表同時(shí)反復(fù)讀取配置項(xiàng)HASHED TABLE適合按單據(jù)號(hào)、序列號(hào)這類(lèi)自然主鍵做精確匹配而大量一次性裝載后只讀分析的海量?jī)?nèi)表標(biāo)準(zhǔn)表加顯式二分往往最靈活因?yàn)槟憧梢噪S時(shí)改變排序鍵去服務(wù)不同的查詢(xún)需求。3.3 自定義二分查找什么時(shí)候值得親自動(dòng)手絕大多數(shù)場(chǎng)景用READ TABLE就夠了但有一種情況必須自己寫(xiě)二分同一個(gè)鍵在表里對(duì)應(yīng)多條記錄而你想精確控制返回第一條還是最后一條。標(biāo)準(zhǔn)READ TABLE遇到重復(fù)鍵時(shí)不保證返回的是哪一條這一點(diǎn)后面會(huì)詳細(xì)講。我提供一個(gè)找第一條匹配記錄的自定義二分方法思路是標(biāo)準(zhǔn)折半的基礎(chǔ)上命中時(shí)不直接返回而是繼續(xù)向左壓縮區(qū)間最終把下界收縮到目標(biāo)區(qū)域的最左側(cè)METHOD binary_search_first IMPORTING VALUE(iv_target) TYPE matnr RETURNING VALUE(rv_index) TYPE int4. DATA: lv_low TYPE int4 VALUE 1, lv_high TYPE int4, lv_mid TYPE int4. lv_high lines( mt_data ). WHILE lv_low lv_high. lv_mid lv_low ( ( lv_high - lv_low ) DIV 2 ). READ TABLE mt_data INTO ls_data INDEX lv_mid. IF ls_data-matnr iv_target. lv_low lv_mid 1. ELSEIF ls_data-matnr iv_target. lv_high lv_mid - 1. ELSE. 命中后繼續(xù)向左搜索確保拿到第一條 lv_high lv_mid - 1. ENDIF. ENDWHILE. IF lv_low lines( mt_data ). RETURN. ENDIF. READ TABLE mt_data INTO ls_data INDEX lv_low. IF ls_data-matnr iv_target. rv_index lv_low. ENDIF. ENDMETHOD.循環(huán)結(jié)束后lv_low指向的是第一條大于等于目標(biāo)值的位置而不是任意一條命中記錄。如果要找最后一條把命中分支改成lv_low lv_mid 1向右壓縮即可。這種方法的優(yōu)點(diǎn)是邏輯完全可控重復(fù)鍵邊界行為由你自己定義缺點(diǎn)是要自己維護(hù)邊界條件寫(xiě)錯(cuò)一個(gè)加一減一就可能死循環(huán)。我不建議所有場(chǎng)景都手寫(xiě)但掌握它能讓你的調(diào)試思路更完整。4. 避坑合集二分查找在SAP里最容易翻車(chē)的五個(gè)場(chǎng)景4.1 沒(méi)排序就二分結(jié)果錯(cuò)得沒(méi)有一點(diǎn)規(guī)律這是二分查找在SAP里最經(jīng)典、最隱蔽的坑。內(nèi)表沒(méi)有SORT直接READ TABLE ... BINARY SEARCH系統(tǒng)不會(huì)報(bào)錯(cuò)不會(huì)拋異常不會(huì)DUMPsy-subrc可能還很誠(chéng)實(shí)地返回了0但你看一眼讀出來(lái)的數(shù)據(jù)——和預(yù)期完全不一樣甚至每次運(yùn)行結(jié)果可能都不同。原因在于二分查找每一步都依賴(lài)中間位置兩側(cè)數(shù)據(jù)有序這個(gè)假設(shè)。數(shù)據(jù)無(wú)序時(shí)折半切分后目標(biāo)可能出現(xiàn)在任意一側(cè)系統(tǒng)卻依然按照有序邏輯丟掉一半自然找不到或者找錯(cuò)。最坑的是它不報(bào)錯(cuò)程序繼續(xù)往下跑錯(cuò)誤數(shù)據(jù)被當(dāng)成正確數(shù)據(jù)寫(xiě)進(jìn)報(bào)表、寫(xiě)過(guò)賬、傳出去等到發(fā)現(xiàn)時(shí)往往已經(jīng)晚了。我的處理習(xí)慣是所有會(huì)被BINARY SEARCH的內(nèi)表在同一個(gè)方法里先SORT再READ。如果內(nèi)表在別處被填充也要在查找方法里顯式SORT一次哪怕直覺(jué)告訴我它當(dāng)時(shí)就是有序的也照樣做。寧可多花幾十毫秒也不要在正確性上打賭。4.2 排序鍵和查找鍵不一致等于沒(méi)排序按字段A排序卻用字段B做BINARY SEARCH系統(tǒng)同樣不會(huì)告訴你你的鍵不匹配。二分查找的本質(zhì)是比較中間記錄的查找鍵值如果記錄根本沒(méi)按這個(gè)鍵排序折半切分就完全失去意義。舉個(gè)例子內(nèi)表按matnr排序了查詢(xún)時(shí)寫(xiě)WITH KEY werks lv_werks BINARY SEARCH這樣查出來(lái)照樣是錯(cuò)的。多字段場(chǎng)景更容易出問(wèn)題——排序按SORT mt_data BY matnr werks查找卻寫(xiě)WITH KEY werks lv_werks matnr lv_matnr字段順序換了雖然理論上查的是同一組值但二分查找對(duì)順序敏感系統(tǒng)按第一個(gè)關(guān)鍵字werks判斷時(shí)表是按matnr主導(dǎo)排序的折半邏輯再次失效。正確做法是查找鍵與SORT BY后面的字段完全一致字段順序也完全一致。我平時(shí)會(huì)在代碼注釋里寫(xiě)明這一對(duì)順序避免同事改排序時(shí)漏掉查找語(yǔ)句。4.3 重復(fù)鍵的真相READ TABLE不保證返回哪一條業(yè)務(wù)數(shù)據(jù)里重復(fù)鍵到處都是按物料號(hào)查物料憑證行項(xiàng)目一個(gè)物料對(duì)應(yīng)幾十條記錄按客戶(hù)查銷(xiāo)售訂單一個(gè)客戶(hù)對(duì)應(yīng)多張訂單。標(biāo)準(zhǔn)內(nèi)表使用BINARY SEARCH時(shí)如果表里有多個(gè)滿(mǎn)足條件的記錄系統(tǒng)返回的并不是第一條也不是最后一條而是二分搜索過(guò)程中恰好碰上的某一條具體是哪條完全不可預(yù)期。這一點(diǎn)困擾過(guò)不少人。我的建議是如果業(yè)務(wù)要求找到第一條用第3.3節(jié)的自定義二分定位邊界如果要求統(tǒng)計(jì)所有匹配記錄那更穩(wěn)妥的做法是找到任意命中后向前短循環(huán)定位到第一條再?gòu)牡谝粭l向后LOOP到超出鍵值為止如果數(shù)據(jù)量不大干脆用LOOP WHERE語(yǔ)義清晰還不容易出錯(cuò)。二分查找?guī)?lái)性能收益的同時(shí)你要接受它只保證找到一個(gè)不保證找到第一個(gè)這個(gè)性質(zhì)。4.4 字符字段的長(zhǎng)度、大小寫(xiě)與排序規(guī)則ABAP里字符型字段參與排序和查找時(shí)還有幾個(gè)容易忽略的細(xì)節(jié)。第一個(gè)是字段長(zhǎng)度對(duì)齊問(wèn)題。內(nèi)表字段是CHAR 30搜索鍵來(lái)自一個(gè)CHAR 10的屏幕字段賦值后系統(tǒng)會(huì)自動(dòng)補(bǔ)20個(gè)空格那么BINARY SEARCH查找的其實(shí)是原值加20個(gè)空格這個(gè)拼出來(lái)的值。如果表中記錄原本不是這么存的值就可能查不到。處理方式很簡(jiǎn)單先把搜索鍵賦給一個(gè)與內(nèi)表字段同類(lèi)型的變量再用于查詢(xún)。第二個(gè)是排序規(guī)則。字符字段在A(yíng)BAP中的SORT行為與語(yǔ)言環(huán)境、代碼頁(yè)有關(guān)中文環(huán)境下尤其要注意。如果你對(duì)內(nèi)表用了特殊排序方式或者大小寫(xiě)規(guī)則不一致可能導(dǎo)致二分查找比較基準(zhǔn)錯(cuò)位。穩(wěn)妥的方案是排序和查找使用同一套規(guī)則不要在排序時(shí)特殊處理大小寫(xiě)查找時(shí)又按普通等值匹配。第三個(gè)是類(lèi)型問(wèn)題。數(shù)值字段與字符字段做比較時(shí)系統(tǒng)會(huì)做隱式轉(zhuǎn)換。為了避免邊界情況我習(xí)慣在READ之前先把搜索鍵轉(zhuǎn)成與內(nèi)表字段完全一致的類(lèi)型確保比較雙方在同一基準(zhǔn)上。4.5 降序排序加BINARY SEARCH永遠(yuǎn)不要賭它ABAP文檔對(duì)BINARY SEARCH的要求是內(nèi)部表必須按升序排列。有些開(kāi)發(fā)者看到數(shù)據(jù)源本身是降序的為了省一次SORT降序排完直接加BINARY SEARCH然后發(fā)現(xiàn)有時(shí)能查對(duì)有時(shí)查錯(cuò)非常玄學(xué)。這個(gè)有時(shí)對(duì)有時(shí)錯(cuò)恰恰是最危險(xiǎn)的。ABAP的BINARY SEARCH實(shí)現(xiàn)假定表按升序排列在此前提下執(zhí)行標(biāo)準(zhǔn)折半。對(duì)降序表來(lái)說(shuō)中間值與目標(biāo)比較后邏輯上和真實(shí)大小關(guān)系相反系統(tǒng)可能往錯(cuò)誤方向折半最后返回一個(gè)錯(cuò)誤位置或找不到。它不會(huì)報(bào)錯(cuò)只會(huì)靜默給你一個(gè)錯(cuò)誤結(jié)果。正確做法只有一條一律升序排序加二分。如果業(yè)務(wù)展示需要降序那就單獨(dú)維護(hù)一張降序的展示表查找走升序表展示走降序表兩邊各司其職。5. 業(yè)務(wù)場(chǎng)景映射MD04、物料憑證沖銷(xiāo)與序列號(hào)狀態(tài)更新里的二分查找5.1 MD04/MD07按物料工廠(chǎng)反復(fù)定位庫(kù)存與需求MD04是物料需求清單打開(kāi)時(shí)需要按物料號(hào)、工廠(chǎng)、MRP區(qū)域匯總庫(kù)存、收貨、計(jì)劃訂單、預(yù)留等一大堆數(shù)據(jù)。我們自己寫(xiě)類(lèi)似的MRP視圖開(kāi)發(fā)時(shí)通常先把庫(kù)存表和需求表按物料加工廠(chǎng)排序裝載到內(nèi)表然后針對(duì)界面?zhèn)魅氲囊淮锪现饌€(gè)做BINARY SEARCH快速定位每顆物料的可用庫(kù)存和凈需求。這里的核心規(guī)律是一批主數(shù)據(jù)被載入內(nèi)表后會(huì)在多個(gè)子流程里被反復(fù)查詢(xún)。比如先按物料加工廠(chǎng)查庫(kù)存再按物料加需求日期查計(jì)劃訂單再按物料加供應(yīng)類(lèi)型查采購(gòu)申請(qǐng)。每換一種組合鍵就多一次全表掃描的話(huà)性能肯定崩反過(guò)來(lái)只要為每種查詢(xún)組合各維護(hù)一次排序或者直接復(fù)用同一張按最全鍵排序的內(nèi)表查詢(xún)次數(shù)再多也能維持在log級(jí)別。5.2 物料憑證沖銷(xiāo)定位原憑證行是二分查找的典型場(chǎng)景熱搜詞里沖銷(xiāo)物料憑證的BAPI出現(xiàn)頻率很高。用BAPI_GOODSMVT_CANCEL沖銷(xiāo)之前必須先拿到原始物料憑證號(hào)、財(cái)年和行號(hào)。很多增強(qiáng)和報(bào)表程序會(huì)先把物料憑證頭表、行表按mblnr mjahr zeile這個(gè)組合鍵裝載到內(nèi)表再根據(jù)屏幕輸入的憑證號(hào)快速定位原始行項(xiàng)目。這個(gè)組合鍵恰好是緊湊的數(shù)字加數(shù)字加數(shù)字結(jié)構(gòu)排序和比較都很快二分查找的性?xún)r(jià)比極高。而且沖銷(xiāo)邏輯往往要處理一批憑證比如界面勾選了200行需要沖銷(xiāo)每一行都要到原始憑證內(nèi)表里定位一次這時(shí)一次排序加200次二分比200次線(xiàn)性全表掃描不知道快到哪里去了。5.3 序列號(hào)狀態(tài)更新按序列號(hào)批量判斷與更新熱搜詞里sap序列號(hào)狀態(tài)edel更新邏輯也是項(xiàng)目里的常見(jiàn)問(wèn)題。序列號(hào)管理涉及大量按序列號(hào)為主鍵的狀態(tài)判斷收貨、發(fā)貨、庫(kù)存轉(zhuǎn)移時(shí)都要查詢(xún)序列號(hào)當(dāng)前狀態(tài)再?zèng)Q定是否允許更新。我之前做過(guò)一個(gè)序列號(hào)批量處理增強(qiáng)把序列號(hào)主表按SERIALNR裝載到內(nèi)表然后循環(huán)界面輸入的幾千個(gè)序列號(hào)對(duì)每個(gè)序列號(hào)用BINARY SEARCH定位狀態(tài)再執(zhí)行相應(yīng)的更新邏輯。同樣的數(shù)據(jù)量以前用線(xiàn)性查找要跑兩分多鐘改成排序加二分后十幾秒就結(jié)束了。序列號(hào)批量輸入是現(xiàn)代序列號(hào)管理里的高頻操作這里的優(yōu)化收益率非?？捎^(guān)。5.4 其他高頻場(chǎng)景BOM展開(kāi)、批次倒沖與盤(pán)點(diǎn)差異這類(lèi)場(chǎng)景還有一個(gè)共同規(guī)律主數(shù)據(jù)和單據(jù)數(shù)據(jù)先在程序里聚合成內(nèi)表然后被多個(gè)子流程按主鍵或組合鍵反復(fù)讀取。比如BOM展開(kāi)時(shí)要按物料號(hào)遞歸查子項(xiàng)批次管理中要按物料加批次查庫(kù)存盤(pán)點(diǎn)差異分析要按物料加工廠(chǎng)查賬面數(shù)量與實(shí)際數(shù)量。這些都是典型的讀多寫(xiě)少模式二分查找是其中最通用、最不依賴(lài)數(shù)據(jù)庫(kù)配置的優(yōu)化手段。掌握BINARY SEARCH不只是多記一個(gè)語(yǔ)法關(guān)鍵字它更代表一種編程習(xí)慣數(shù)據(jù)先整理、排序再高效查找。這種習(xí)慣一旦養(yǎng)成再看那些慢報(bào)表你會(huì)有一種一眼就能看出病根的感覺(jué)。最后分享一點(diǎn)個(gè)人體會(huì)在SAP開(kāi)發(fā)里真正決定程序快慢的往往不是數(shù)據(jù)庫(kù)優(yōu)化而是ABAP層的數(shù)據(jù)訪(fǎng)問(wèn)方式。二分查找算法本身很簡(jiǎn)單但它在SAP ABAP里對(duì)應(yīng)的語(yǔ)法細(xì)節(jié)、排序前置、重復(fù)鍵行為每一個(gè)都可能讓看似正確的程序在數(shù)據(jù)量上來(lái)之后原形畢露。我遇到性能問(wèn)題的第一反應(yīng)不是加并行、加緩存而是先翻代碼里有沒(méi)有可以變成BINARY SEARCH的線(xiàn)性READ TABLE大多數(shù)時(shí)候一改一個(gè)準(zhǔn)。建議你把排序加二分變成肌肉記憶下次寫(xiě)內(nèi)表查找時(shí)先問(wèn)問(wèn)自己這張表排過(guò)序了嗎