【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】 5.7.25-OceanBase-v3.2.4.5 VS 5.7.25-OceanBase-v4.2.1.6
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):
【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手 ] 即可召唤小助手,欢迎试用!
参数:lower_case_table_names = 0
查询SQL:
select * from information_schema.TABLES
select * from INFORMATION_SCHEMA.TABLES
版本:5.7.25-OceanBase-v4.2.1.6 系统表不区分大小写,都能查询
版本:5.7.25-OceanBase-v3.2.4.5 系统表区分大小写, INFORMATION_SCHEMA.TABLES不能查询
有这个说明么?还是其他啥问题呢
论坛小助手
2026 年8 月 25 日 16:02
#3
您的问题是关于在不同版本的OceanBase中,设置lower_case_table_names = 0参数后系统表查询行为的变化。这个问题涉及到OceanBase对MySQL兼容性的调整,以及不同版本之间可能存在的差异。遗憾的是,obdiag工具主要用于解决性能、稳定性等问题,并不太适合直接用来解决这种配置或兼容性相关的问题。但为了进一步了解问题细节并提供帮助,您可以按照以下步骤操作:
收集更多信息
首先,建议您收集更多关于当前环境的信息,尽管这不完全符合obdiag日志采集场景的应用范围,但基础信息的收集仍然有助于诊断问题。
日志采集场景 : 集群基础信息
日志采集命令 : obdiag gather scene run --scene=observer.base
这个命令将帮助我们获取集群的基础配置等信息,虽然它可能不会直接指出问题的原因,但是可以为我们提供一个更好的上下文来理解您的集群是如何配置的。
提供更多信息
请您提供更多关于该问题的背景信息,以便我们更好地进行分析:
当您尝试使用INFORMATION_SCHEMA.TABLES查询时,具体的错误信息是什么?请尽量给出完整的错误提示。
您提到的两个OceanBase版本(v3.2.4.5与v4.2.1.6)之间的具体迁移过程是怎样的?是否有遇到过任何异常?
在这两个版本之间,是否还有其他配置项发生了变化?例如:字符集设置、存储引擎的选择等。
您能否分享一下您所使用的具体SQL语句样本,特别是那些导致了不同行为的查询?
通过这些问题的回答,我们可以更准确地定位到问题的关键点,并尝试提出解决方案或建议进一步的动作。希望这些信息能够帮助我们尽快解决您的困扰。
附上敏捷诊断工具 obdiag 使用帮助链接
淇铭
2026 年8 月 25 日 16:03
#4
看着是企业版的问题 建议找企业的技术支持
你好,你提的这个技术问题牵涉到OceanBase企业版范围内的功能细节;针对此类问题,建议你通过以下方式寻求帮助:
如你所在的企业客户已签署OceanBase企业版销售合同,请你联系客户经理;
如你所在的企业客户尚未签署OceanBase企业版销售合同,你可通过OceanBase官网商务咨询 页面留下你的联系方式,OceanBase企业版的业务顾问会在一个工作日内与你联系。
另外,我们欢迎你使用社区版,并在论坛/社群中分享你对社区版本的想法、经验和问题,与其他社区成员共同交流。
SQL Error [1146] [42S02]: Table ‘INFORMATION_SCHEMA.TABLES’ doesn’t exist
[10.101.23.12:2882] [2026-08-25 15:50:16.719760] [YB420A65170C-000608D343DBB65B-0-0]