项目使用SSM,oracle 11g,linux服务器,生产环境与测试环境代码相同,数据库不同,相关细节配置可能不同。
业务需要根据关键字查询系统中人员的相关信息,用户输入一个关键字,能够模糊查询一张视图中4个字段的数据。
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
查询语句如上,应该并不复杂,USER数据量15000左右,ORG数据量1000左右。通过plsql直接查库,耗时0.5s左右。项目上线运行初期,这个查询响应正常。几天后上线另一个页面,同样使用了这个查询接口(代码逻辑基本一致,调用Service中同一个方法,指向map中同一个sql,只有拼接语句时的一个if判断条件不同,最终呈现的查询语句是相同的),响应耗时正常。但前一个页面在执行这个查询时出现了问题,后台抛出如下异常:
登录数据库服务器排查,发现500多G的临时表空间使用达到100%,只剩余十几M。加大临时表空间后,不再报错,但是这个查询变得异常耗时。
但项目中其他查询都还能正常执行,好像没有出现同样的状况,包括前面提到的使用同一个查询方法的页面。
在测试环境和生产环境上对出现问题的查询打印代码执行的耗时,如下图:
测试环境:
正式环境:
生产环境与测试环境代码相同,数据库不同,相关细节配置可能不同。现在没有头绪是哪里出了问题……求助>_<!
这几个字段都很小, 如果查询条件相对固定的话,可以把这几个字自段连一块,形成一个字个段, 或物化视图,并对此字段建索引. 然后只需查一个字段即可.
还有就是userid!=xxx, 最好改成(userid>xxx and userid<xxx), 也许我的经验过时了, 但至少值得一试.