技术干货 | 如何将大表在线改造为分区表并释放空间

Oracle-大表改造分区表实施步骤 对于业务交易繁忙的数据库,在运行了一定时间后往往会产生一些数据量较大的表,特别是对于每天新增数据较多的日志表或者流水表,单表数据量通常会达到几十G,甚至是上百G。大表对于日常的运维非常的不方便,特别是在表数据的清理、迁移,查询性能会随着数据量的增大而受到影响,因此,通常对于大表我们需要进行优化拆分,在Oracle数据库,比较常见的大表优化拆分是将大表改造为分区表,这种方式最主要的好处就是对于应用透明,应用层面的改动很少 阅读详情

技术干货 | 如何将大表在线改造为分区表并释放空间

出现麻烦

你是否遇到过如此令人麻烦的问题,比如:由于前期规划不当,后期库表数据量猛增;或者由于“年久失修”而造成的表数据积累不断。等等诸如此类 大表 问题。

面对这些大表,是删也不能删,清理又困难。

即使你不嫌麻烦,一点一点的通过 delete 清理了数据,但是还会有令人头疼的 表碎片 问题。

面对 表ibd 文件的只增不减,也许想到了可以通过这些方法解决:

  • ALTER TABLE xxx engine=innodb;
  • OPTIMIZE TABLE xxx;

这两种方法虽然在清理表数据后可以释放空间,但是会造成锁表问题。

如何优雅在线的清理数据并释放空间呢?

清理数据方法有很多,比如 [delete] [truncate] [删除分区] 等,其实最简单有效的方法就是 删除分区 。

有人会问:当初数据库中没有设计为分区表,谁也没想到这个表现在数据量这么大,这该怎么办?

再也不用抱怨你接手了一个烂摊子,也不用频繁接收表文件过大造成的文件系统告警了…

我们"在线"把大表改造成分区表不就好了!

这将优雅的实现:

  • 在线 ——> 不影响业务
  • 分区 ——> 便于管理
  • 空间 ——> 删除分区直接释放

闪亮登场

实现我们的大目标,那就需要借助专业的小工具。他就是

percona-toolkit 之 pt-online-schema-change

概要

在线修改表结构,特点是修改过程中不会造成读写阻塞。

原理

工作原理是创建要更改的表的空副本,根据需要对其进行修改,然后将原始表中的行复制到新表中。复制完成后,它会移走原始表并用新表替换。默认情况下,它还会删除原始表。

用法

pt-online-schema-change [OPTIONS] DSN

选项

详见:https://greatsql.cn/docs/8.0.32-27/6-oper-guide/10-5-pt-development.html#pt-online-schema-change

最佳实践

1. 测试表

CREATE TABLE `t1` (
  `id` int NOT NULL AUTO_INCREMENT,
  `data_value` varchar(255) DEFAULT NULL,
  `expired_date` int unsigned NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1;

2. 测试数据

表中存在数据 10000000

greatsql> SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
| 10000000 |
+----------+
1 row in set (3.03 sec)

3. 查看表文件大小

t1.ibd 文件大小有 468M

-rw-r----- 1 mysql mysql 468M May  5 06:07 t1.ibd

4. 修改主键

如果使用分区表,分区键需要包含在主键中,使用 pt-online-schema-change 可以 online 修改主键。

首先,使用 --dry-run 进行执行前测试

pt-online-schema-change h=192.168.105.101,P=3306,u=root,p=root,D=test,t=t1 --alter "DROP PRIMARY KEY,ADD PRIMARY KEY (id, expired_date)" --recursion-method=none --no-check-replication-filters --no-check-unique-key-change --alter-foreign-keys-method auto --print --dry-run

执行结果:

Operation, tries, wait:
......
2025-05-05T06:59:52 Dropping new table...
DROP TABLE IF EXISTS `test`.`_t1_new`;
2025-05-05T06:59:52 Dropped new table OK.
Dry run complete.  `test`.`t1` was not altered.

然后,使用 --execute 执行

pt-online-schema-change h=192.168.105.101,P=3306,u=root,p=root,D=test,t=t1 --alter "DROP PRIMARY KEY,ADD PRIMARY KEY (id, expired_date)" --no-check-alter --recursion-method=none --no-check-replication-filters --no-check-unique-key-change --alter-foreign-keys-method auto --print --execute

执行结果:

Operation, tries, wait:
......
Copying `test`.`t1`:  49% 00:30 remain
Copying `test`.`t1`:  96% 00:02 remain
2025-05-05T07:06:55 Copied rows OK.
2025-05-05T07:06:55 Analyzing new table...
2025-05-05T07:06:55 Swapping tables...
RENAME TABLE `test`.`t1` TO `test`.`_t1_old`, `test`.`_t1_new` TO `test`.`t1`
2025-05-05T07:06:55 Swapped original and new tables OK.
2025-05-05T07:06:55 Dropping old table...
DROP TABLE IF EXISTS `test`.`_t1_old`
2025-05-05T07:06:55 Dropped old table `test`.`_t1_old` OK.
2025-05-05T07:06:55 Dropping triggers...
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_t1_del`
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_t1_upd`
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_t1_ins`
2025-05-05T07:06:55 Dropped triggers OK.
Successfully altered `test`.`t1`.

查看表结构

greatsql> SHOW CREATE TABLE t1\G;
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `id` int NOT NULL AUTO_INCREMENT,
  `data_value` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL,
  `expired_date` int unsigned NOT NULL,
  PRIMARY KEY (`id`,`expired_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
1 row in set (0.00 sec)

此时可以看到,表 t1 的主键已经修改为 (id,expired_date) 了。

5. 调整为分区表

使用 pt-online-schema-change 可以 online 调整为分区表。

首先,使用 --dry-run 进行执行前测试

pt-online-schema-change h=192.168.105.101,P=3306,u=root,p=root,D=test,t=t1 \
--alter "
  PARTITION BY RANGE (expired_date) (
    PARTITION p202501 VALUES LESS THAN (1738339200),  -- 2025-02-01 00:00:00
    PARTITION p202502 VALUES LESS THAN (1740758400),  -- 2025-03-01 00:00:00
    PARTITION p202503 VALUES LESS THAN (1743436800),  -- 2025-04-01 00:00:00
    PARTITION p202504 VALUES LESS THAN (1746028800),  -- 2025-05-01 00:00:00
    PARTITION p202505 VALUES LESS THAN (1748707200),  -- 2025-06-01 00:00:00
    PARTITION p_max VALUES LESS THAN MAXVALUE
  )" \
--recursion-method=none --no-check-replication-filters --no-check-unique-key-change --alter-foreign-keys-method auto --print --dry-run

执行结果:

Operation, tries, wait:
......
2025-05-05T07:18:17 Dropping new table...
DROP TABLE IF EXISTS `test`.`_t1_new`;
2025-05-05T07:18:17 Dropped new table OK.
Dry run complete.  `test`.`t1` was not altered.

然后,使用 --execute 执行

pt-online-schema-change h=192.168.105.101,P=3306,u=root,p=root,D=test,t=t1 \
--alter "
  PARTITION BY RANGE (expired_date) (
    PARTITION p202501 VALUES LESS THAN (1738339200),  -- 2025-02-01 00:00:00
    PARTITION p202502 VALUES LESS THAN (1740758400),  -- 2025-03-01 00:00:00
    PARTITION p202503 VALUES LESS THAN (1743436800),  -- 2025-04-01 00:00:00
    PARTITION p202504 VALUES LESS THAN (1746028800),  -- 2025-05-01 00:00:00
    PARTITION p202505 VALUES LESS THAN (1748707200),  -- 2025-06-01 00:00:00
    PARTITION p_max VALUES LESS THAN MAXVALUE
  )" \
--recursion-method=none --no-check-replication-filters --no-check-unique-key-change --alter-foreign-keys-method auto --print --execute

执行结果:

Operation, tries, wait:
......
Operation, tries, wait:
......
Copying `test`.`t1`:  24% 01:30 remain
Copying `test`.`t1`:  59% 00:40 remain
Copying `test`.`t1`:  97% 00:02 remain
2025-05-05T07:22:02 Copied rows OK.
2025-05-05T07:22:02 Analyzing new table...
2025-05-05T07:22:02 Swapping tables...
RENAME TABLE `test`.`t1` TO `test`.`_t1_old`, `test`.`_t1_new` TO `test`.`t1`
2025-05-05T07:22:02 Swapped original and new tables OK.
2025-05-05T07:22:02 Dropping old table...
DROP TABLE IF EXISTS `test`.`_t1_old`
2025-05-05T07:22:02 Dropped old table `test`.`_t1_old` OK.
2025-05-05T07:22:02 Dropping triggers...
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_t1_del`
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_t1_upd`
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_t1_ins`
2025-05-05T07:22:02 Dropped triggers OK.
Successfully altered `test`.`t1`.

查看表结构

greatsql> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `id` int NOT NULL AUTO_INCREMENT,
  `data_value` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,
  `expired_date` int unsigned NOT NULL,
  PRIMARY KEY (`id`,`expired_date`)
) ENGINE=InnoDB AUTO_INCREMENT=10000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
/*!50100 PARTITION BY RANGE (`expired_date`)
(PARTITION p202501 VALUES LESS THAN (1738339200) ENGINE = InnoDB,
 PARTITION p202502 VALUES LESS THAN (1740758400) ENGINE = InnoDB,
 PARTITION p202503 VALUES LESS THAN (1743436800) ENGINE = InnoDB,
 PARTITION p202504 VALUES LESS THAN (1746028800) ENGINE = InnoDB,
 PARTITION p202505 VALUES LESS THAN (1748707200) ENGINE = InnoDB,
 PARTITION p_max VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */
1 row in set (0.00 sec)

此时可以看到,表 t1 已经调整为分区表了。

6. 测试验证

  1. 查询表分区及数据情况
-- 查询数据
greatsql> SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
| 10000000 |
+----------+
1 row in set (3.39 sec)

-- 查询分区
greatsql> SELECT table_schema,table_name,partition_name,partition_expression,partition_description FROM information_schema.partitions WHERE table_name = 't1' order by partition_name asc;
+--------------+------------+----------------+----------------------+-----------------------+
| TABLE_SCHEMA | TABLE_NAME | PARTITION_NAME | PARTITION_EXPRESSION | PARTITION_DESCRIPTION |
+--------------+------------+----------------+----------------------+-----------------------+
| test         | t1         | p202501        | `expired_date`       | 1738339200            |
| test         | t1         | p202502        | `expired_date`       | 1740758400            |
| test         | t1         | p202503        | `expired_date`       | 1743436800            |
| test         | t1         | p202504        | `expired_date`       | 1746028800            |
| test         | t1         | p202505        | `expired_date`       | 1748707200            |
| test         | t1         | p_max          | `expired_date`       | MAXVALUE              |
+--------------+------------+----------------+----------------------+-----------------------+
6 rows in set (0.01 sec)
  1. 查询表文件情况
total 509M
-rw-r----- 1 mysql mysql 116M May  5 07:22 t1#p#p202501.ibd
-rw-r----- 1 mysql mysql 104M May  5 07:22 t1#p#p202502.ibd
-rw-r----- 1 mysql mysql 116M May  5 07:22 t1#p#p202503.ibd
-rw-r----- 1 mysql mysql 112M May  5 07:22 t1#p#p202504.ibd
-rw-r----- 1 mysql mysql  60M May  5 07:22 t1#p#p202505.ibd
-rw-r----- 1 mysql mysql 112K May  5 07:22 t1#p#p_max.ibd

可以看到,t1.ibd 文件已经不存在了,每个 ibd 文件即为 分区文件。

  1. 删除数据,释放空间
    如果需要删除一些数据,直接删除分区即可
-- 删除 202501 分区数据
greatsql> ALTER TABLE t1 DROP PARTITION p202501;
Query OK, 0 rows affected (0.07 sec)
Records: 0  Duplicates: 0  Warnings: 0

greatsql> SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
|  7727745 |
+----------+
1 row in set (2.53 sec)

数据删除完成,看看文件系统所占空间是否释放?

total 393M
-rw-r----- 1 mysql mysql 104M May  5 07:42 t1#p#p202502.ibd
-rw-r----- 1 mysql mysql 116M May  5 07:22 t1#p#p202503.ibd
-rw-r----- 1 mysql mysql 112M May  5 07:22 t1#p#p202504.ibd
-rw-r----- 1 mysql mysql  60M May  5 07:22 t1#p#p202505.ibd
-rw-r----- 1 mysql mysql 112K May  5 07:22 t1#p#p_max.ibd

可以看到,分区 p202501 所使用的 ibd 文件也不存在了,文件系统空间得到了释放。

《干货分享》分区表改造(方案、脚本模板生成),值得收藏起来实战再用 前言 太久没有更新技术博客,后续还是保持以前的更新速度,走向2020的学习之路,也欢迎大家一起来学习学习. 一、分区表简介 1.1 什么是分区表? 分区表是将大表的数据分成称为分区的许多小的子集,分区表的种类划分主要有:range(范围)、list(列表)和hash(散列)分区。划分依据主要是根据其表内部属性。 分区表可以创建其独特的分区索引,分区表可以从物理上将一个大表分成几个小表,但是从逻辑... 阅读详情

相关推荐

SpringBoot+Vue+MySQL 高校学科竞赛平台 完整可运行版(源码+文档)

本项目基于SpringBoot+Vue+MySQL构建高校学科竞赛管理平台,覆盖学生、教师、领队教师、管理员四大角色,实现竞赛发布、报名、刷题、评分、公示等全流程闭环管理。系统架构清晰,技术主流,配套完整源码、数据库脚本、万字论文、开题报告、答辩PPT及部署文档,支持一键运行,适用于毕业设计、课程设计及院系二次开发,真正实现“开箱即用”。

招风的黑耳优快云 148

MySQL 日志表改造为分区表

业务有一张日志表,只需要保留 3 个月的数据,仅 3 月的数据就占用 80G 的存储空间,如果不定期清理那么磁盘容纳不下,但是每次清理的时候,使用 DELETE 删除非常慢,还会产生大量的 Binlog 日志,而且删除后会产生大量的空间碎片,回收需要重建表,期间还会造成临时空间增长(Online DDL 排序需要使用临时空间)需要先扩磁盘,等待空间收缩后再缩容,非常麻烦。了解到这张表几乎不会查询,只会在发生问题的时候查询,所以非常适合使用分区表。

分享既学习 2220

论文阅读笔记:Extended Vision Transformer (ExViT) for Land Use and Land Cover Classification

注意力机制驱动的深度模型最近取得了成功,如最具代表性的视觉转换器(ViT),吸引了一波高级研究来探索它们对更广泛领域的适应。然而,遥感(RS)领域中基于Transformer的方法更关注单模态数据,这可能会在充分利用不断增长的多模态地球观测数据时失去可扩展性。为此,我们提出了一种新的多模式深度学习框架,通过在最小修改的情况下扩展传统的ViT,针对土地利用和土地覆盖(LULC)分类任务。

嗑研狗的日常 945

oracle 普通表-分区表改造流程

append 增加数据的时候 不会检查HWM中是否有空闲块,会直接往HWM之上一个新块当中插入数据,所以一定要批量插入,要不然每一条数据就会增加一个新块 十分浪费空间.查询test中全部,插入test_p中,p和n是test_p和test的别名,parallel的并行度为10,append为insert快的参数。检查数据是否完整,无误则开启应用。保险起见老的数据保留一个月,确定无误后将表删除,释放空间。

汪灵骅的博客 1152

MacOS下微信小程序源码提取与逆向实战:从找到.wxapkg到完整还原

本文详细介绍了在MacOS系统下进行微信小程序源码提取与逆向分析的完整实战流程。从定位沙盒机制中的.wxapkg缓存文件,到搭建Node.js环境与配置wxappUnpacker工具链,再到执行核心反编译命令并处理分包等复杂情况,提供了清晰的操作步骤。文章还汇总了Node版本、依赖缺失、文件乱码等常见问题的解决方案,旨在帮助开发者、安全研究人员高效完成小程序安全审计与学习。

weixin_29246195的博客 1602

避免踩坑!WIN11 22H2更新后共享打印机失效的终极解决方案

本文详细解析了WIN11 22H2更新后共享打印机失效的问题,特别是常见的0x00000709错误代码。通过系统更新机制分析、错误代码解读,提供从基础到高级的完整解决方案,包括注册表修复、组策略调整和驱动兼容性处理,帮助用户彻底解决打印机共享问题并预防未来故障。

pp12345的博客 533

大表改造成分区表

首先查询用户下的大表方法一:select table_name,num_rows from user_tables order by num_rows desc;(按表的行数排序)方法二:create or replace function count_rows(table_name in varchar2) return numberis num_r...

weixin_34087503的博客 495

Cursor+Playwright MCP实战:如何用自然语言一键生成UI自动化测试脚本

本文探讨了如何利用Cursor与Playwright MCP实现自然语言驱动的UI自动化测试脚本生成。通过智能IDE与浏览器自动化协议的结合,开发者可以高效创建稳定的测试脚本,显著提升测试效率与维护性。重点介绍了MCP架构的优势、项目结构最佳实践及团队协作规范,为自动化测试带来革命性改进。

k8l9m0n的博客 441

数据库周刊60丨3月国产数据库排行榜出炉;日本银行数据迁移失败致使业务宕机;阿里云RDS PG13发布;亚健康Oracle数据库故障定位;Redis最佳实践;MySQL查询优化……

热门资讯 [1、2021年3月国产数据库排行榜:雏凤声清阿里三连 绝代双骄华为合璧 【摘要】2021年3月国产数据库流行度排行榜已出炉,在本月排行的前十名中,TiDB 仍然以领先第二名135分 的优势稳居榜首,OceanBase 本月积分大涨跃升至第二位,达梦则是降低一位至第三名。前十名中,在冠军 TiDB 之外,可以用一句话概括,就是:三升三降三不变。 [2、日本银行的数据迁移失败:在线业务宕机、ATM 变成了吞卡怪兽 【摘要】日本的瑞穗银行(Mizuho Bank)近日公开道歉,起因是数据迁移工作将其.

ToyaAkira00的博客 639

zabbix6.0.4拓扑图链路显示流量

1. 背景介绍 网络流量监控是网络管理员必备功课,以前研究cacti的weathermap插件,网络流量大小和拥塞情况一清二楚,随着cacti的没落,weathermap插件也不能再继续使用,此时就需要学习了解新的替代方案。 经过研究和实际测试,发现zabbix的拓扑图有这个功能。 以下验证了zabbix的拓扑图显示线路流量的功能。 2. Zabbix 6显示拓扑图流量过程 选择监测-拓扑图 点进Local ne...

u013930899的博客 8483

2021年03月 C/C++(五级)真题解析#中国电子学会#全国青少年软件编程等级考试

给定一个十进制正整数n(0 < n < 1000000000),每个数位上数字均不为0。n的位数为m。现在从m位中删除k位(0

人生就是一个不断学习的过程 1011

Oracle普通表自动改造分区表(可借鉴到其他数据库)

这是我编写的最经典的工具之一,很实用,技术含金量也比较高。本工具是基于Oracle的,但是这种结合数据字典的方式,是有通用性的,已经改造在PG数据库和部分国产数据库上了。这工具让AI来写,还真靠不住,不信你们可以尝试一下:)

从底层逻辑去思考技术,去拥抱变化 575

一文讲透 SAP VDM 命名里的前缀与后缀:看懂 I_、C_、A_,把 CDS 视图栈搭得又稳又好用

SAP S/4HANA 的 CDS 视图命名规范解析 摘要:本文详细解析 SAP S/4HANA 中 CDS 视图的 VDM 命名规范。通过前缀(如 I_、C_、R_)区分视图层级,后缀标记附加角色,结合 @VDM.viewType 注解形成完整语义体系。I_作为稳定接口层,C_面向特定场景裁剪,R_限定应用域内复用,A_提供远程 API 接口。命名规范使团队能快速识别视图用途、依赖关系和扩展边界,确保模型长期可维护性。文章结合制造业物料主数据、Fiori 应用等实际案例,说明如何通过规范命名构建清晰的视图

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 220

Java EE 进阶:8.MyBatis 操作数据库(入门)(第一弹)

Java EE 进阶:8.MyBatis 操作数据库(入门)(第一弹)

要努力去发光,而不是被照亮~ 130

VisionPro 机器视觉案例 之 彩色保险丝个数统计

CogColorSegmenterTool CogColorMatchTool

机器视觉李小白的博客 2353

Probability and Statistics - 4th edition

Probability and Statistics - 4th edition

Spring Boot 数据源与 MyBatis(-Plus) 自定义配置详解

本文详解 Spring Boot 中单数据源环境下 HikariCP 与 MyBatis-Plus 的自定义配置。通过手动声明 SqlSessionFactory,实现下划线转驼峰、日志输出、一级缓存策略等精细化控制。结合 HikariCP 核心参数调优(如最大连接数、连接生命周期),确保高性能与稳定性。适用于仅需访问单一数据库的场景,避免多数据源复杂性,兼顾性能与可维护性。

BADAO_LIUMANG_QIZHI的博客 198

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

Docker Compose:搭建本地多服务开发环境

从一个 Java API、PostgreSQL 和 Redis 开始,配置服务名、端口、环境变量、健康检查、数据卷和依赖关系。理解 Compose 文件如何被解析、项目如何隔离,以及哪些数据不能依赖“重建容器”保留,能够把个人开发环境整理成团队可复用的启动入口。

m0_62221377的博客 457

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

ssm框架搭建

这个是一个在idea上成功跑起来的ssm框架项目,保存在这里方便以后使用直接下载

AI全栈实战 | 3.9-01 爬虫入门:requests 加 BeautifulSoup 三分钟跑通,但 90% 的人栽在这 4 个“礼貌“问题上

⚠️:本文内容仅用于。请遵守目标站点的服务条款与相关法律法规,不得对目标服务造成负担,不得采集、传播个人隐私数据。技术是中性的,边界在你手里。爬虫的入门技术(requests 发请求 + BeautifulSoup 解析)三分钟就能学会。真正区分"会用爬虫"和"会做爬虫的人"的,是这篇我们跑通"请求→解析→存储"的最小闭环,然后重点把"合规与礼貌"这根弦给你绷上。

源码获取 | 运行部署 | 定制二开修改,如果回复不及时请耐心等待,请见谅。 410

数据库主键选型指南:BIGINT vs VARCHAR

主键选型关乎数据库性能与架构演进。BIGINT(如雪花算法)在顺序写入、二级索引开销和分布式生成上优势显著,适合高并发核心链路;而传统 VARCHAR UUIDv4 因随机性导致频繁页分裂、存储膨胀,性能堪忧。UUIDv7 通过时间戳有序性实现高效追加写入,结合 BINARY(16) 存储可兼顾性能与安全,成为现代微服务新选择。关键在于:主键应稳定、无业务含义,优先选用趋势递增的紧凑类型,并根据场景合理采用双主键模式或 ULID 等替代方案。

小李同学的博客 301

自动化运维选型:四条技术路线的能力边界,以及它们为什么不能互相替代

自动化运维怎么选型?拆解配置管理、基础设施即代码、作业调度与场景化编排四条技术路线边界,分析账本归属与时间语义差异,给出四种架构组合与判断点,帮企业看清为何不能互相替代。

trainsignalcn的专栏 327

C++算法(七)

C++ stack算法题和一些客观题

2503_94479566的博客 370

不用再为文本搜索单独维护一套系统!全文检索深度解析

为了给商品、客服工单或者企业知识库增加一个搜索框,企业往往需要在业务数据库之外,再部署一套Elasticsearch。数据库保存商品、订单和用户等真实业务数据,搜索引擎保存另一份文本索引;两套系统之间,还需要通过CDC、消息队列或者同步程序持续传输数据。一个看似简单的搜索需求,最后可能变成两套集群、两份数据和一条必须保持稳定的数据链路。由此产生的问题并不少:数据库已经完成更新,搜索结果却可能尚未同步;业务查询同时涉及文本、库存、权限和订单状态时,应用需要在两个系统之间来回组合结果;

TiDB 社区干货传送门 250

IDEA 简介:从零认识 IntelliJ IDEA

IDEA 全称,是由 JetBrains 公司开发的一款主流 Java 集成开发环境(IDE)。它集代码编辑、编译、调试、测试、版本控制、构建管理等功能于一体,被大量 Java 开发者视为日常开发的首选工具。所谓 IDE(Integrated Development Environment,集成开发环境),就是把写代码所需的各类工具整合到同一个界面中。相比只用文本编辑器加命令行编译,IDE 能显著减少重复操作,让开发者把精力集中在业务逻辑上。

ztI10的博客 152

48-逻辑结构表空间段区块

默认 10%,意思是块里的空闲空间低于 10% 时就不再插入新行,留着给已有行的 UPDATE 变胖用。注意 INSERT 过程中每次申请新区,都是一次潜在的空间报错点,如果表空间满了,此刻就会抛 ORA-01653。剩下的空间被谁占了?段的每个区可以落在表空间的任一数据文件,所以 2T 的表在 32G 单文件上限(smallfile)的世界里照样能活——多加文件就行。,一张只有两个 CLOB 字段的表,实际在库里是三个段(表段 + 两个 LOBSEGMENT),空间统计漏算 LOB 段是新手常犯的错。

yuhou25的博客 286

市场调查与统计分析专业大学期间考证怎么安排?

市场调查与统计分析专业的考证规划,适合从一份完整的调查报告倒推:能不能设计问卷、判断样本是否合理、清洗数据,再把分析结果转化为业务建议?围绕这条能力链安排证书,比单纯按“热门程度”报名更有针对性。结合2026年的学习安排,并为2027年的实习、升学和求职预留时间,大学期间可以重点考虑六类证书:全国计算机等级考试证书、大学英语四级或六级成绩报告单、CDA数据分析师、初级统计专业技术资格证书、微软办公软件国际认证中的Excel相关证书,以及软考数据库系统工程师资格证书。

cc572502653的博客 158

Oracle 19c 在线重定义后旧表空间清理及 ASM 存储资源回收 SOP

Oracle 19c 在线重定义后旧表空间清理与 ASM 存储资源回收 SOP

「YYL DBA手记」 数据库 · 架构 · 运维 · 实战 yyldba.blog.youkuaiyun.com 486
上一篇: GreatSQL优化技巧:手动实现谓词下推
下一篇: GreatSQL分页查询优化案例实战
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值