GreenPlum 索引问题

问题描述

项目中使用GP数据库做实时同步，对于这种高并发大数据量的dml操作，效率非常低，于是，考虑到索引优化。有时候，已经建了索引，但是看查询计划，并没有使用到索引；

案例

对于odb_ywuser_prpcmain这张表，policyno为分布键。在列 policyno 建了一个名叫 idx_db_ods_odb_ywuser_prpcmain 的索引，在列 policyno,inserttime 上将建了一个名叫 idx_db_ods_odb_ywuser_prpcmain2 的索引；

create index idx_db_ods_odb_ywuser_prpcmain on odb_ywuser_prpcmain (policyno);
create index idx_db_ods_odb_ywuser_prpcmain2 on odb_ywuser_prpcmain (policyno,inserttime);

然后查看基于where条件 policyno 字段做update的执行计划，可以看出并没有走索引；

explain UPDATE db_ods.odb_ywuser_prpcmain SET POLICYNO='6211230282641667969',APPLICODE='30250791',OP_TIME='2021-10-13 23:59:57' WHERE POLICYNO='6211230282641667969';

再查看基于where条件 policyno,inserttime 字段做update的执行计划，可以看出是走了索引的；

explain UPDATE db_ods.odb_ywuser_prpcmain SET INSERTTIME='2021-10-12 00:00:08',POLICYNO='G210308283006500003' WHERE INSERTTIME='2021-10-12 00:00:04' AND POLICYNO='G210308283006500003';

问题思考

那么问题来了，为什么第一条没有走索引呢？
GP中查询是否走索引，是比较cost值的，绝大部分场景优化器的cost值的判断是准的，所以，优化器判断走索引消耗比顺序扫描更慢，就不会走索引，优化器判断并不是百分百正确，实际执行效果走索引确实比顺序扫描快的话，可以在会话级别（或者用户级别）设置顺序扫描参数关闭，再执行sql；

--会话级别  每次会话都要设置
set enable_seqscan to off;
--用户级别  只要设置一次
alter role db_ods set enable_seqscan =off;
--执行sql  走索引速度确实快了
explain UPDATE db_ods.odb_ywuser_prpcmain SET POLICYNO='6211230282641667969',APPLICODE='30250791',OP_TIME='2021-10-13 23:59:57' WHERE POLICYNO='6211230282641667969';
UPDATE db_ods.odb_ywuser_prpcmain SET POLICYNO='6211230282641667969',APPLICODE='30250791',OP_TIME='2021-10-13 23:59:57' WHERE POLICYNO='6211230282641667969';

总结

GP可以应用于OLAP和OLTP场景。对于OLAP，不管数据量有多大，GP都不建议建索引。对于OLTP性能瓶颈的情况下，可以考虑索引。并不一定有索引就一定快，建索引得基于where查询条件，并且表足够大，如果在小表中建索引，又强制执行计划去走索引，那么，顺序扫描足够快，中间还要去扫描索引，只会是画蛇添足；如果测试索引确实比顺序扫描快的话，可以强制走索引，毕竟优化器只是理论计算出来的cost值；对于oracle可以在sql语句中使用 hint 方式去强制使用索引，对于GP则可以设置会话级别的参数或用户级别的参数（不建议设置全局参数，绝大多数基于场景的优化器都是准确的）。