- 博客(31)
- 收藏
- 关注
RSS订阅原创 SQL优化 | 3.X vs 4.X：OceanBase 手动收集统计信息（六）
针对分区表收集统计信息时，可以增加收集的粒度和选择分区的方式来进行更精准的统计信息收集。如果需要显示收集某个表的统计信息，当前主流提供了两种方式来进行统计信息收集，分别是通过。下的对象进行统计信息收集。这在批量处理多个相关表的统计信息时非常有用。在 MySQL 模式下，如果不想显式写出全部字段，可以通过。是 Oracle 模式下的语法，因此需要先启用。系统变量以支持 Oracle 模式的扩展语法。除了对单个表进行统计信息收集，还可以对整个。子句来收集表中所有列的统计信息。租户模式，不推荐使用。
2025-05-08 10:10:07
1029
原创 OceanBase 是如何关闭主备线程的？
验证一下，当 【主备集群 clog 同步断开时间】 > 【clog 的保留时间】，再次开启主备集群间的 clog 同步，新数据是否丢失？那么，OceanBase 主备集群与 MySQL 主备库，在关闭主备线程，删除主备相关信息上有哪些区别呢？：当开启主备集群 clog 同步，会自动检测数据一致性，如发现数据不一致，会自动拉取基线数据进行同步。两者的命令是否相同？9. 当 clog 同步断开，主节点日志过期，重新打开日志同步：备集群不会丢数据。clog 正常同步时，备集群查询数据（连接串需要添加 -c）。
2025-04-30 10:00:00
839
原创 实战案例 | SQL 中驱动表与 Hash 关联的场景抉择 (十四)
在LEADING提示所定义的连接顺序里，最外层括号中处于最左边的表就是驱动表。
2025-04-28 10:06:29
1625
原创 实战案例 | 你的慢SQL，驱动表选对了吗？（十三）
分析一条耗时1分钟的SQL执行计划，发现表b作为驱动表存在性能问题。通过检查关联表的数据量和关联字段，发现f表关联字段索引缺失，同时调整驱动表和连接方式可优化性能。优化后SQL耗时缩短至17秒，性能显著提升，证明优化措施有效。
2025-04-27 09:46:36
1075
原创 实战案例 | 从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
原创 实战案例 | 执行计划缓存导致SQL耗时过慢问题（十一）
我们知道，SQL查询并不需要每次生成查询计划，因为这样涉及到硬解析等耗费性能的操作，所以默认每次会先查询。，检查慢SQL实际命中的plan（业务租户和sys租户下都可以查询到数据）。（硬解析操作包含词法/语法/语义解析，优化器统计信息查询等步骤，参考下图）。通过下面执行计划和执行耗时可知，第一次执行的语句因为字段。索引，range太大基本为全索引扫描，所以耗时太慢。这个首次传入是个空字符串没有数据，ob估行是1。租户内执行，清除当前租户中所有。本案例中，后续的SQL命中该。sys租户下执行，不同粒度。
2025-04-23 17:02:10
1161
原创 实战案例 | 笛卡尔积导致的慢 SQL 优化实战解析（十）
T1表和T2表关联字段的离散度不高（产生局部笛卡尔积），导致连接时产生大量数据。可考虑优化SQL语句来提高查询性能。当连接没有on条件时，会出现笛卡尔积(全部笛卡尔积);当连接on条件是非唯一字段（字段区分度不高）时，会出现笛卡尔积(局部笛卡尔积)；当连接on条件是唯一字段时，则不会出现笛卡尔积；
2025-04-22 09:13:08
821
原创 实战案例 | 范围查询、隐式转换与 `or` 索引失效（九）
用于驱动表达式中的子查询，OceanBase会以算法来执行算子，即循环遍历左边的记录集，然后去右边结果集中取数据。所以，子查询是否能命中索引，对性能影响很大。关联字段不是主键且未加索引。关联字段隐式转化。范围查询未走索引。常见索引失效场景（or。
2025-04-21 09:31:39
884
原创 SQL优化 | OceanBase执行计划解读(八)
全表扫描每秒可以扫 200万行数据，回表每秒扫 20 万行数据，相差 10 倍。想获取更多实用干货，关注微信公众号【雅俗数据库】。：对于后续案例分析，判断驱动表有很大帮助。
2025-04-20 10:46:42
941
原创 SQL优化 | Hint：概述、特点与使用（七）
Hint是SQL语句注释，可向OceanBase数据库优化器传达指令，使优化器生成指定执行计划。通常优化器会为查询选择最佳执行计划，但在某些场景下其生成的计划无法满足需求，此时用户可使用Hint指定特定执行计划。Hint应谨慎使用，建议在收集表统计信息、用EXPLAIN评估无Hint时优化器执行计划后再考虑使用。因为数据库条件变化和版本更新可能使Hint的适用性发生改变。
2025-04-19 11:06:34
813
原创 带宽被 OBServer 备份 “榨干”，集群陷入 “无主” 危机
经排查发现，NFS盘的交换机端口负载带宽理论峰值为1.25GB/S，在备份时间点，带宽已被打满。综上所述:可以判断是因为每日备份导致网络带宽打满，从而引起时钟同步异常，进而导致原主的租约过期，最终出现无主情况。这表明easy工作线程是共享的，由于备份网络处理繁忙，导致其他rpc的处理也受到了影响。可通过增加网络带宽的方式，缓解备份时的网络压力，避免因带宽不足导致的各种问题。建议将其配置为1，这样备份时间会拉长，但修改为1后，集群无主的问题得到了改善。bond0为业务网卡，bond1为备份网卡。
2025-04-18 09:29:11
1735
原创 行锁 | MySQL行记录上锁 SQL问题排查
表名作用查看当前数据库中正在执行的 SQL 语句和会话状态信息存储 InnoDB 存储引擎中未提交事务的详细信息，如事务 ID、事务状态、事务开始时间、锁定的表数量和行数量等记录等待锁的事务信息，包括等待开始时间、被锁定的表名、等待锁的事务 ID、持有锁的事务 ID 以及用于终止持有锁连接的 SQL 语句记录当前正在执行的 SQL 语句的相关信息存储线程执行的 SQL 语句历史记录包含线程的相关信息，可用于关联和THREAD_ID。
2025-04-17 09:13:30
978
原创 SQL优化 | 如何创建 Outline 并验证 Outline 生效（五）
此时我们发现一个问题：结果中有两条 SQL（对应两个 sql_id），区别是一个有分号，一个没分号。想获取更多实用干货，关注微信公众号【雅俗数据库】。创建OUTLINE前需要先进入相应的数据库。在ODC中执行的SQL无论加不加分号，在。应用程序发起的SQL请求，以及。中指定数据库名称，或者在执行。客户端执行的SQL，在。答案：没有分号的那个。
2025-04-16 15:03:01
860
原创 SQL优化 | OcenaBase慢查询基础信息采集（一）
如果在业务租户下查询，业务租户是Oracle模式，SQL语法不兼容，所以建议在。后应跟上具体的SQL语句，文档中未完整给出，实际使用时需补充完整。文档中此部分内容缺失具体SQL示例，需根据实际情况补充。想获取更多实用干货，关注微信公众号【雅俗数据库】。OceanBase缓存执行计划的两个视图是(作用：检查是否存在隐式转化，字段NDV值等。注意：若报SQL格式错误，去掉注释即可。
2025-04-08 17:18:41
546
原创 SQL优化 | 精准区分 trace_id、sql_id、plan_id（二）
在SQL优化过程中，经常遇到trace_id，sql_id，plan_id 这三个字段，笔者总是傻傻的分不清他们的区别；下面我将着重介绍这三个ID值的区别，以及他们分别如何获取？
2025-03-26 09:28:58
1496
原创 OB运维 | 分区操作（重分布）
技术交流，联系作者：hwc007007。备注：优快云社区交流。待测点：如果是range分区,减少分区数量,会不会丢数据；答案：OceanBase 4.0之后支持。答案：OceanBase 4.0之后支持。
2025-03-18 11:56:38
1248
原创 解锁binlog | 精准定位 binlog 文件中最大事务的大小（一）
在MySQL运维过程中，大事务（即涉及大量数据更新的事务）不受欢迎，因其往往会引发诸多维护难题。在MySQL维护工作中，我们需要重点留意是否存在大事务，并从binlog中寻找相关迹象。下面将介绍如何确定大事务的大小。
2025-03-10 12:03:25
846
原创 高可用 | Orchestrator故障切换（七）
自动切换受到以下条件限制和约束：主库是downtime的集群不进行故障切换。如果希望忽略集群故障，可以设置downtime。处于故障活跃期的集群不进行故障切换（即只对配置项匹配的集群进行故障切换。：在Orchestrator的配置文件中，可能会有类似如下的配置来设置这里的和就是与相关的配置项，分别表示在处理主节点集群故障和中间主节点故障时的活动时间周期，单位为秒。
2025-03-08 19:59:12
446
原创 高可用 | Orchestrator手工切换（六）
不论集群主库是否故障，都会进行后续切换操作，需要用户确认已发生故障。，是因为老主库不是故障的，首先会让候选主库追上老主库。最后，将老主库作为新主库的从库（但没有执行。指定的故障主库必须是故障的，也就是已确认发生故障，如果不是故障的，不进行切换。这种切换方式针对的是：老主库是正常的，需要提升新主库，老主库可作为从库。不人为指定新主库host和端口，让orchestrator自己选新主库，老主库。：从库提升为主库，并且候选主库必须是集群主库的直连从库。不会将老主库作为新主库的从库，老主库成为孤立的实例。
2025-03-07 16:22:50
799
原创 高可用 | Orchestrator故障检测/故障场景（五）
笔者目前在hook脚本中，只对DeadMaster和DeadMasterAndSomeReplicas两种故障场景做了切换，其余故障场景，不会发生高可用切换。生产环境，需要根据实际业务需要，定义自己所需切换的故障场景。想获取更多实用干货，关注微信公众号【雅俗数据库】。
2025-03-04 16:46:16
468
原创 高可用 | Orchestrator+VIP部署hook脚本(四)
Orchestrator默认仅提供MySQL主从复制的扩展管理。在发生故障转移时，会重新组织扩展，选出新主库并指定其他从库连接到它。但Orch自身不会进行任何DNS更改或VIP漂移。切换后，应用程序可能连接到错误的数据库。那么是否可以按照MHA+VIP类似的方式，来使用Orchestrator呢？建议开启无损半同步（rpl_semi_sync_master_wait_point=AFTER_SYNC）。
2025-03-03 18:09:13
801
原创 高可用 | Orchestrator接管MySQL主从（三）
参数定义了从库从主库获取数据等待的超时时间，超过这个时间从库会主动断开连接并尝试重新获取。被Orch纳管的MySQL实例，需要启用GTID,主从同步使用。打印拓扑实例的 ASCII 树 通过以下方式传递集群名称。想获取更多实用干货，关注微信公众号【雅俗数据库】。输入ip(hostname)和port。过长会导致切换延迟过久，所以需要调整。检查主库和从库之间的IO链路。显示当前已知的集群（显示主节点）温馨提示：推荐使用界面方式来接管。
2025-03-02 13:18:37
485
原创 高可用 | Orchestrator集群安装部署（二）
部署一个一主两从的orchestrator集群，当主节点宕机时，会在从节点中选举出新的主节点，保证orchestrator集群的高可用性，并继续为检测MySQL集群服务。注意：使用两种方式切换启动,先确保Orch进程未启动。想获取更多实用干货，关注微信公众号【雅俗数据库】。注意检查是否配置如下参数，若未配置，请手工配置。登录网页 11.186.63.78:3000。数据库安装部署省略，可自行安装。11.186.63.78节点。所有节点都启动 Orch。三节点，分别建软连接。Orch集群健康检查。
2025-03-02 12:33:27
832
原创 高可用 | Orchestrator架构介绍（一）
由 go 编写的 MySQL 高可用性和复制拓扑管理工具，支持复制拓扑结构的调整、自动故障转移和手动主从切换等。后端数据库使用 MySQL 或 SQLite 存储元数据，并提供 Web 界面展示 MySQL 复制的拓扑关系及状态。通过 Web 可更改 MySQL 实例的复制关系和部分配置信息，同时也提供命令行和 api 接口，便于运维管理。
2025-03-02 12:28:18
2176
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人