055、SELECT單表查詢那天半夜被電話叫醒說生產(chǎn)某個報表轉(zhuǎn)圈圈。登錄系統(tǒng)一查不是程序邏輯死循環(huán)是SQL在數(shù)據(jù)庫里裸奔?？创a一個訂單查詢條件字段是vbeln但屏幕參數(shù)傳進(jìn)來的是numc類型而表字段是charABAP直接隱式轉(zhuǎn)換索引廢掉全表掃描。改成lvbeln p_vbeln類型對齊瞬間從幾十秒變成毫秒級。從那以后我養(yǎng)成習(xí)慣寫SELECT先檢查字段類型匹配。單表查詢聽著簡單真正不出坑的沒幾個。先搭最簡單架子SELECT carrid, connid, fldate FROM sflight INTO wa_flight WHERE carrid LH.這段代碼不是只取一行是隱式循環(huán)每條匹配記錄都會把值塞進(jìn)wa_flight然后往下走。如果你只想拿一條要么補UP TO 1 ROWS要么用SELECT SINGLE。SELECT SINGLE更適合主鍵或唯一條件比如查物料號、客戶號。注意它如果不加WHERE就直接取表里任意一行別這么干。INTO有講究。你寫字段列表INTO工作區(qū)里的結(jié)構(gòu)順序必須一致。比如SELECT a, b, c INTO wa那wa的結(jié)構(gòu)必須是a, b, c這個順序。如果多了少了數(shù)據(jù)錯位不報錯你查半天才發(fā)現(xiàn)wa-b里放的是c的值。這坑我踩過當(dāng)年查一個金濃度查出來的數(shù)據(jù)忽大忽小折騰一晚上最后發(fā)現(xiàn)INTO少了一個字段。不想管順序用INTO CORRESPONDING FIELDS OF wa按名字匹配但多了個字段映射性能稍差。對于小表無所謂大表別用。還有SELECT *的問題。新手最喜歡SELECT * INTO TABLE gt_itab方便嘛。但*會把表的所有字段都撈過來哪怕你只用兩個字段。數(shù)據(jù)傳輸量、內(nèi)存占用、網(wǎng)絡(luò)開銷全被放大。有一次優(yōu)化報表改掉三個SELECT *直接縮掉一半執(zhí)行時間。別懶。單表查詢最常用的批量寫法是SELECT carrid, connid, fldate INTO TABLE gt_flight FROM sflight WHERE carrid LH.這條語句會一次性把所有匹配行塞進(jìn)內(nèi)表中間不經(jīng)過工作區(qū)效率比SELECT ... ENDSELECT高得多。記住這個原則能用INTO TABLE完成的事別用循環(huán)去APPEND。SELECT ... ENDSELECT適合在循環(huán)里處理每行邏輯沒法避免時才用。比如你要逐行算金額、填狀態(tài)那很正常。但如果你只是把數(shù)據(jù)裝進(jìn)內(nèi)表后面用那就INTO TABLE。APPENDING和INTO TABLE的區(qū)別我再說一嘴。INTO TABLE會先清空接收內(nèi)表再插入數(shù)據(jù)APPENDING TABLE不清空在表尾追加。這地方容易迷糊。比如你分多次查不同條件下相同字段想?yún)R總到一個內(nèi)表用APPENDING TABLE。但你要先確保內(nèi)表類型匹配且每次查詢的字段集合一致。有一次我在循環(huán)里查一個個物料描述每次都用INTO TABLE結(jié)果內(nèi)表只有最后一次的數(shù)據(jù)找了半天原因。改成APPENDING就好了。說到WHERE條件除了還有IN、BETWEEN、LIKE。LIKE匹配通配符%代表任意串_代表一個字符。要注意數(shù)據(jù)庫對LIKE的索引使用前導(dǎo)通配符%開頭的條件基本走不了索引。比如查客戶姓名以“張”開頭寫成name LIKE 張%索引還能用寫成name LIKE %張完了全表掃。還有如果字段值里有%或_想當(dāng)普通字符ABAP里可以用ESCAPE關(guān)鍵字指定轉(zhuǎn)義符別生記。另一個坑是SY-SUBRC的判斷。SELECT執(zhí)行完后SY-SUBRC 0表示至少找到一條4表示沒找到。很多人忘記檢查拿著空內(nèi)表往下算然后除零報錯。建議每條SELECT后面緊跟IF sy-subrc 0. 有數(shù)據(jù)正常處理 ELSE. 沒數(shù)據(jù)給個友好提示或者退出 ENDIF.別嫌麻煩出錯時救你命。小技巧查單條數(shù)據(jù)時用UP TO 1 ROWS配合INTO TABLE或INTO wa比SELECT SINGLE更靈活。比如你想取最新一條可以按日期降序排列再加UP TO 1 ROWS。而SELECT SINGLE不支持這種排序取最新。排序用ORDER BY單表查詢里也常用。比如取銷售訂單前10條最新SELECT vbeln, erdat INTO TABLE gt_list FROM vbak ORDER BY erdat DESCENDING UP TO 10 ROWS.注意UP TO 10 ROWS必須放在ORDER BY后面別搞反。還有字段類型轉(zhuǎn)換開頭那個案例。在WHERE條件里盡量讓變量類型和表字段類型一致。如果不一致ABAP會做轉(zhuǎn)換導(dǎo)致謂詞無法使用索引。實在避免不了可以用CONV顯式轉(zhuǎn)換或者用l_field p_field.做個賦值再查。另外如果字段是NUMC類型你傳進(jìn)去一個帶前導(dǎo)零的CHAR也容易出問題。建議平時閱讀表結(jié)構(gòu)用SE11看字段類型心里有數(shù)。調(diào)試技巧事務(wù)碼ST05打開SQL跟蹤執(zhí)行你的程序然后看生成的SQL語句。如果發(fā)現(xiàn)ABAP自動加了一些轉(zhuǎn)換函數(shù)或者條件里出現(xiàn)CAST多半是類型不匹配。ST05里還能看到讀取的表、次數(shù)、掃描行數(shù)。我有次發(fā)現(xiàn)一個查詢實際執(zhí)行了1000多次結(jié)果優(yōu)化成一次批量查詢性能提升幾十倍。多花五分鐘跟蹤SQL值。老生常談一下寫單表查詢時先明確你要哪些字段哪些是篩選條件哪些需要排序。別一股腦SELECT *別把條件寫寬。比如狀態(tài)字段它本身索引價值低如果還用LIKE更糟。能精確匹配就精確匹配能縮小范圍就縮小范圍。字段多了INTO CORRESPONDING也會有額外開銷盡量手寫字段列表。最后給個經(jīng)驗處理完數(shù)據(jù)后如果內(nèi)表很大用完了記得CLEAR或者FREE。FREE會釋放內(nèi)存CLEAR只清空內(nèi)容。尤其長會話里大內(nèi)表占用內(nèi)存不釋放影響后續(xù)調(diào)用。別小看這個我之前見過一個程序跑幾次就把內(nèi)存吃光就是沒釋放。單表查詢是整個ABAP SQL的基石。你把它寫干凈性能穩(wěn)一半。后面多表關(guān)聯(lián)、子查詢、批量操作全是這些基礎(chǔ)規(guī)則疊加上去。記住每次SELECT前想想索引想想數(shù)據(jù)類型想想目的地。不用急掉幾次坑就記住了。少點廢話多跑ST05。