这个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的直接归档表的新功能。
代码语言：javascript代码运行次数：0运行复制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 我的天，这功能可以呀！！！
代码语言：javascript代码运行次数：0运行复制
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 后删除表需要两个步骤。
删除归档表的注意事项
代码语言：javascript代码运行次数：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]> 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]>
通过上面的演示，POALRDB FOR MYSQL 的数据归档表的方式我已经写清楚了，通过这样的方式，归档将只在库内进行，而不用再库外进行，或者在导出数据，对于一些Saas类的企业，这样的功能简直是到了心坎里面。
同时对于PolarDB for MySQL的数据归档的性能有相关的说明，我们在使用的过程中也发现时间比我们想的要快，甚至我们都想把一些冷库都转成归档IBD的形式，这是不是太鸡贼了，为了省钱我们是什么都敢干！！