合并后还是一样的慢
-- 确认手工触发合并已经完成
mysql> SELECT * FROM DBA_OB_MAJOR_COMPACTION\G
*************************** 1. row ***************************
FROZEN_SCN: 1744857736108305000
FROZEN_TIME: 2025-04-17 02:42:16.108305
GLOBAL_BROADCAST_SCN: 1744857736108305000
LAST_SCN: 1744857736108305000
LAST_FINISH_TIME: 2025-04-17 02:45:09.215856
START_TIME: 2025-04-17 02:42:16.339471
STATUS: IDLE
IS_ERROR: NO
IS_SUSPENDED: NO
INFO:
1 row in set (0.01 sec)
mysql> select 1 from information_schema.columns limit 1;
+---+
| 1 |
+---+
| 1 |
+---+
1 row in set (8.41 sec)
Giant
#24
合并不可能这么快吧。
感觉是访问这个 表 触发了所有的 表或者视图的 来检查列。
我这个是一个空库,合并速度我理解是正常范围内
mysql> SELECT * FROM DBA_OB_MAJOR_COMPACTION\G
*************************** 1. row ***************************
FROZEN_SCN: 1744867350732239000
FROZEN_TIME: 2025-04-17 05:22:30.732239
GLOBAL_BROADCAST_SCN: 1744867350732239000
LAST_SCN: 1744857736108305000
LAST_FINISH_TIME: 2025-04-17 02:45:09.215856
START_TIME: 2025-04-17 05:22:30.956514
STATUS: COMPACTING
IS_ERROR: NO
IS_SUSPENDED: NO
INFO:
1 row in set (0.01 sec)
mysql> SELECT * FROM DBA_OB_MAJOR_COMPACTION\G
*************************** 1. row ***************************
FROZEN_SCN: 1744867350732239000
FROZEN_TIME: 2025-04-17 05:22:30.732239
GLOBAL_BROADCAST_SCN: 1744867350732239000
LAST_SCN: 1744867350732239000
LAST_FINISH_TIME: 2025-04-17 05:26:54.107276
START_TIME: 2025-04-17 05:22:30.956514
STATUS: IDLE
IS_ERROR: NO
IS_SUSPENDED: NO
INFO:
1 row in set (0.01 sec)
淇铭
#26
建议时区调整好 重新做合并 看着show trace发过来的数据 是有问题 看着是语句执行打开关闭 陷入循环了 或者不用容器环境 自己单机搭建一个 看看是否还有问题
Giant
#27
我还有个疑问 : 这个trace日志里面 有大量的这个操作 ,如果 3000多行的话 ,有可能 把所有的表或者视图 检查了一遍schema 。 会有 这样控制的参数不 ??
我记的 mysql 社区版有的操作,会自动触发 检测 ddl 的。
不知道咱们的ob是否有这样的机制。
淇铭
#28
自动触发检测 我记得mysql是information_schema是一个“in-memory”的数据库 他应该是log里读取数据并且创建表的和隔离级别有关系 可以使用ANALYZE TABLE 表名; 这样手动刷新吧
远航
#30
没看懂你发的内容
select count() from test2;
这个语法都过不去呀。
how create table __all_virtual_information_columns的查询结果:
CREATE TABLE `__ALL_VIRTUAL_INFORMATION_COLUMNS` (
`TABLE_SCHEMA` varchar(128) NOT NULL,
`TABLE_NAME` varchar(256) NOT NULL,
`TABLE_CATALOG` varchar(4096) NOT NULL DEFAULT '',
`COLUMN_NAME` varchar(128) NOT NULL DEFAULT '',
`ORDINAL_POSITION` bigint(20) unsigned NOT NULL DEFAULT '0',
`COLUMN_DEFAULT` longtext DEFAULT NULL,
`IS_NULLABLE` varchar(4) NOT NULL DEFAULT '',
`DATA_TYPE` longtext NOT NULL DEFAULT '',
`CHARACTER_MAXIMUM_LENGTH` bigint(20) unsigned DEFAULT NULL,
`CHARACTER_OCTET_LENGTH` bigint(20) unsigned DEFAULT NULL,
`NUMERIC_PRECISION` bigint(20) unsigned DEFAULT NULL,
`NUMERIC_SCALE` bigint(20) unsigned DEFAULT NULL,
`DATETIME_PRECISION` bigint(20) unsigned DEFAULT NULL,
`CHARACTER_SET_NAME` varchar(128) DEFAULT NULL,
`COLLATION_NAME` varchar(128) DEFAULT NULL,
`COLUMN_TYPE` longtext NOT NULL,
`COLUMN_KEY` varchar(3) NOT NULL DEFAULT '',
`EXTRA` varchar(4096) NOT NULL DEFAULT '',
`PRIVILEGES` varchar(200) NOT NULL DEFAULT '',
`COLUMN_COMMENT` longtext NOT NULL DEFAULT '',
`GENERATION_EXPRESSION` longtext NOT NULL DEFAULT '',
PRIMARY KEY (`TABLE_SCHEMA`, `TABLE_NAME`)
) DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = 'none' REPLICA_NUM = 1 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 10
淇铭
#31
按照步骤来 那是个举例 哎 你的语句哪个有问题 可以按照案例的步骤来
我好奇试了下,发现我也有这个问题,用普通租户执行的。但是,和你的又不一样。我只有第一次执行会很慢,20s+,后面再怎么执行都很快了。
select 1 from Information_schema.columns limit 0,1
os : ubuntu 24.04
ce : 4.3.5.1
enable_sql_audit = true
远航
#34
select * from GV$OB_PLAN_CACHE_PLAN_EXPLAIN的结果:
[root@x.x.x.x ~]$ grep “YB420BA1CC68-000615A0A8EA6511-0-0” rootservice.log
[root@x.x.x.x ~]$ grep “YB420BA1CC68-000615A0A8EA6511-0-0” observer.log
换成我自己的TRACE_ID查不到数据
淇铭
#35
查询的信息 保存在文本里 可以都收集一下么?按照步骤
要在同一个会话下执行
重新搭建了一个单节点OBServer,复现还是相同情况,下面是复现的步骤和trace日志
YB427F000001-000632F610B331C6-0-0.log (2.0 MB)
复现完整记录.txt (33.8 KB)
淇铭
#41
该问题和研发那边确认了,符合当前的预期,是已知问题,后期会优化。如果要在ob4351版本上走到pk,可以在创建租户的时候将 lower_case_table_names 变量设置为1,但是这个变量在租户创建好后就不能修改了。ob425bp1上查询应该没有问题
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002016015
1 个赞