項(xiàng)目使用SSM，oracle 11g，linux服務(wù)器，生產(chǎn)環(huán)境與測(cè)試環(huán)境代碼相同，數(shù)據(jù)庫不同，相關(guān)細(xì)節(jié)配置可能不同。

業(yè)務(wù)需要根據(jù)關(guān)鍵字查詢系統(tǒng)中人員的相關(guān)信息，用戶輸入一個(gè)關(guān)鍵字，能夠模糊查詢一張視圖中4個(gè)字段的數(shù)據(jù)。

SELECT

A .userId,

A .account,

A .name,

A .mobile,

A .code,

A .phone,

A .email,

A .sort

FROM

USER A

INNER JOIN USER_ORG b ON A .userId = b.userId

INNER JOIN ORG c ON b.orgId = c.orgId

WHERE

(a.name LIKE '%18888888888%' OR a.mobile LIKE '%18888888888%' OR a.phone LIKE '%18888888888%' OR a.email LIKE '%18888888888%')

AND A .userId != 100000000000000

AND c.isAvalible = 1

ORDER BY

A .sort ASC

查詢語句如上，應(yīng)該并不復(fù)雜，USER數(shù)據(jù)量15000左右，ORG數(shù)據(jù)量1000左右。通過plsql直接查庫，耗時(shí)0.5s左右。項(xiàng)目上線運(yùn)行初期，這個(gè)查詢響應(yīng)正常。幾天后上線另一個(gè)頁面，同樣使用了這個(gè)查詢接口(代碼邏輯基本一致，調(diào)用Service中同一個(gè)方法，指向map中同一個(gè)sql，只有拼接語句時(shí)的一個(gè)if判斷條件不同，最終呈現(xiàn)的查詢語句是相同的)，響應(yīng)耗時(shí)正常。但前一個(gè)頁面在執(zhí)行這個(gè)查詢時(shí)出現(xiàn)了問題，后臺(tái)拋出如下異常：

登錄數(shù)據(jù)庫服務(wù)器排查，發(fā)現(xiàn)500多G的臨時(shí)表空間使用達(dá)到100%，只剩余十幾M。加大臨時(shí)表空間后，不再報(bào)錯(cuò)，但是這個(gè)查詢變得異常耗時(shí)。

但項(xiàng)目中其他查詢都還能正常執(zhí)行，好像沒有出現(xiàn)同樣的狀況，包括前面提到的使用同一個(gè)查詢方法的頁面。

在測(cè)試環(huán)境和生產(chǎn)環(huán)境上對(duì)出現(xiàn)問題的查詢打印代碼執(zhí)行的耗時(shí)，如下圖：

測(cè)試環(huán)境：

正式環(huán)境：

生產(chǎn)環(huán)境與測(cè)試環(huán)境代碼相同，數(shù)據(jù)庫不同，相關(guān)細(xì)節(jié)配置可能不同。現(xiàn)在沒有頭緒是哪里出了問題……求助>_

總結(jié)

以上是生活随笔為你收集整理的java web 耗时请求_javaweb应用中出现了一个耗时异常长的数据查询，寻求帮助的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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