为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。
【DM版本】:8
【操作系统】:
【CPU】:
【问题描述】*:
分页语句1,加俩查询条件之后,2和3
1.
SELECT * FROM AM_LIST_DATA
WHERE LIST_ID= '8a845097c3944251856959734a5a4a8b'
order by create_time desc limit 0, 10;
2.
SELECT * FROM AM_LIST_DATA
WHERE LIST_ID= '8a845097c3944251856959734a5a4a8b'
AND check_result='PASS'
order by create_time desc limit 0, 10;
3.
SELECT * FROM AM_LIST_DATA
WHERE LIST_ID= '8a845097c3944251856959734a5a4a8b'
AND check_result='PASS'
data_source='CDKPT'
order by create_time desc limit 0, 10;
1能使用我的联合索引 union_index(list_id,create_time)
2和3就用不上了union_index,只能用(list_id,check_result,data_source)索引,查询巨慢,如果我强制给使用union_index索引,查询巨快。
我为啥要建一个list_id,check_result,data_source的联合索引,是因为我还有一个查询count()的语句,
select count() from am_list_data
WHERE list_id = '8a845097c3944251856959734a5a4a8b'
AND check_result='PASS' and
data_source='CDKPT',不建这个索引不快,建了这个索引巨快,但是我这check_result,和data_source是枚举值。
真的搞不懂为什么,求大神指教
可以尝试更新一下统计信息,有可能是统计信息不准确造成的。
方法可以参考:https://eco.dameng.com/community/article/e568e956bc7d579722b221a691f46678
索引应设计为(LIST_ID ASC, CREATE_TIME DESC)
,这样3个查询请求正常都应该走这个索引。
如果没有,注意分页查询优化有一个相关参数 TOP_ORDER_OPT_FLAG
,explain确认下开启这个参数优化后3个SQL的执行计划是否都走了union_index
-- 1.
explain SELECT /*+top_order_opt_flag(1)*/ * FROM AM_LIST_DATA
WHERE LIST_ID= '8a845097c3944251856959734a5a4a8b'
order by create_time desc limit 0, 10;
-- 2.
explain SELECT /*+top_order_opt_flag(1)*/ * FROM AM_LIST_DATA
WHERE LIST_ID= '8a845097c3944251856959734a5a4a8b'
AND check_result='PASS'
order by create_time desc limit 0, 10;
-- 3.
explain SELECT /*+top_order_opt_flag(1)*/ * FROM AM_LIST_DATA
WHERE LIST_ID= '8a845097c3944251856959734a5a4a8b'
AND check_result='PASS'
data_source='CDKPT'
order by create_time desc limit 0, 10;
如果以上显示都走了预期索引,可以把以上/*+top_order_opt_flag(1)*/
带入SQL;
SQL2/3走(list_id,check_result,data_source)索引慢是因为有排序代价;
另外建议应用SQL参数化,不要LIST_ID='xxx',而是LIST_ID=?
等,如果已是参数化而以上案例已参数值取代则忽略。
还有确认下LIST_ID列统计信息,dbms_stats.column_stats_show(USER,'AM_LIST_DATA','LIST_ID');
命令查看,stat 100 on AM_LIST_DATA(LIST_ID)
命令收集
强制走索引吧。
可参考一下说明:
https://eco.dameng.com/document/dm/zh-cn/pm/manage-index.html#10.4%20%E5%A6%82%E4%BD%95%E5%9C%A8%20SQL%20%E8%AF%AD%E5%8F%A5%E4%B8%AD%E4%BD%BF%E7%94%A8%E7%B4%A2%E5%BC%95