雅俗数据库
分享MySQL与OceanBase相关技术博文
【公众号 | 雅俗数据库】
展开
专栏收录文章
- 默认排序
- 最新发布
- 最早发布
- 最多阅读
- 最少阅读
-
SQL优化 | OcenaBase慢查询基础信息采集(一)
如果在业务租户下查询,业务租户是Oracle模式,SQL语法不兼容,所以建议在。后应跟上具体的SQL语句,文档中未完整给出,实际使用时需补充完整。文档中此部分内容缺失具体SQL示例,需根据实际情况补充。想获取更多实用干货,关注微信公众号【雅俗数据库】。OceanBase缓存执行计划的两个视图是(作用:检查是否存在隐式转化,字段NDV值等。注意:若报SQL格式错误,去掉注释即可。原创 2025-04-08 17:18:41 · 546 阅读 · 0 评论 -
SQL优化 | 精准区分 trace_id、sql_id、plan_id(二)
在SQL优化过程中,经常遇到trace_id,sql_id,plan_id 这三个字段,笔者总是傻傻的分不清他们的区别;下面我将着重介绍这三个ID值的区别,以及他们分别如何获取?原创 2025-03-26 09:28:58 · 1497 阅读 · 0 评论 -
SQL优化 | OceanBase是否遵循最左匹配原则?(三)
在MySQL数据库中,如果不满足最左匹配原则,索引会失效。原创 2025-03-27 10:00:00 · 1131 阅读 · 0 评论 -
SQL 优化 | 同类型 SQL 缘何冒出多个 sql_id(四)
定义不同的字符串格式,会导致sql_id不同。原创 2025-03-29 10:41:24 · 773 阅读 · 0 评论 -
SQL优化 | 如何创建 Outline 并验证 Outline 生效(五)
此时我们发现一个问题:结果中有两条 SQL(对应两个 sql_id),区别是一个有分号,一个没分号。想获取更多实用干货,关注微信公众号【雅俗数据库】。创建OUTLINE前需要先进入相应的数据库。在ODC中执行的SQL无论加不加分号,在。应用程序发起的SQL请求,以及。中指定数据库名称,或者在执行。客户端执行的SQL,在。答案:没有分号的那个。原创 2025-04-16 15:03:01 · 860 阅读 · 0 评论 -
SQL优化 | 3.X vs 4.X:OceanBase 手动收集统计信息(六)
针对分区表收集统计信息时,可以增加收集的粒度和选择分区的方式来进行更精准的统计信息收集。如果需要显示收集某个表的统计信息,当前主流提供了两种方式来进行统计信息收集,分别是通过。下的对象进行统计信息收集。这在批量处理多个相关表的统计信息时非常有用。在 MySQL 模式下,如果不想显式写出全部字段,可以通过。是 Oracle 模式下的语法,因此需要先启用。系统变量以支持 Oracle 模式的扩展语法。除了对单个表进行统计信息收集,还可以对整个。子句来收集表中所有列的统计信息。租户模式,不推荐使用。原创 2025-05-08 10:10:07 · 1029 阅读 · 0 评论 -
SQL优化 | Hint:概述、特点与使用(七)
Hint是SQL语句注释,可向OceanBase数据库优化器传达指令,使优化器生成指定执行计划。通常优化器会为查询选择最佳执行计划,但在某些场景下其生成的计划无法满足需求,此时用户可使用Hint指定特定执行计划。Hint应谨慎使用,建议在收集表统计信息、用EXPLAIN评估无Hint时优化器执行计划后再考虑使用。因为数据库条件变化和版本更新可能使Hint的适用性发生改变。原创 2025-04-19 11:06:34 · 813 阅读 · 0 评论 -
SQL优化 | OceanBase执行计划解读(八)
全表扫描每秒可以扫 200万行数据,回表每秒扫 20 万行数据,相差 10 倍。想获取更多实用干货,关注微信公众号【雅俗数据库】。:对于后续案例分析,判断驱动表有很大帮助。原创 2025-04-20 10:46:42 · 942 阅读 · 0 评论 -
实战案例 | 范围查询、隐式转换与 `or` 索引失效(九)
用于驱动表达式中的子查询,OceanBase会以算法来执行算子,即循环遍历左边的记录集,然后去右边结果集中取数据。所以,子查询是否能命中索引,对性能影响很大。关联字段不是主键且未加索引。关联字段隐式转化。范围查询未走索引。常见索引失效场景(or。原创 2025-04-21 09:31:39 · 885 阅读 · 0 评论 -
实战案例 | 笛卡尔积导致的慢 SQL 优化实战解析(十)
T1表和T2表关联字段的离散度不高(产生局部笛卡尔积),导致连接时产生大量数据。可考虑优化SQL语句来提高查询性能。当连接没有on条件时,会出现笛卡尔积(全部笛卡尔积);当连接on条件是非唯一字段(字段区分度不高)时,会出现笛卡尔积(局部笛卡尔积);当连接on条件是唯一字段时,则不会出现笛卡尔积;原创 2025-04-22 09:13:08 · 822 阅读 · 0 评论 -
实战案例 | 执行计划缓存导致SQL耗时过慢问题(十一)
我们知道,SQL查询并不需要每次生成查询计划,因为这样涉及到硬解析等耗费性能的操作,所以默认每次会先查询。,检查慢SQL实际命中的plan(业务租户和sys租户下都可以查询到数据)。(硬解析操作包含词法/语法/语义解析,优化器统计信息查询等步骤,参考下图)。通过下面执行计划和执行耗时可知,第一次执行的语句因为字段。索引,range太大基本为全索引扫描,所以耗时太慢。这个首次传入是个空字符串没有数据,ob估行是1。租户内执行,清除当前租户中所有。本案例中,后续的SQL命中该。sys租户下执行,不同粒度。原创 2025-04-23 17:02:10 · 1161 阅读 · 0 评论 -
实战案例 | 从MySQL到OB:SELECT查询ORDER BY异常排序(十二)
推荐] 避免使用非唯一列进行 order by 排序参考官方文档:(SQL 规范如果 order by 后是一个非唯一字段,MySQL 的返回结果会按照主键二次排序,但 OceanBase 数据库无此行为。代码中禁止使用非唯一列进行 order by 排序,该行为会在 OceanBase 数据库中产生非稳定的返回结果从而影响业务。OceanBase 数据库切主后,SQL 在不同执行计划的 server 上执行返回结果存在差异。order by 后的列存在多行相同的值,每次执行会返回不同的结果。原创 2025-04-25 09:45:16 · 697 阅读 · 0 评论 -
实战案例 | 你的慢SQL,驱动表选对了吗?(十三)
分析一条耗时1分钟的SQL执行计划,发现表b作为驱动表存在性能问题。通过检查关联表的数据量和关联字段,发现f表关联字段索引缺失,同时调整驱动表和连接方式可优化性能。优化后SQL耗时缩短至17秒,性能显著提升,证明优化措施有效。原创 2025-04-27 09:46:36 · 1075 阅读 · 0 评论 -
实战案例 | SQL 中驱动表与 Hash 关联的场景抉择 (十四)
在LEADING提示所定义的连接顺序里,最外层括号中处于最左边的表就是驱动表。原创 2025-04-28 10:06:29 · 1625 阅读 · 0 评论 -
实战案例 | 从执行画像入手诊断 SQL 性能瓶颈(十五)
row_dt(算子吐出首行所需时间)结合执行计划中的:找到消耗较大的表。原创 2025-04-29 09:30:00 · 588 阅读 · 0 评论
分享