今天接到一個優(yōu)化需求，跑個程序要12+個小時，周期是每天一次，所以時效性極差，不能響應快速的實際業(yè)務需求，下面我們看一段LIKE的優(yōu)化方法。

SELECT ? ? bukrs

? ?? ?? ???werks

? ?? ?? ???lgort

? ?? ?? ???matnr

? ?? ?? ???lifnr

? ?? ?? ???sobkz

? ?? ?? ???servg

? ?? ?? ???matkl

? ?? ?? ???prdha

? ?? ?? ???labst

? ?? ?? ???ean11

? ?? ?APPENDING CORRESPONDING FIELDS OF TABLE i_s770

? ?? ?FROM s770

? ???WHERE matnr IN s_matnr

? ?? ? AND servg = ''

? ?? ? AND sobkz = ''

? ?? ? AND bukrs IN r_bukrs

? ?? ? AND werks IN r_werks

? ?? ? AND ( lgort = '0001' OR lgort = '0002' OR lgort = '0003' OR lgort = '0005' OR

? ?? ?? ?? ? lgort LIKE '7%' OR lgort LIKE '8%' OR lgort LIKE '9%' OR lgort LIKE 'A%' OR

? ?? ?? ?? ? lgort LIKE 'B%' OR lgort LIKE 'C%' OR lgort LIKE 'D%' OR lgort LIKE 'E%' OR

? ?? ?? ?? ? lgort LIKE 'F%' OR lgort LIKE 'G%' OR lgort LIKE 'H%' OR lgort LIKE 'I%' )

? ?? ? %_HINTS ORACLE 'FULL(S770)'.

其實這條語句以前已經(jīng)被三星的顧問優(yōu)化過了，現(xiàn)在看看還有可優(yōu)化的潛力；%_HINTS ORACLE 'FULL(S770)'是掃描全表的意思，一條條查找，不寫走索引反而會很慢。

下面是測試案例：
1、se30測試這兩種語句的性能

DATA: record_count TYPE INT4.

RANGES: r_lgort FOR s770-bukrs.

r_lgort-sign = 'I'.

r_lgort-option = 'BT'.

r_lgort-low = '7000'.

r_lgort-high = '9ZZZ'.

APPEND r_lgort.

SELECT count(*) INTO record_count FROM s770?

WHERE lgort IN r_lgort.

WRITE:record_count.

DATA: record_count TYPE INT4.

SELECT count(*) INTO record_count FROM s770?

WHERE lgort LIKE '7%' OR?

? ?? ?lgort LIKE '8%' OR lgort LIKE '9%'.

WRITE:record_count.

2、然后我們se38新建一個程序，看看這兩條sql查詢的數(shù)量是否一致

看到了吧，性能提升明顯，快到一半了！但是這還不夠快，因為sql中還有模糊查詢，我們可以用下面的這種方法：

??SELECT ? bukrs

? ?? ?? ???werks

? ?? ?? ???lgort

? ?? ?? ???matnr

? ?? ?? ???lifnr

? ?? ?? ???sobkz

? ?? ?? ???servg

? ?? ?? ???matkl

? ?? ?? ???prdha

? ?? ?? ???labst

? ?? ?? ???ean11

? ?? ?APPENDING CORRESPONDING FIELDS OF TABLE i_s770

? ?? ?FROM s770

? ???WHERE matnr IN s_matnr

? ?? ? AND servg = ''

? ?? ? AND sobkz = ''

? ?? ? AND bukrs IN r_bukrs

? ?? ? AND werks IN r_werks.

??LOOP AT i_s770.

? ? IF i_s770-lgort = '0001' OR i_s770-lgort = '0002' OR i_s770-lgort = '0003' OR i_s770-lgort = '0005'.

? ?? ?CONTINUE.

? ? ELSEIF i_s770-lgort+0(1) NE '7' AND i_s770-lgort+0(1) NE '8' AND i_s770-lgort+0(1) NE '9'

? ?? ? AND i_s770-lgort+0(1) NE 'A' AND i_s770-lgort+0(1) NE 'B' AND i_s770-lgort+0(1) NE 'C'

? ?? ? AND i_s770-lgort+0(1) NE 'D' AND i_s770-lgort+0(1) NE 'E' AND i_s770-lgort+0(1) NE 'F'

? ?? ? AND i_s770-lgort+0(1) NE 'G' AND i_s770-lgort+0(1) NE 'H' AND i_s770-lgort+0(1) NE 'I'.

? ?? ?DELETE i_s770.

? ? ENDIF.

??ENDLOOP.

這樣處理內(nèi)表比在數(shù)據(jù)庫 里直接處理就快多了。

Tips：

當執(zhí)行SQL時，如果有符合選擇條件的INDEX存在，但是數(shù)據(jù)庫并未按照INDEX來執(zhí)行，那么我們可以在SQL語句中明確的寫上執(zhí)行的INDEX。


①用過的兩個寫法：
1、指定使用全表掃描：%_HINTS ORACLE 'FULL(table_name)'
2、指定索引：%_HINTS ORACLE 'INDEX(table_name index_name)'
其他Oracle Hints的寫法可以參見這篇文章：Oracle Hint的用法,在SQL語句優(yōu)化過程中，經(jīng)常會用到hint。
②Using secondary indexes
Consider the following example:
SELECT * FROM SPFLI
? %_HINTS ORACLE 'INDEX("SPFLI" "SPFLI~001")'
.......
ENDSELECT.
In the above example, 001 is the secondary index of the table SPFLI. It's a well-known fact that the efficient way of retrieving data from the database tables is by using secondary indexes. Many database vendors provide the optimizer hints for the same. From SAP v4.5, optimizer hints can be provided by the %_HINTS parameter. This is dependent on the database systems that support optimizer hints. The point to be noted here is these optimizer hints are not standardized by the SQL standards. Each database vendor is free to provide the optimizer hints.


Now to know which index to use for our table:
1. Go to SE11 and there specify the table name
2. Now from the menu, goto --> indexes
3. select the required index.
Now suppose that the identifier 001 represents a non-unique secondary index comprising of the columns CITYFROM and CITYTO. The index name should be defined as: ?~like SPFLI~001 in the above example.The sequence of fields in the WHERE condition is of no relevance in using this optimizers index. If you specify hints incorrectly, ABAP ignores them but doesn't return a syntax error or runtime error.The code was written in R/3 4.6C.
Consider the following example:?
REPORT Suresh_test.
TABLES: spfli.
DATA : t_spfli LIKE spfli OCCURS 0 WITH HEADER LINE.
SELECT * FROM spfli
?INTO TABLE t_spfli
? ? ?%_HINTS ORACLE 'INDEX("SPFLI" "SPFLI~001")'.
?
?LOOP AT t_spfli.
? ? ? WRITE :/ t_spfli.
ENDLOOP.
?
③ABAP--如何在SELECT語句中指定索引(example)
report z_generic_test_program .
tables: csks. start-of-selection. ?
select * up to 10 rows
? ? ?from csks ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? where kokrs <> space
? ? ? ? ? ?and kostl <> space ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? %_hints oracle 'index(csks"csks~J")'. ?
? ? ? ? ? write: / csks.
endselect.?
④Control over FOR ALL ENTRIES Hints Under the heading Database Interface Hints, Note 129385 describes the options you have for influencing the database interface by entering hints. The hints are evaluated in the database interface itself and are not passed on to the database. Starting with kernel Release 4.6B all the above mentioned FOR ALL ENTRIES parameters can be set via such a hint for a single statement. In the example: ?
SELECT *
? ? FROM [..]
? ? FOR ALL ENTRIES IN [..]
? ? WHERE [..] ?
? ? %_HINTS ORACLE '&prefer_in_itab_opt 1&&prefer_fix_blocking -1&'.
This way, the boolean parameter 'prefer_in_itab_opt' is explictly set and the boolean parameter 'prefer_fix_blocking' is set to its default value. FOR ALL ENTRIES hints, like hints are generally only used as a a corrective device in emergency situations.

總結(jié)

以上是生活随笔為你收集整理的【力荐】Select查询语句中LIKE关键词的优化方法分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。