select 1 from Information_schema.columns limit 0,1 语句执行45秒

zhenxing · 2025 年4 月 17 日 10:46

合并后还是一样的慢

-- 确认手工触发合并已经完成
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)

zhenxing · 2025 年4 月 17 日 10:47

官方容器里面的系统时区没调整

更新：手工调整了容器时区，重启容器后问题还是存在

Giant · 2025 年4 月 17 日 11:07

合并不可能这么快吧。

感觉是访问这个表触发了所有的表或者视图的来检查列。

zhenxing · 2025 年4 月 17 日 13:55

我这个是一个空库，合并速度我理解是正常范围内

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)

淇铭 · 2025 年4 月 17 日 14:55

建议时区调整好重新做合并看着show trace发过来的数据是有问题看着是语句执行打开关闭陷入循环了或者不用容器环境自己单机搭建一个看看是否还有问题

Giant · 2025 年4 月 17 日 15:40

我还有个疑问：这个trace日志里面有大量的这个操作，如果 3000多行的话，有可能把所有的表或者视图检查了一遍schema 。会有这样控制的参数不？？

我记的 mysql 社区版有的操作，会自动触发检测 ddl 的。

不知道咱们的ob是否有这样的机制。

淇铭 · 2025 年4 月 17 日 16:03

自动触发检测我记得mysql是information_schema是一个“in-memory”的数据库他应该是log里读取数据并且创建表的和隔离级别有关系可以使用ANALYZE TABLE 表名; 这样手动刷新吧

AntTech_HEZ4XU · 2025 年4 月 17 日 16:24

为什么求回答

远航 · 2025 年4 月 17 日 17:09

没看懂你发的内容

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

淇铭 · 2025 年4 月 17 日 17:12

按照步骤来那是个举例哎你的语句哪个有问题可以按照案例的步骤来

淇铭 · 2025 年4 月 17 日 17:14

淇铭:

直连的时候查询慢么？
1、show trace; --使用这个命令链路跟踪看看消耗在哪里
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000639971
2、通过查看gv$ob_sql_audit审计视图确认影响执行耗时的等待事件。
3、再获取 SQL 执行计划EXPLAIN EXTENDED
4、获取 sql plan monitor 信息，全过程可以参看如下操作。
1.登录sys租户设置 sql_plan_monitor 参数

确认 sql_plan_monitor 已经打开

show parameters like ‘enable_sql_audit’;

如果 enable_sql_audit = False 则将其打开

alter system enable_sql_audit = true;

登录业务租户，获取 sql 的执行计划
EXPLAIN EXTENDED sql语句;

设置临时 trace 获取
SET ob_enable_show_trace=‘ON’;

再次执行需要采集的 sql 语句

获取上一步执行的 sql 的 trace_id 信息
select last_trace_id();

临时关闭 plan monitor 数据，防止信息被覆盖
alter system enable_sql_audit = false;

获取 plan monitor 的 sql ，将 xxxxx 替换为第 6 步返回的 trace_id ，以获取每个算子的吐行信息
select plan_line_id, plan_operation, sum(output_rows), sum(STARTS) rescan, min(first_refresh_time) open_time, max(last_refresh_time) close_time, min(first_change_time) first_row_time, max(last_change_time) last_row_eof_time, count(1) from oceanbase.gv$sql_plan_monitor where trace_id = ‘xxxxx’ group by plan_line_id, plan_operation order by plan_line_id;

8 恢复 sql_audit 参数
alter system enable_sql_audit = true;

按照上面的步骤信息提供一下

AntTech_PMFZEE · 2025 年4 月 17 日 17:30

我好奇试了下，发现我也有这个问题，用普通租户执行的。但是，和你的又不一样。我只有第一次执行会很慢，20s+，后面再怎么执行都很快了。

select 1 from Information_schema.columns limit 0,1

os : ubuntu 24.04
ce : 4.3.5.1

enable_sql_audit = true

远航 · 2025 年4 月 17 日 17: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查不到数据

淇铭 · 2025 年4 月 17 日 17:38

查询的信息保存在文本里可以都收集一下么？按照步骤

要在同一个会话下执行

zhenxing · 2025 年4 月 17 日 18:04

重新搭建了一个单节点OBServer，复现还是相同情况，下面是复现的步骤和trace日志

YB427F000001-000632F610B331C6-0-0.log (2.0 MB)
复现完整记录.txt (33.8 KB)

淇铭 · 2025 年4 月 17 日 18:40

建议你重新开个帖子方便跟踪

淇铭 · 2025 年4 月 18 日 10:23

内部没有复现出来你的环境方便远程看看么？

jiaxin666 · 2025 年4 月 22 日 16:54

我们也遇到了4.3这问题，4.2版本就正常能走table_schema,table_name索引

oceanbase mysql租户表数量超过20000张时查询information_schema.columns视图很慢，执行计划走了全表扫描 - 社区问答- OceanBase社区-分布式数据库

jiaxin666 · 2025 年4 月 22 日 16:59

淇铭 · 2025 年4 月 23 日 10:34

该问题和研发那边确认了，符合当前的预期，是已知问题，后期会优化。如果要在ob4351版本上走到pk，可以在创建租户的时候将 lower_case_table_names 变量设置为1，但是这个变量在租户创建好后就不能修改了。ob425bp1上查询应该没有问题
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002016015