有关OceanBase HATP方面的性能的几点疑惑？

[AntTech_DVCBDO]

我们的业务场景下有一个日最大流水400w行的日志表，目前运行在CK上，总记录数大概在5亿左右，由于对中国厂商自研数据库的使用要求，我们正在考虑切换一个hatp的数据库。我前段时间通过白屏部署了一个三节点的oceanbanse，单节点规格8C 16G 一开始采用的最小模式。然后我进行了如下的DDL建表：

CREATE TABLE IF NOT EXISTS `sys_oper_log` (
  `oper_id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '日志主键',
  `title` varchar(50) DEFAULT '' COMMENT '模块标题',
  `business_type` int(2) DEFAULT '0' COMMENT '业务类型（0其它 1新增 2修改 3删除）',
  `method` varchar(100) DEFAULT '' COMMENT '方法名称',
  `request_method` varchar(10) DEFAULT '' COMMENT '请求方式',
  `operator_type` int(1) DEFAULT '0' COMMENT '操作类别（0其它 1后台用户 2手机端用户）',
  `oper_name` varchar(50) DEFAULT '' COMMENT '操作人员',
  `dept_name` varchar(50) DEFAULT '' COMMENT '部门名称',
  `oper_url` varchar(255) DEFAULT '' COMMENT '请求URL',
  `oper_ip` varchar(50) DEFAULT '' COMMENT '主机地址',
  `oper_location` varchar(255) DEFAULT '' COMMENT '操作地点',
  `oper_param` varchar(2000) DEFAULT '' COMMENT '请求参数',
  `json_result` varchar(2000) DEFAULT '' COMMENT '返回参数',
  `status` int(1) DEFAULT '0' COMMENT '操作状态（0正常 1异常）',
  `error_msg` varchar(2000) DEFAULT '' COMMENT '错误消息',
  `oper_time` datetime DEFAULT NULL COMMENT '操作时间',
  PRIMARY KEY (`oper_id`)
) partition by key(oper_id) partitions 9 ;

通过Navicat随机插入了约600w的测试数据，然后执行count计数

SELECT count(1) FROM sys_oper_log;

结果并不是那么让人满意，我同样尝试过不设置分区或者调整并行度，或者放开租户的资源限制

ALTER TABLE sys_oper_log PARALLEL 8;

但是最好的结果600w的计数仍然需要3-4秒以上的时间。而同样的数据在CK中我可以得到一个毫秒级的响应，因此我不确定是否是我的步骤哪里出现了问题。希望得到解答。

补充：距离我上次批量的数据模拟插入（600w数据10分钟批量插入，每次插入1000）过去了约20分钟，现在我执行计数可以得到一个毫秒级的响应了，在这过程中我三台机器的内存开销都比较高，似乎是后台正在执行合并的任务。我不知道自己的判断是否正确。如果是，那么有没有更多有关这个合并任务的描述，我想要知道如何能够查询到他何时开始，何时结束。

[云深月隐]

单纯的全表扫描查询，应该还是ck的性能好，ob的优点应该在于oltp和olap都能做，性能应该比单纯的oltp和olap的数据库稍微差点。

[云深月隐]

合并的方式及触发都有几种，以及怎么查看在下面这个文档里
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000508470

[obpilot]

1. oper_id 是自增的，根据这个分区不是很贴合业务。日志表（流水表）建议根据时间 (oper_time） 做 RANGE 分区。如果数据量很大，再根据 oper_id 做二级hash 分区。 方便将来删除历史记录。

2. 导入了大量数据期间，租户内存大概率发生了转储。数据全部初始化后，建议对租户发起一个 合并（`alter system major freeze tenant=‘xxx’

3. 大查询 加上 HINT /*+ query_timeout(1000000000000) parallel(表名 16) */ 用并行可以提升查询性能，具体并行度看租户 CPU 。

4. 可以再发一下 集群和租户的资源。

select zone,concat(SVR_IP,':',SVR_PORT) observer,
	cpu_capacity_max cpu_total,cpu_assigned_max cpu_assigned,
	cpu_capacity-cpu_assigned_max as cpu_free,
	round(memory_limit/1024/1024/1024,2) as memory_total,
	round((mem_capacity-mem_assigned)/1024/1024/1024,2) as memory_free
from gv$ob_servers;

select t1.name resource_pool_name, t2.`name` unit_config_name, 
	t2.max_cpu, t2.min_cpu, 
	round(t2.memory_size/1024/1024/1024,2) mem_size_gb,
	round(t2.log_disk_size/1024/1024/1024,2) log_disk_size_gb, t2.max_iops, 
	t2.min_iops, t3.unit_id, t3.zone, concat(t3.svr_ip,':',t3.`svr_port`) observer,
	t4.tenant_id, t4.tenant_name
from __all_resource_pool t1
	join __all_unit_config t2 on (t1.unit_config_id=t2.unit_config_id)
	join __all_unit t3 on (t1.`resource_pool_id` = t3.`resource_pool_id`)
	left join __all_tenant t4 on (t1.tenant_id=t4.tenant_id)
order by t1.`resource_pool_id`, t2.`unit_config_id`, t3.unit_id;

[AntTech_DVCBDO]

[obpilot]

将剩余 的 CPU 资源全部分给这个测试的租户。

以及合并结束后，sql 里加 并行 hint 后再跑跑看。

[AntTech_DVCBDO]

第一个1.3秒是第一次任务合并完成后的执行时间，后续同样的sql重复执行，速度就突然变快了。这是因为缓存机制的影响嘛？然后我过了大概两小时后执行sql。

得到一个中间的值。这个0.48我也比较好奇。

[秃蛙]

第一次慢是要生成这个表相关的执行计划会有些耗时。后续查询会走计划查询会快起来。

0.048的浮动有可能是执行计划的汰换。