为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。
【DM版本】:V8
【操作系统】:linux,麒麟V10(128核 256G)
【CPU】: Hygon AMD x86_64
【问题描述】*:远程连接数据库查询2毫秒,但是在DBeaver中查询需要14s,在JAVA程序中也要查询14s,初步怀疑是驱动的问题,把DBeaver驱动换成最新的DmJdbcDriver8.jar还是无法解决程序查询慢的问题
查询语句如下,并且使用过EXPLAIN查看过开销在数据库相对小的,也对相应的字段做了索引,JAVA程序本身依旧查询慢
select id, component_id, screenshot, config, version , is_lasted, tenant_id, status, create_user, create_dept , create_time, update_user, update_time, is_deleted from visual_component_version where is_deleted = 0 and (component_id in (1428646434743275521, 1430426216663527426, 1430713493148573697, 1430848124430753793, 1432190921455902722, 1432992141764190210, 1433032186190819329, 1433073902637740034, 1433271181127102466, 1433282458838806530, 1433334767378472962, 1433352937216647170, 1433413818544082945, 1433735459413344258, 1434069094927302657, 1434097647084560385, 1438788078691590145, 1440863896334934017, 1441228936779046913, 1442034839202340865, 1442325924265144322, 1442332080480006146, 1442385284471271425, 1442696798680698881, 1447760710251298818, 1448496268559052802, 1448612035820580865, 1448940853687676930, 1449989205149806593, 1451458062126739457, 1452475358433570817, 1452540953149632514, 1452564041430003713, 1452883814068056066, 1452911458398564354, 1453266387383742465, 1453266656863580162, 1453279789318733825, 1453656717208911874, 1453659445234565122, 1453911700749852674, 1453998892640411650, 1455360372661366785, 1455817069878804481, 1456472150848770050, 1460467762418475009, 1460474031095209986, 1460503062071009282, 1460506283116126210, 1460511230230585345, 1460516271108710402, 1463802821710004226, 1465268433153478658, 1466256210453704705, 1468150797049339906, 1473839214337126401, 1473906192494030849, 1474201430982848514, 1475289948446453762, 1476488241321291777, 1476715096762691585, 1478630539468320770, 1478983834554920961, 1479294191808655362, 1480823513146372098, 1481198265907249153, 1481458106668122113, 1481812315598471170, 1483731766124941314, 1484059469405278209, 1484408054422278146, 1485443018945175553, 1485452712355012610, 1485500621679206401, 1485503769391112194, 1485504740640923649, 1485505434898898946, 1485508165910896641, 1485521617727496194, 1485523314818392065, 1485523464685068289, 1485524293848637442, 1485524615933435905, 1485524845831626754, 1485527746167676930, 1485546459302436866, 1485861684722536450, 1485865110957199361, 1485868237450121217, 1485871831989620738, 1485887324884570113, 1486255528135831554, 1486550993297420290, 1486582741439819778, 1486586429910757378, 1486618334260178945, 1486621700826673154, 1486638260060499969, 1491240578991075329, 1493144253258698753, 1493178962069331969, 1493894173464637442, 1494495963041435650, 1494553287252348929, 1495648862085545985, 1496015489155170306, 1497055908795166721, 1497534148043382786, 1507296840148123650, 1514507457210957826, 1538408783393144833, 1552927759286079489, 1559017764582379522, 1562275491057618945, 1564133809830924289, 1569624114375692290, 1572159344337723394, 1572435287706935297, 1572761393962131457, 1580807636864331778, 1591005020924641282, 1594589621468307457, 1596073521385275393, 1598244799306522626, 1606203288258019330, 1608286725373865986, 1613446093131927554, 1613722896559824897, 1623984106380648449, 1626121893277200385, 1627230853371654145, 1628573012729520129, 1628733388733538306, 1638348529049014273, 1638392605622407169, 1641614369149259778, 1647788690230054914) and is_deleted = 0);
https://eco.dameng.com/document/dm/zh-cn/faq/faq-optimizing
可以把sql缓存的执行计划dump出来,对比和explain的执行计划是否有区别
请参考:
BLKUP2+SSEK2
的操作执行计划,如果传入的值刚好数据分布比重很大自然就慢(计划不合理,但是缓存计划的时候传入了分布比例很低的值);SVR_LOG
获取程序绑定的变量类型,如果程序绑定的类型错误,可能会导致实际执行计划非预期(通常会走全扫描),例如数据库里的筛选列是INT类型,但程序里绑定了float类型直接导致不能走索引检索(案例可参考绑定类型错误导致的性能问题);建议更换jar包试试,客户之前也反馈这个问题,更换jar后正常。
1、检查驱动包是否和数据库版本一致,建议替换下对应版本驱动程序。
2、检查内存中执行计划,执行SQL替换下
查询示例:
select * from v$cachepln where sqlstr like '%t.bxdid is not null%';
3、导出执行计划到文本
alter session set events 'immediate trace name plndump level 139897600695728,dump_file ''/opt/dmsetup/sql_plan.log''';
对比下执行计划,计划跑偏可尝试清理下计划缓存解决问题
方法:
清理sql缓存计划:
SELECT * FROM v$cachepln where SQLSTR LIKE '%语句%’;
SP_CLEAR_PLAN_CACHE(CACHE_ITEM);
感觉可以排查下网络或者抓包看看是哪一个环节损耗时间