这个MySQL说“云上自建的MySQL”都是”小垃圾“

AustinDatabases

发布于 2025-04-26 13:07:24

2700

代码可运行

文章被收录于专栏：AustinDatabasesAustinDatabases

运行总次数：0

代码可运行

最近越来越多的人知道上云还用ECS自建的MySQL是垃圾，是呀用经济学原理一分析，就知道有多垃圾了。有人问了，你说的那个是价值观，太宏观，你说点干货，怎么自建的MySQL就垃圾了，来来来，今天我给你看一个云原生数据库的功能，你敢说你的自建MySQL不是小垃圾。

故事开头是我们的一个同事在产生一个新的PolarDB for MySQL的时候，发现一些和之前配置不同的地方，并进行询问，我后面也跟了进去。

后面我就发现了一些问题，主要还是云原生数据库的不学习就落后的问题，顺着客服给我的信息，我突然发现一些POALRDB FOR MYSQL之前没有的功能。

在此之前我们使用PolarDB for MySQL的通用功能是通过X-Engine 引擎来进行的数据的归档和压缩的。

x-Engine

最近光忙活MongoDB的升级和PolarDB for PostgreSQL的事情了，一段时间没有去关注PolarDB for MySQL，这个数据库新版本提供了类似 PolarDB for PostgreSQL的冷数据归档的方案。

PolarDB for Mysql 归档新方案

废话不说，咱们先试试这个PolarDB for MySQL的直接归档表的新功能。

MySQL [test]> SELECT 
    ->     TABLE_NAME AS `Table`,
    ->     ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS `Size (MB)`,
    ->     TABLE_ROWS AS `Rows`
    -> FROM 
    ->     information_schema.TABLES
    -> WHERE 
    ->     TABLE_SCHEMA = 'test'
    -> ORDER BY 
    ->     (DATA_LENGTH + INDEX_LENGTH) DESC;
+------------+-----------+--------+
| Table      | Size (MB) | Rows   |
+------------+-----------+--------+
| text       |     40.58 | 997819 |
| test_table |      0.02 |      0 |
+------------+-----------+--------+
2 rows inset (0.004 sec)

MySQL [test]>

MySQL [test]> SELECT 
    ->     TABLE_NAME AS `Table`,
    ->     ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS `Size (MB)`,
    ->     TABLE_ROWS AS `Rows`
    -> FROM 
    ->     information_schema.TABLES
    -> WHERE 
    ->     TABLE_SCHEMA = 'test'
    -> ORDER BY 
    ->     (DATA_LENGTH + INDEX_LENGTH) DESC;
+------------+-----------+--------+
| Table      | Size (MB) | Rows   |
+------------+-----------+--------+
| text       |     40.58 | 997819 |
| test_table |      0.02 |      0 |
+------------+-----------+--------+
2 rows inset (0.004 sec)

MySQL [test]> alter table text engine = CSV storage OSS;
Query OK, 1000000 rows affected (3.124 sec)
Records: 1000000  Duplicates: 0  Warnings: 0

MySQL [test]> alter table text engine = innodb;
Query OK, 1000000 rows affected (6.440 sec)
Records: 1000000  Duplicates: 0  Warnings: 0

MySQL [test]> alter table text engine = CSV storage OSS;
Query OK, 1000000 rows affected (2.534 sec)
Records: 1000000  Duplicates: 0  Warnings: 0

MySQL [test]> select * from text limit 1;
+----+---------------+
| id | varchar_col   |
+----+---------------+
|  1 | data_00000000 |
+----+---------------+
1 row inset (0.133 sec)

MySQL [test]> select * from text limit 1000;
+------+---------------+
| id   | varchar_col   |
+------+---------------+
|    1 | data_00000000 |
|    2 | data_00000001 |
|    3 | data_00000002 |
|    4 | data_00000003 |
|    5 | data_00000004 |
|    6 | data_00000005 |
|    7 | data_00000006 |
|    8 | data_00000007 |
|    9 | data_00000008 |
|   10 | data_00000009 |
|   11 | data_00000010 |
|   12 | data_00000011 |
|   13 | data_00000012 |
|   14 | data_00000013 |
|   15 | data_00000014 |
|  979 | data_00000978 |
|  980 | data_00000979 |
|  981 | data_00000980 |
|  982 | data_00000981 |
|  983 | data_00000982 |
|  984 | data_00000983 |
|  985 | data_00000984 |
|  986 | data_00000985 |
|  987 | data_00000986 |
|  988 | data_00000987 |
|  989 | data_00000988 |
|  990 | data_00000989 |
|  991 | data_00000990 |
|  992 | data_00000991 |
|  993 | data_00000992 |
|  994 | data_00000993 |
|  995 | data_00000994 |
|  996 | data_00000995 |
|  997 | data_00000996 |
|  998 | data_00000997 |
|  999 | data_00000998 |
| 1000 | data_00000999 |
+------+---------------+
1000 rows inset (0.107 sec)

归档后

把数据重新提出归档系统

归档后对应界面中的表已经消失

看来这功能是有点意思！！这以后归档表那不是太方便了吗，还需要 mysqldump 吗？还需要导入导出数据节省成本，在节省成本能有 OSS成本低，几分钱的成本，如果你嫌弃这个还高，那你把这些数据存到纸上都的几十块钱。

在查看文档的时候，我还发现，他不光可以把表存储成 csv方式进行归档，还可以存储成 ibd 文件

这里需要说一下，这两种方式的不同

1 将MySQL的表转为CSV的方式的意义在于只要归档了这个表就不可以变化了，数据就是死的，只能读

2 将MySQL的表转为idb文件的归档方式的好处是归档的表还可以进行DML的操作，但不能进行DDL的操作。

这个功能一出，我想都能想的到一些企业的需求马上就能被满足，尤其Saas 企业。一些企业的数据归档后，客户不知道那天冒出来，还要数据，你还没发拒绝，这功能可以支持数据归档后，在归档中将文件进行变更，这太牛了。

马上试一下,What F 我的天，这功能可以呀！！！

                                                                                                   
MySQL [test]> SELECT                                                                               
    ->     TABLE_NAME AS `Table`,
    ->     ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS `Size (MB)`,
    ->     TABLE_ROWS AS `Rows`
    -> FROM 
    ->     information_schema.TABLES
    -> WHERE 
    ->     TABLE_SCHEMA = 'test'
    -> ORDER BY 
    ->     (DATA_LENGTH + INDEX_LENGTH) DESC;
+------------+-----------+--------+
| Table      | Size (MB) | Rows   |
+------------+-----------+--------+
| text       |     40.58 | 997819 |
| test_table |      0.02 |      0 |
+------------+-----------+--------+
2 rows inset (0.004 sec)

MySQL [test]> alter table text storage_type oss;
Query OK, 0 rows affected (1.007 sec)
Records: 0  Duplicates: 0  Warnings: 0

MySQL [test]> select * from text limit 1;
+----+---------------+
| id | varchar_col   |
+----+---------------+
|  1 | data_00000000 |
+----+---------------+
1 row inset (0.003 sec)

MySQL [test]> update text set varchar_col = '11111'where id = 1;
Query OK, 1 row affected (0.006 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MySQL [test]> select * from text limit 1;                        
+----+-------------+
| id | varchar_col |
+----+-------------+
|  1 | 11111       |
+----+-------------+
1 row inset (0.094 sec)

MySQL [test]>

写到这里，我对比了一下两种的归档方式的文件大小

1 ibd 大小是 60MB 2 csv 大小事 27MB左右

ibd文件大小

那么这里我总结，如果是真正归档，那么我们选择CSV的格式，这里数据不能再变动，但如果是我刚才说的那个需求，不定什么时间客户还要数据，还要改这个数据，那么把数据文件变成 ibd就是最优选。

最后我们说一下数据的清理，在MySQL中如果删除一张表我们通过drop table命令来进行，而在PolarDB中，将表归档到OSS 后删除表需要两个步骤。

删除归档表的注意事项


MySQL [test]> select * from text limit 1;
+----+---------------+
| id | varchar_col   |
+----+---------------+
|  1 | data_00000000 |
+----+---------------+
1 row inset (0.003 sec)

MySQL [test]> update text set varchar_col = '11111'where id = 1;
Query OK, 1 row affected (0.006 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MySQL [test]> select * from text limit 1;                        
+----+-------------+
| id | varchar_col |
+----+-------------+
|  1 | 11111       |
+----+-------------+
1 row inset (0.094 sec)

MySQL [test]> call dbms_oss.delete_table_file('test','text');
ERROR 8079 (HY000): [INNODB OSS] Operation failed. OSS files are still in use.
MySQL [test]> drop table text;
Query OK, 0 rows affected (0.010 sec)

MySQL [test]> call dbms_oss.delete_table_file('test','text');
Query OK, 0 rows affected (0.783 sec)

MySQL [test]>