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

最近越来越多的人知道上云还用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]>

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.

登录后复制

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)

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.
• 20.
• 21.
• 22.
• 23.
• 24.
• 25.
• 26.
• 27.
• 28.
• 29.
• 30.
• 31.
• 32.
• 33.
• 34.
• 35.
• 36.
• 37.
• 38.
• 39.
• 40.
• 41.
• 42.
• 43.
• 44.
• 45.
• 46.
• 47.
• 48.
• 49.
• 50.
• 51.
• 52.
• 53.
• 54.
• 55.
• 56.
• 57.
• 58.
• 59.
• 60.
• 61.
• 62.
• 63.
• 64.
• 65.
• 66.
• 67.
• 68.
• 69.
• 70.
• 71.
• 72.
• 73.
• 74.
• 75.
• 76.
• 77.
• 78.
• 79.
• 80.
• 81.

归档后

把数据重新提出归档系统

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

看来这功能是有点意思！！  这以后归档表那不是太方便了吗，还需要 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.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.
• 20.
• 21.
• 22.
• 23.
• 24.
• 25.
• 26.
• 27.
• 28.
• 29.
• 30.
• 31.
• 32.
• 33.
• 34.
• 35.
• 36.
• 37.
• 38.
• 39.
• 40.
• 41.
• 42.
• 43.

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

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]>

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.
• 20.
• 21.
• 22.
• 23.
• 24.
• 25.
• 26.
• 27.
• 28.
• 29.

通过上面的演示，POALRDB FOR MYSQL 的数据归档表的方式我已经写清楚了，通过这样的方式，归档将只在库内进行，而不用再库外进行，或者在导出数据，对于一些Saas类的企业，这样的功能简直是到了心坎里面。

同时对于PolarDB for MySQL的数据归档的性能有相关的说明，我们在使用的过程中也发现时间比我们想的要快，甚至我们都想把一些冷库都转成归档IBD的形式，这是不是太鸡贼了，为了省钱我们是什么都敢干！！