快捷導(dǎo)航

SQL使用復(fù)合索引實(shí)現(xiàn)數(shù)據(jù)庫(kù)查詢的優(yōu)化

更新時(shí)間：2022年05月25日 09:55:03 作者：??千云????

這篇文章主要介紹了SQL使用復(fù)合索引實(shí)現(xiàn)數(shù)據(jù)庫(kù)查詢的優(yōu)化,文章圍繞主題展開詳細(xì)的內(nèi)容介紹，具有一定的參考價(jià)值，需要的小伙伴可以參考一下

一問題

程序再在一次查詢時(shí)出現(xiàn)查詢時(shí)間過長(zhǎng)，每次查詢要1-2分鐘業(yè)務(wù)反饋用戶操作體驗(yàn)很差，sql如下:

select *
FROM edi_booking edibooking0_
WHERE 1 = 1
        AND edibooking0_.load_port_code IN ('CNCWN', 'CNDCB', 'AA', 'CNMWN'
        , 'CWHSD', 'CNSHK', 'CNYTN', 'CNSKU')
        AND edibooking0_.carrier_code = 'WHL'
        AND upper(edibooking0_.so_no) LIKE upper('025%')
        AND edibooking0_.load_port_code = 'CNSHK'
        AND edibooking0_.status <= 1
        AND edibooking0_.tfc_code = 'E19957'
ORDER BY edibooking0_.so_no ASC;

需要對(duì)查詢進(jìn)行優(yōu)化。

二分析

還是老樣子，先看看執(zhí)行計(jì)劃，看看走沒走索引，不查不知道一查嚇一跳，執(zhí)行計(jì)劃上居然顯示走了索引，索引是函數(shù)索引upper(so_no) ，走了索引為什么還慢呢，根據(jù)以往的經(jīng)驗(yàn)，走了索引不是應(yīng)該很快才對(duì)嗎？奇奇怪怪，于是注意到了查詢條件中還有一個(gè)條件tfc_code，又發(fā)現(xiàn)這個(gè)字段其實(shí)也有建立索引，是不是數(shù)據(jù)庫(kù)的執(zhí)行計(jì)劃有問題，沒有走tfc_code索引呢？或者說tfc_code索引本身有問題，于是進(jìn)行重建tfc_code索引。

alter index EDI_BOOKING_IDX_TFC_CODE rebuild online;

執(zhí)行后，哇塞，查詢速度果然上來了，2s鐘返回查詢結(jié)果。查看執(zhí)行計(jì)劃，走了tfc_code索引，nice！但是故事還沒有結(jié)束！過了一天后，業(yè)務(wù)又反饋查詢慢了，查看執(zhí)行計(jì)劃，走的索引又變成了upper(so_no)。讓人頭禿。

那還個(gè)方向思考，既然走了索引，為什么還會(huì)慢?。?！原來走了索引并不一定就會(huì)快，這是一個(gè)大大的誤區(qū)。

upper(edibooking0_.so_no) LIKE upper('025%')這個(gè)過濾條件走了索引，但是索引的類型是range_scan,這種類型查詢返回的數(shù)據(jù)量會(huì)比較大，這就是這次走索引還慢的問題所在，因?yàn)樽吡怂饕蠓祷亓?code>150w條數(shù)據(jù)，而150w條數(shù)據(jù)被后去的條件過濾，這樣導(dǎo)致了查詢速度慢的問題。

而引發(fā)這個(gè)問題，一個(gè)是upper(so_no)索引返回?cái)?shù)據(jù)量大，另外一個(gè)就是oracle的執(zhí)行計(jì)劃沒有選擇最優(yōu)的索引，如果選擇tfc_code索引，那么查詢也會(huì)很快。

三解決方案

指定數(shù)據(jù)庫(kù)選擇索引：

由于執(zhí)行計(jì)劃是數(shù)據(jù)庫(kù)自動(dòng)生成的，我們無法改變執(zhí)行計(jì)劃，但是我們可以通過指定索引的方式，讓數(shù)據(jù)庫(kù)去執(zhí)行我們指定的索引，如：

select /*+index(edibooking0_ IDX_EDI_BOOKING_SO_TFC_CT)*/*
FROM edi_booking edibooking0_

但是這種有一個(gè)弊端，要對(duì)每一個(gè)執(zhí)行的語(yǔ)句都要進(jìn)行指定索引，修改量比較大。

建立復(fù)合索引：

CREATE INDEX IDX_EDI_BOOKING_SO_TFC_CT
ON edi_booking (UPPER("SO_NO"), "TFC_CODE","CONTRACT_NO");

復(fù)合索引很容易給人一種雞肋的感覺，因?yàn)樗麑?duì)應(yīng)的查詢條件一定是他最左邊的索引字段被查詢才能生效，但是其實(shí)他是非常有用的，比如我們現(xiàn)在的場(chǎng)景，進(jìn)行復(fù)核索引過濾時(shí)就會(huì)產(chǎn)生非常大的性能提升,最終通過建立組合索引解決問題

到此這篇關(guān)于SQL使用復(fù)合索引實(shí)現(xiàn)數(shù)據(jù)庫(kù)查詢的優(yōu)化的文章就介紹到這了,更多相關(guān)SQL查詢優(yōu)化內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: