换哪个数据库，我还能省100万，创造业绩

AustinDatabases

发布于 2026-07-01 18:31:38

❝开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6 7 8群已经爆满 9群为纯聊天群，默认不加入不得发广告，自己公众号文章链接等，发一次直接踢，默认加入8群，开10群PolarDB专业学习群115+)

《告别迁移焦虑：OceanBase MySQL 模式能否兼容 DBA 的“祖传”运维 SQL？》

体现价值-我们靠PostgreSQL迁移PolarDB，给公司省下了100万 “巨款”

在企业里做事，千万不要以为一个功劳可以吃一辈子，实际上你连下个月都吃不到，人性对于你过去所做的贡献，都会选择性的遗忘，这也就是忘恩负义之人，满大街都是的原因，不赖他们，是人性，他们不恨你那就算是个正常人了。（关于心理学可以关注另一个号，里面有所研究）

作为一个非常懂得人性的，数据库从业者，这业绩的一直做，经济下行，什么TPS跑的有多快，国产数据库一些指标是世界第一名，俩字，没用，三字，真没用，他是让你涨不了工资，也让你没法晋升。

企业要的是成本下降，数据库工作者要的是工作业绩，降低成本，是做数据库的工作者，也是目前为数不多体现价值的工作之一。不然你真的要上抖音，去卖国产数据库？？

成本削减，从数据库本体来说，包含硬件成本，软件成本，削减的正路就是用更少的硬件来承载更多的项目，这里有三点，CPU，内存，磁盘，而磁盘最近比较贵贵的，用更少的磁盘存储更多的数据库的数据，减少数据的量级还能减少备份设备的采买，这些设备减少了，还会节约空调设备的采购。电费也会节省，这算来算去，最简单的节省成本的方案还是要从磁盘下手。

最近公司的外部项目，一个央企的项目禁止 PG ,MYSQL，MongoDB的进入，俗称数据库要在信创名单，PolarDB是云上的，云下的我根本也没打算用，节省磁盘成本的主意，我自然打到了OB的头上，分布式在那个项目里面应该是用不上，但是OB 单体数据库倒是可以看看，反正他们也在那个信创名录的名单里面，不用考虑方案本身的不合法性。

一直听闻oceanbase 的数据压缩有两把刷子，可能压多少，MYSQL系统里面的数据到了OB到底能变的多小，这到没有测过，索性咱们测试看看，到底这单体的OB 有多大的道行。测试要充足，各种数据的类型都要进行测试。

准备测试数据，测试数据的类型要多样，找出OB数据压缩的优势和劣势，所以必须要严格的测试，测试表如下

1 表中全部是 INT BIGINT类型的

2 表中全部是时间类型的

3 表中全部是文字类型的

4 综合类型

每个类型都灌入100万上的数据

版本也拿到了最新版4.2.X,然后就是建表，插入数据。但在插入数据的时候，发现一个问题，单机的OB在插入数据，比MySQL 快的多。

image

image

在执行完存储过程给四个表每个表都插入100万数据,可以清晰的看到OceanBase这边插入400万数据耗时 1分44秒，MySQL 8同样的插入400万数据耗时 11分42秒。在研究完OB的数据存储的原理，OB插入数据快这是必然，也没有什么好惊叹的，LSM TREE的优势。但是数据压缩这块我们的看看到底之间的差距有多大。

image

我们针对对四个表的压缩成绩进行比对，我们可以发现针对字符形的，混合型的数据OB的压缩非常的狠。

image

这里我们把建表语句和填充的存储过程贴一下

CREATE TABLE `test_int_only` (
 `id` BIGINT NOT NULL AUTO_INCREMENT,
 `tenant_id` INT NOT NULL,
 `user_id` BIGINT NOT NULL,
 `order_status` INT NOT NULL,
 `click_count` INT NOT NULL,
 `amount_cents` BIGINT NOT NULL,
 `score` INT NOT NULL,
 `version` INT NOT NULL,
 PRIMARY KEY (`id`),
 KEY `idx_user_status` (`user_id`, `order_status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `test_datetime_only` (
 `id` BIGINT NOT NULL AUTO_INCREMENT,
 `create_time` DATETIME NOT NULL,
 `update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP,
 `login_date` DATE NOT NULL,
 `logout_time` DATETIME NOT NULL,
 `pay_time` TIMESTAMP NOT NULL DEFAULT '2026-01-01 00:00:00',
 `schedule_date` DATE NOT NULL,
 PRIMARY KEY (`id`),
 KEY `idx_create_time` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `test_text_only` (
 `id` BIGINT NOT NULL AUTO_INCREMENT,
 `short_code` VARCHAR(32) NOT NULL,
 `username` VARCHAR(64) NOT NULL,
 `title` VARCHAR(255) NOT NULL,
 `user_comment` VARCHAR(500) NOT NULL,
 `sys_log` VARCHAR(1000) NOT NULL,
 PRIMARY KEY (`id`),
 KEY `idx_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

TE TABLE `test_mixed_general` (
 `id` BIGINT NOT NULL AUTO_INCREMENT,
 `biz_no` VARCHAR(64) NOT NULL,
 `customer_id` BIGINT NOT NULL,
 `biz_type` INT NOT NULL,
 `amount` DECIMAL(18,4) NOT NULL,
 `is_deleted` TINYINT NOT NULL DEFAULT 0,
 `remark` VARCHAR(255) DEFAULT NULL,
 `create_time` DATETIME NOT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `uk_biz_no` (`biz_no`),
 KEY `idx_customer_time` (`customer_id`, `create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

DELIMITER $$
CREATE PROCEDURE proc_batch_load_data()
BEGIN
 DECLARE i INT DEFAULT 1;
 DECLARE rand_str VARCHAR(1000);
-- 关闭事务自动提交以提升灌入效率
 SET @@autocommit = 0;
-- 1. 灌入全数字表 (100万行)
 WHILE i <= 1000000 DO
 INSERT INTO test_int_only (tenant_id, user_id, order_status, click_count,
amount_cents, score, version)
 VALUES (
 FLOOR(100 + RAND() * 900), -- 3位租户ID
 FLOOR(100000 + RAND() * 9000000), -- 7位离散用户ID
 FLOOR(1 + RAND() * 5), -- 状态1-5
 FLOOR(RAND() * 1000), -- 点击数
 FLOOR(1000 + RAND() * 1000000), -- 金额流水
 FLOOR(50 + RAND() * 100), -- 积分
 i -- 递增版本号
);
-- 每1万行提交一次，防止大事务
 IF MOD(i, 10000) = 0 THEN
 COMMIT;
 END IF;
 SET i = i + 1;
 END WHILE;
 COMMIT;
-- 2. 灌入全时间表 (100万行)
 SET i = 1;
 WHILE i <= 1000000 DO
 INSERT INTO test_datetime_only (create_time, login_date, logout_time,
schedule_date)
 VALUES (
DATE_ADD('2020-01-01 00:00:00', INTERVAL FLOOR(RAND() * 200000) MINUTE),
 DATE_ADD('2020-01-01', INTERVAL FLOOR(RAND() * 2000) DAY),
 DATE_ADD('2020-01-01 02:00:00', INTERVAL FLOOR(RAND() * 200000) MINUTE),
 DATE_ADD('2026-01-01', INTERVAL FLOOR(RAND() * 365) DAY)
 );
 IF MOD(i, 10000) = 0 THEN
 COMMIT;
 END IF;
 SET i = i + 1;
 END WHILE;

COMMIT;
-- 3. 灌入全文本表 (100万行)
 SET i = 1;
 WHILE i <= 1000000 DO
 INSERT INTO test_text_only (short_code, username, title, user_comment, sys_log)
 VALUES (
 MD5(i),
 CONCAT('user_tpl_', i),
 CONCAT('关于系统高并发架构下的核心数据重构主题讨论报告_序列_', i),
 CONCAT('测试用户评论：整体系统的响应速度还可以，但是每次一到月底大表DDL变更就卡死，希望数据
库架构师赶紧用上MongoDB或者OceanBase解决无锁表问题。数字：', i),
 CONCAT('ERROR 2026-06-14 20:39:51 [com.infra.db.pool] Connection timeout. Over
100ms waiting for wal commit. Context: ', MD5(RAND()))
 );
 IF MOD(i, 10000) = 0 THEN
 COMMIT;
 END IF;
 SET i = i + 1;
 END WHILE;
 COMMIT;
-- 4. 灌入综合业务表 (100万行)
 SET i = 1;
 WHILE i <= 1000000 DO
 INSERT INTO test_mixed_general (biz_no, customer_id, biz_type, amount, is_deleted,
remark, create_time)
 VALUES (
 CONCAT('BIZ-', YEAR(NOW()), '-', 10000000 + i),
 FLOOR(500000 + RAND() * 500000),
 FLOOR(1 + RAND() * 10),
 (10.5 + RAND() * 9999.9),
IF(RAND() > 0.95, 1, 0),
 IF(RAND() > 0.5, '核心业务系统标准结算流水回滚凭证', NULL),
 DATE_ADD('2025-01-01 00:00:00', INTERVAL FLOOR(RAND() * 500000) MINUTE)
 );
 IF MOD(i, 10000) = 0 THEN
 COMMIT;
 END IF;
 SET i = i + 1;
 END WHILE;
 COMMIT;
 SET @@autocommit = 1;
END $$
DELIMITER ;

OB压缩数据能力

obclient(root@test)[db_test]> SELECT 
    ->     table_name AS '表名',
    ->     table_rows AS '实际行数',
    ->     ROUND(data_length / 1024 / 1024, 2) AS 'OB真实物理占用 (MB)',
    ->     ROUND(index_length / 1024 / 1024, 2) AS 'OB索引实际占用 (MB)'
    -> FROM information_schema.tables 
    -> WHERE table_schema = 'db_test'
    ->   AND table_name IN ('test_int_only', 'test_datetime_only', 'test_text_only', 'test_mixed_general');
+--------------------+--------------+---------------------------+---------------------------+
| 表名               | 实际行数     | OB真实物理占用 (MB)       | OB索引实际占用 (MB)       |
+--------------------+--------------+---------------------------+---------------------------+
| test_int_only      |      1000000 |                     44.00 |                     22.00 |
| test_datetime_only |      1000000 |                     40.00 |                     20.00 |
| test_text_only     |      1000000 |                    140.00 |                     16.00 |
| test_mixed_general |      1000000 |                     42.00 |                     42.00 |
+--------------------+--------------+---------------------------+---------------------------+
4 rows inset (0.049 sec)

MYSQL 插入数据空间占用


mysql> SELECT table_name AS '表名', ROUND(((data_length + index_length) / 1024 / 1024), 2) AS '总占用空间 (MB)', ROUND((data_length / 1024 / 1024), 2) AS '数据量 (MB)', ROUND((index_length / 1024 / 1024), 2) AS '索引量 (MB)', table_rows AS '行数' FROM information_schema.tables WHERE table_schema = 'db_test' AND table_name IN ('test_int_only', 'test_datetime_only', 'test_text_only', 'test_mixed_general');
+--------------------+----------------------+----------------+----------------+--------+
| 表名               | 总占用空间 (MB)      | 数据量 (MB)    | 索引量 (MB)    | 行数   |
+--------------------+----------------------+----------------+----------------+--------+
| test_datetime_only |                78.16 |          48.58 |          29.58 | 997128 |
| test_int_only      |               102.17 |          64.59 |          37.58 | 996228 |
| test_mixed_general |               158.83 |          92.64 |          66.19 | 995771 |
| test_text_only     |               535.63 |         487.00 |          48.63 | 945730 |
+--------------------+----------------------+----------------+----------------+--------+
4 rows in set (0.01 sec)

计算此次测试实际节省磁盘空间

最后我们计算了一下OB 在压缩数据这块的特点，OceanBase 在所有测试场景下的存储空间占用均远小于 MySQL。在总空间占用上，OB 相比 MySQL 节省了 23.2% 到 70.9% 不等。文本数据压缩率极高：对于 test_text_only 表，OB 展现了极强的压缩能力，数据量从 MySQL 的 487 MB 压缩至 140 MB，空间节省高达 71.2%。对于 test_int_only 和 test_datetime_only 这类结构化强、冗余度低的数值数据，压缩难度较大，但 OB 依然分别实现了 31.8% 和 17.6% 的数据量压缩。除此以外，对于索引本身也有较强的压缩能力。文本表 (test_text_only) 的索引从 MySQL 的 48.63 MB 压缩至 OB 的 16 MB，节省率达 67.1%，混合表 (test_mixed_general) 索引从 66.19 MB 压缩至 42 MB，节省率达 36.5%。

OceanBase 使用 LSM-Tree 架构及高效的数据/索引编码压缩技术，在存储成本控制上具有绝对优势。数据特征越适合压缩（如长文本、高重复率字符串），OB 的压缩收益越夸张（可达 70% 以上）；即使是针对难以压缩的整型与时间类型，OB 也能通过宏观架构与微块压缩提供 20%-35% 的存储节省。

这我的好好看看，现在的MySQL数据存储容量压缩50%后，能节省多少钱，备份设备能节省多少，UPS是不是能削减一下，这算算能不能又是一个节费 100万的项目。