今天遇到一個生產(chǎn)問題，業(yè)務(wù)SQL很簡單，單表查詢，而且表只有三個字段，有個主鍵ID，而且通過主鍵ID過濾，業(yè)務(wù)頁面會傳一百多個ID過來調(diào)用SQL，這個表數(shù)據(jù)量大小為100多萬，但是偏偏這條SQL執(zhí)行跑了15秒，完全影響業(yè)務(wù)不能使用。

成都創(chuàng)新互聯(lián)服務(wù)項目包括廬山網(wǎng)站建設(shè)、廬山網(wǎng)站制作、廬山網(wǎng)頁制作以及廬山網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，廬山網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到廬山省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

select a,b,c from t where t.id in (1111,222,333,444,555..........)

我一開始并沒有去查看表設(shè)計，而是直接看了執(zhí)行計劃,

1 alter session set statistics_level=all;
2 執(zhí)行SQL
3 select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')

執(zhí)行計劃直接走了全表掃描，而在謂詞過濾的信息里有一堆的

to_number(t.id)=1111 or to_number(t.id)=2222 ..............

看到這里立馬就猜想到了具體的問題所在，查詢T表ID字段，是VARCHAR2類型，而SQL in的是數(shù)字類型，SQL直接被隱式轉(zhuǎn)換后，便走不了索引了， 直接走了全表。這個問題后續(xù)才發(fā)現(xiàn)，也是因為業(yè)務(wù)不關(guān)注，在表數(shù)據(jù)日益上漲之后，性能問題日益凸顯才被拋出來