【Mysql 学习】MERGE存储引擎(一)

简介: MERGE存储引擎(一)MERGE表的问题   MERGE存储引擎,也被认识为MRG_MyISAM引擎,是一个相同的可以被当作一个来用的MyISAM表的集合。“相同”意味着所有表同样的列和索引信息。

MERGE存储引擎(一)
MERGE表的问题
   MERGE存储引擎,也被认识为MRG_MyISAM引擎,是一个相同的可以被当作一个来用的MyISAM表的集合。“相同”意味着所有表同样的列和索引信息。你不能合并列被以不同顺序列于其中的表,没有恰好同样列的表,或有不同顺序索引的表。而且,任何或者所有的表可以用myisampack来压缩。表选项的差异,比如AVG_ROW_LENGTH, MAX_ROWS或PACK_KEYS都不重要。
   当你创建一个MERGE表之时,MySQL在磁盘上创建两个文件。文件名以表的名字开始,并且有一个扩展名来指明文件类型。一个.frm文件存储表定义,一个.MRG文件包含被当作一个来用的表的名字。这些表作为MERGE表自身,不必要在同一个数据库中。
   你可以对表的集合用SELECT, DELETE, UPDATE和INSERT。你必须对你映射到一个MERGE表的这些表有SELECT, UPDATE和DELETE 的权限。
   如果你DROP MERGE表,你仅在移除MERGE规格。底层表没有受影响。
   当你创建一个MERGE表之时,你必须指定一个UNION=(list-of-tables)子句,它说明你要把哪些表当作一个来用。如果你想要对MERGE表的插入发生在UNION列表中的第一个或最后一个表上,你可以选择地指定一个INSERT_METHOD选项。使用FIRST或LAST值使得插入被相应地做在第一或最后一个表上。如果你没有指定INSERT_METHOD选项,或你用一个NO值指定该选项。往MERGE表插入记录的试图导致错误。

下面例子说明如何创建一个MERGE表:
mysql> create table pay_2009 (
    -> id int,
    -> pay_date datetime,
    -> amount decimal(15,3),
    -> key idx_fk_id(id)
    -> ) engine=myisam;
Query OK, 0 rows affected (0.06 sec)

mysql> create table pay_2010 (
    -> id int,
    -> pay_date datetime,
    -> amount decimal(15,3),
    -> key idx_fk_id(id)
    -> ) engine=myisam;
Query OK, 0 rows affected (0.13 sec)

mysql> create table pay_all (
    -> id int,
    -> pay_date datetime,
    -> amount decimal(15,3),
    -> index (id)
    -> ) engine=merge union=(pay_2009,pay_2010) insert_method=first;
Query OK, 0 rows affected (0.09 sec)
mysql> insert into pay_2009 values(1,'2009-09-27',10000),(2,'2009-09-17',20000);
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> insert into pay_2010 values(1,'2010-09-27',10000),(2,'2010-09-17',20000);
Query OK, 2 rows affected (0.02 sec)
Records: 2  Duplicates: 0  Warnings: 0

 

mysql>
注意,一个列在MERGEN表中被索引,但没有被宣告为一个PRIMARY KEY,因为它是在更重要的MyISAM表中。这是必要的,因为MERGE表在更重要的表中的设置上强制非唯一性。

创建MERGE表之后,你可以发出把一组表当作一体来操作的查询:

mysql> select * from pay_2009;
+------+---------------------+-----------+
| id   | pay_date            | amount    |
+------+---------------------+-----------+
|    1 | 2009-09-27 00:00:00 | 10000.000 |
|    2 | 2009-09-17 00:00:00 | 20000.000 |
+------+---------------------+-----------+
2 rows in set (0.00 sec)

mysql> select * from pay_2010;
+------+---------------------+-----------+
| id   | pay_date            | amount    |
+------+---------------------+-----------+
|    1 | 2010-09-27 00:00:00 | 10000.000 |
|    2 | 2010-09-17 00:00:00 | 20000.000 |
+------+---------------------+-----------+
2 rows in set (0.00 sec)

mysql> select * from pay_all;
+------+---------------------+-----------+
| id   | pay_date            | amount    |
+------+---------------------+-----------+
|    1 | 2009-09-27 00:00:00 | 10000.000 |
|    2 | 2009-09-17 00:00:00 | 20000.000 |
|    1 | 2010-09-27 00:00:00 | 10000.000 |
|    2 | 2010-09-17 00:00:00 | 20000.000 |
+------+---------------------+-----------+
4 rows in set (0.00 sec)

mysql> insert into pay_all values(3,'2009-12-02',80000);
Query OK, 1 row affected (0.00 sec)

mysql> select * from pay_2009;
+------+---------------------+-----------+
| id   | pay_date            | amount    |
+------+---------------------+-----------+
|    1 | 2009-09-27 00:00:00 | 10000.000 |
|    2 | 2009-09-17 00:00:00 | 20000.000 |
|    3 | 2009-12-02 00:00:00 | 80000.000 |
+------+---------------------+-----------+
3 rows in set (0.00 sec)

mysql> select * from pay_2010;
+------+---------------------+-----------+
| id   | pay_date            | amount    |
+------+---------------------+-----------+
|    1 | 2010-09-27 00:00:00 | 10000.000 |
|    2 | 2010-09-17 00:00:00 | 20000.000 |
+------+---------------------+-----------+
2 rows in set (0.00 sec)

mysql> select * from pay_all;
+------+---------------------+-----------+
| id   | pay_date            | amount    |
+------+---------------------+-----------+
|    1 | 2009-09-27 00:00:00 | 10000.000 |
|    2 | 2009-09-17 00:00:00 | 20000.000 |
|    3 | 2009-12-02 00:00:00 | 80000.000 |
|    1 | 2010-09-27 00:00:00 | 10000.000 |
|    2 | 2010-09-17 00:00:00 | 20000.000 |
+------+---------------------+-----------+
5 rows in set (0.00 sec)
注意,你也可以直接从MySQL之外直接操作.MRG文件:

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
目录
相关文章
|
存储 关系型数据库 MySQL
【Mysql 学习】 MERGE表方面的问题(二)
shell> cd /mysql-data-directory/current-databaseshell> ls -1 t1 t2 > total.MRGshell> mysqladmin flush-tables要重映射一个MERGE表到一个不同的MyISAM表集,你可以执行下列之一: ·DROP MERGE表并且重建它。
896 0
|
运维 算法 机器人
阿里云AnalyticDB具身智能方案:破解机器人仿真数据、算力与运维之困
本文将介绍阿里云瑶池旗下的云原生数据仓库AnalyticDB MySQL推出的全托管云上仿真解决方案,方案采用云原生架构,为开发者提供从开发环境、仿真计算到数据管理的全链路支持。
|
11月前
|
存储 人工智能 关系型数据库
阿里云AnalyticDB for PostgreSQL 入选VLDB 2025:统一架构破局HTAP,Beam+Laser引擎赋能Data+AI融合新范式
在数据驱动与人工智能深度融合的时代,企业对数据仓库的需求早已超越“查得快”这一基础能力。面对传统数仓挑战,阿里云瑶池数据库AnalyticDB for PostgreSQL(简称ADB-PG)创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系,并自主研发Beam混合存储引擎与Laser向量化执行引擎,全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。 近日,相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025,标志着中国自研云数仓技术再次登上国际舞台。
1208 1
|
10月前
|
存储 人工智能 OLAP
AI Agent越用越笨?阿里云AnalyticDB「AI上下文工程」一招破解!
AI上下文工程是优化大模型交互的系统化框架,通过管理指令、记忆、知识库等上下文要素,解决信息缺失、长度溢出与上下文失效等问题。依托AnalyticDB等技术,实现上下文的采集、存储、组装与调度,提升AI Agent的准确性与协同效率,助力企业构建高效、稳定的智能应用。
|
12月前
|
存储 人工智能 分布式计算
数据不用搬,AI直接炼!阿里云AnalyticDB AI数据湖仓一站式融合AI+BI
阿里云瑶池旗下的云原生数据仓库AnalyticDB MySQL版(以下简称ADB)诞生于高性能实时数仓时代,实现了PB级结构化数据的高效处理和分析。在前几年,为拥抱大数据的浪潮,ADB从传统数仓拓展到数据湖仓,支持Paimon/Iceberg/Delta Lake/Hudi湖格式,为开放的数据湖提供数据库级别的性能、可靠性和管理能力,从而更好地服务以SQL为核心的大规模数据处理和BI分析,奠定了坚实的湖仓一体基础。
|
分布式计算 运维 监控
Fusion 引擎赋能:流利说如何用阿里云 Serverless Spark 实现数仓计算加速
本文介绍了流利说与阿里云合作,利用EMR Serverless Spark优化数据处理的全过程。流利说是科技驱动的教育公司,通过AI技术提升用户英语水平。原有架构存在资源管理、成本和性能等痛点,采用EMR Serverless Spark后,实现弹性资源管理、按需计费及性能优化。方案涵盖数据采集、存储、计算到查询的完整能力,支持多种接入方式与高效调度。迁移后任务耗时减少40%,失败率降低80%,成本下降30%。未来将深化合作,探索更多行业解决方案。
1000 1
|
存储 分布式计算 物联网
美的楼宇科技基于阿里云 EMR Serverless Spark 构建 LakeHouse 湖仓数据平台
美的楼宇科技基于阿里云 EMR Serverless Spark 建设 IoT 数据平台,实现了数据与 AI 技术的有效融合,解决了美的楼宇科技设备数据量庞大且持续增长、数据半结构化、数据价值缺乏深度挖掘的痛点问题。并结合 EMR Serverless StarRocks 搭建了 Lakehouse 平台,最终实现不同场景下整体性能提升50%以上,同时综合成本下降30%。
1231 58
|
SQL 存储 缓存
海量数据分页查询效率低?一文解析阿里云AnalyticDB深分页优化方案
本文介绍了AnalyticDB(简称ADB)针对深分页问题的优化方案。深分页是指从海量数据中获取靠后页码的数据,常导致性能下降。ADB通过快照缓存技术解决此问题:首次查询生成结果集快照并缓存,后续分页请求直接读取缓存数据。该方案在数据导出、全量结果分页展示及业务报表并发控制等场景下表现出色。测试结果显示,相比普通分页查询,开启深分页优化后查询RT提升102倍,CPU使用率显著降低,峰值内存减少至原方案的几分之一。实际应用中,某互联网金融客户典型慢查询从30秒优化至0.5秒,性能提升60+倍。
922 1

热门文章

最新文章