索引和统计信息问题咨询

[11小透明]

【测试环境】
【 OB 4.2.1.6】

CREATE TABLE test02 (
id bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT ‘自增主键’,
uuid varchar(64) DEFAULT NULL,
os tinyint(4) DEFAULT NULL COMMENT ‘os’,
create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘创建时间’,
update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘更新时间’,
PRIMARY KEY (id),
KEY I_oaid (uuid) BLOCK_SIZE 16384 LOCAL,
KEY I_create_time (create_time) BLOCK_SIZE 16384 LOCAL,
KEY I_update_time (update_time) BLOCK_SIZE 16384 LOCAL
) AUTO_INCREMENT = 3436046 AUTO_INCREMENT_MODE = ‘ORDER’ DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = ‘zstd_1.3.8’ REPLICA_NUM = 3 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0
partition by hash(id) PARTITIONS 30;

SELECT * from test02 where did=‘xxx’ order by update_time desc;【执行2ms】
SELECT uuid from test02 where did=‘xxx’ order by update_time desc;【执行8.5s】

发现了时快时慢的例子，分析执行计划得知是有时扫了全表，手动收集下统计信息才能正常。
想问下这个是为什么，之后线上不能时不时的手动收集一下统计信息吧

[Royce1220]

能提供一下快慢时候的explain extended执行计划吗？

[道阻且長]

1，先试着找下真实原因。分析下执行计划的差异。另外测试数据和生产数据的分布规律是一样的吗？一般来说尽量真实的数据统计信息才行。
2，先看能否找到真实原因，没有办法了，可以写hint优化器提示，或者绑定执行计划

Optimizer Hint-OceanBase 数据库-OceanBase文档中心-分布式数据库使用文档

计划绑定-OceanBase 数据库-OceanBase文档中心-分布式数据库使用文档

[Royce1220]

表里面的数据是什么时候插入的，现在数据变更量大吗，按理说不需要经常收集统计信息的。

[11小透明]

手动统计信息前(这个也不是稳定每次都是慢,时快时慢，复现的几次有发现读全表的执行计划)


手动统计信息后：

[liuxzh]

一般是数据量有较大的变化时，都是要手动执行统计信息收集。
尤其是加载数据后，应立刻进行组户级合并最好。

[11小透明]

如果这个表是需要实时导入的呢。那这样会不会有不稳定风险。

[liuxzh]

有的，准实时的导入累积起来会加大转储，通过转储触发合并这种方式不一定适用实际场景，
我的建议是定时手动设置任务执行租户级合并。
这样影响最小。

[Royce1220]

这种是buffer表的场景，如果表一直在实时导入，是有可能导致这种不稳定的情况发生，一个是因为查询的链路变长了，第二个是因为优化器获取到的统计信息和实际表中的数据不匹配，4.x没有buffer表的概念了，可以看下自适应合并参数_enable_adaptive_compaction的值，另外个人理解table full scan算子不一定代表是全表扫描，像这个例子中，应该是对i_update_time的全扫描。

[liuxzh]

3X版本会有一个处理机制：
当执行计划连续发生性能衰减时，会自动刷新新的执行计划。—> 这里会出现有SQL执行计划变慢，过一会儿恢复 的情况。
3X版本触发转储只能缓解这个场景的性能问题。
OB3X 版本不支持租户级别合并，4X版本支持，这个功能时不错的，可以控制租户级别的合并。
obclient> ALTER SYSTEM MAJOR FREEZE;
4X中对本租户执行这个就可以

[淇铭]

1.使用sql_audit诊断
2.针对这个语句查看一下gv$ob_sql_audit视图
3.具体分析手动前和手动后gv$ob_sql_audit视图信息的变化，分析具体消耗在哪一步。

[兹拉坦]

简单分析和总结了一下这个问题，详见这篇博客：《分析一个收集统计信息之前，计划不稳定的问题》