工作中遇到一個(gè)SQL查詢慢的問(wèn)題
查詢語(yǔ)句是：
SELECT * FROM db_msg.t_xxpt_xx_cocall xx WHERE dt_fssj >=‘2020-06-03 00:00:00’ AND dt_fssj <= ‘2020-06-10 23:59:59’ order by dt_fssj desc limit 20;
篩選字段為30w左右數(shù)據(jù)，返回結(jié)果集20，首次執(zhí)行時(shí)會(huì)執(zhí)行有7，8秒的時(shí)間

為了優(yōu)化這個(gè)SQL我首先查看這個(gè)SQL執(zhí)行計(jì)劃：
1 #NSET2: [6696, 20, 764]
2 #PRJT2: [6696, 20, 764]; exp_num(26), is_atom(FALSE)
3 #SORT3: [6696, 20, 764]; key_num(1), is_distinct(FALSE), top_flag(1), is_adaptive(0)
4 #BLKUP2: [418, 198120, 764]; I_XXPT_XX_COCALL_FSSJ(XX)
5 #SSEK2: [418, 198120, 764]; scan_type(ASC), I_XXPT_XX_COCALL_FSSJ(T_XXPT_XX_COCALL as XX), scan_range[exp_cast(‘2020-06-03 00:00:00’),exp_cast(‘2020-06-10 23:59:59’)]

執(zhí)行計(jì)劃時(shí)首先走SEEK2二級(jí)索引數(shù)據(jù)定位，同時(shí)篩選字段數(shù)據(jù)，然后走BLKUP2(定位查找)

然后我這邊打開(kāi)MONITOR_SQL_EXEC參數(shù)，然后執(zhí)行這個(gè)語(yǔ)句，使用ET來(lái)查看這個(gè)執(zhí)行計(jì)劃每個(gè)步驟的消耗，發(fā)現(xiàn)執(zhí)行計(jì)劃BLKUP2這一步會(huì)消耗百分之98以上時(shí)間。

主要是因?yàn)楫?dāng)前語(yǔ)句為select * 要返回所有列的信息，而二級(jí)索引只記錄rowid和索引列信息，所以執(zhí)行計(jì)劃需要定位查找其他列數(shù)據(jù)，消耗大量資源

所以后續(xù)優(yōu)化中去掉了此列上的普通二級(jí)索引，新建了一個(gè)聚集索引，聚集索引上包含所有列的值，走CSEK2查找篩選后就能獲得所有列的值，不會(huì)再走BLKUP2(定位查找)這個(gè)過(guò)程，從而減少資源開(kāi)銷(xiāo)

添加聚集索引：
CREATE CLUSTER INDEX I_XXPT_XX_COCALL_FSSJ ON db_msg.t_xxpt_xx_cocall (DT_FSSJ DESC);

然后查看新的執(zhí)行計(jì)劃：
1 #NSET2: [0, 20, 764]
2 #PRJT2: [0, 20, 764]; exp_num(26), is_atom(FALSE)
3 #TOPN2: [0, 20, 764]; top_num(20)
4 #CSEK2: [0, 100, 764]; scan_type(ASC), I_XXPT_XX_COCALL_FSSJ(T_XXPT_XX_COCALL as XX), scan_range[exp_cast(‘2020-07-10 23:59:59’),exp_cast(‘2020-07-03 00:00:00’)]

新計(jì)劃下執(zhí)行時(shí)間基本不到1S，SQL優(yōu)化成功

總結(jié)

以上是生活随笔為你收集整理的DM 一次SQL优化经历的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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