版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
作为MySQL DBA，在日常运维过程中，经常需要对某张表进行备份恢复。单个表常用的数据备份方法有下面几种：
上述单表物理复制的方法，核心在于cp命令，因为是通过物理拷贝，所以如果复制的表非常大，那么通过物理拷贝，就会比逻辑上的SQL写入快很多，比如insert into select语句。
1. 背景 在使用MySQL时，如果有大表的存储引擎是InnoDB，并且系统参数innodb_file_per_table设置为1，即每个文件对应一个独立的表空间，当对这些大表进行DROP TABLE时，有时会发现整个数据库系统的性能会有显著下降，包括一些只涉及几行数据的简单SELECT查询和DML语句，而且这些语句和正在删除的大表没有关系。造成这种现象的原因是什么呢？通过什么方式能缓解和避免这个问题呢？ 2. 已知的瓶颈 Percona曾经在MySQL官方5.5.23之前的版本中遇到过这个问题，并且提供
本文介绍了MySQL DROP TABLE操作可能存在的性能瓶颈，包括InnoDB引擎表、MyISAM引擎表、以及操作系统层面的限制。针对这些瓶颈，本文提出了相应的优化方案，包括增大InnoDB缓冲池、使用MyISAM存储引擎、以及调整操作系统相关参数。通过这些优化方案，可以有效地提升MySQL数据库的性能，减少DROP TABLE操作对数据库性能的影响。
这个时候所有的mysql的相关进程都会停止，直到drop结束，mysql才会恢复执行。出现这个情况的原因就是因为，在drop table的时候，innodb维护了一个全局锁，drop完毕锁就释放了。
前段时间，客户反馈 Zabbix 实例的 history_str 表数据量很大，导致磁盘空间使用率较高，想要清理该表，咨询是否有好的建议。想着正好最近学习了相关的知识点，正好可以检验一下学习成果，经过实践的检验，最终考试合格，客户也比较满意，于是便有了此文。
Xtrabackup是Percona公司开发的一款开源的MySQL热备份工具，之前的工作中也是经常使用，但是也仅仅是停留在使用的阶段，对于这个工具的细节，并没有做过多的研究，今天细细看了一下过程，还是有点收获的，写下来记录一下，有不对的地方，还请指正。
背景 MySQL 8.0 DDL 是一个复杂的过程，涉及比较多的模块，例如：MDL 锁，表定义缓存，行格式，Row Log，DDL Log，online 属性，表空间物理文件操作等。本文主要通过与5.
备份InnoDB的表时，可以使用可移动表空间执行部分备份，可以备份单独的表，也可以备份具有相同业务功能的多个表。
MySQL 5.6中开始支持把undo log分离到独立的表空间，并放到单独的文件目录下；这给我们部署不同IO类型的文件位置带来便利，对于并发写入型负载，我们可以把undo文件部署到单独的高速存储设备上。增加了如下几个参数来控制该行为。
要是问大家，知道怎么从mysql数据库中drop掉业务表，很多人肯定会说，so easy，用drop table t_test语句不就完事了，这是初生牛犊不怕虎，你要是如此简单，去线上业务库中drop掉一张1TB大小的表，造成长时间的业务无法访问数据库，更严重，导致数据库崩溃，宕机都是可能的。
MySQL 表空间可分为共享表空间和单表空间；其中共享表空间又可分为系统表空间和通用表空间。
爱可生 DBA 团队成员，主要负责 MySQL 故障处理和 SQL 审核优化。对技术执着，为客户负责。
所以整体使用逻辑备份(mysqldump), 个别大表使用物理备份(导出表空间)
Percona XtraBackup[1]（简称PXB）是 Percona 公司开发的一个用于 MySQL 数据库「物理热备」的备份工具，支持 MySQl（Oracle）、Percona Server 和 MariaDB，并且全部开源，真可谓是业界良心。我们 RDS MySQL 的物理备份就是基于这个工具做的。
上一篇已经，针对XTRABACKUP 的在版本上的问题，导致在使用较新版本的MYSQL上，只能使用mysqlbakcup. 到底mysqlbakcup 是一个什么样的企业级别的工具。今天我们就看看他有什么样的功能。
在MySQL中，存在各种各样的临时文件，其存放位置是五花八门，且不同版本也不尽相同，主要包括以下：
2.此时不要关闭mysql服务，查询到mysql的句柄号，通过句柄号恢复ibd文件
说过很多次，不要拘泥于某一个技术的一点，技术是相通的。重要的是编程思想，思想是最重要的。当数据量大的时候，需要具有分的思想去细化粒度。当数据量太碎片的时候，需要具有合的思想来粗化粒度。
无论何种存储引擎（InnoDB、MyISAM、MEMORY...），只要创建了表结构就会在磁盘上创建一个frm文件，文件名为：表名.frm
https://github.com/xelabs/tokudb-xtrabackup/wiki/How-to-build
这条命令是查询自"/"根目录下所有大小超过1G的文件，查询的大小可以根据需要改变，如下：
本来准备做二级分区的DDL的, 但是看了下, WC, 太复杂了. 而且分区表用得也不多. 还不如更新支持 mysql5.7
对于千万级的表数据存储，删除大量记录后，表文件大小并没有随之变小。好奇怪，是什么原因导致的？不要着急，接下来，我们来深入剖析其中原因
爱可生 DBA 团队成员，负责项目中数据库故障与平台问题解决，对数据库高可用与分布式技术情有独钟。
线上的MySQL实例在使用时间长了之后，会保存很多的业务数据，通常情况下，磁盘使用量也会随着业务的接入时间上升。
ibd2sql是解析mysql 8.0的ibd文件, 并生成DDL和DML, 还支持解析出被删除的数据(当然也可以解析binlog来实现)
需求 有时候又删除大表的需求, 一般直接drop就行, 但有时候会有IO的问题. 什么叫大表呢? 没得明确的定义, 本文的演示环境使用 15000W的数据做演示 (sysbench创建的) 实现和演示
MySQL数据库中进行表空间整理，可以用的一种操作就是optimize table，
对于 MySQL 5.7 的数据恢复,我们可以借助 dbsake 和 ibd2sql 这两个强大的工具来完成。这个方法不仅可以恢复表结构,还能恢复数据,是一个相当完整的解决方案。下面是详细步骤:
如果Mysql服务无法启动，则可以通过Mysql表对应的.ibd文件恢复数据，如果你的Mysql服务可以正常启动，就不要使用这种方式了
「MySQL存储引擎最大的特点就是【插件化】，可以根据自己的需求使用不同的存储引擎，innodb存储引擎支持行级锁以及事务特性，也是多种场合使用较多的存储引擎。」
mysql> alter table skatetab add unique index(id, uid), drop primary key, add primary key(uid, id);
硬盘空间满导致mysql ibd文件被删后提示Tablespace is missing for table ‘db_rsk/XXX“ 昨天一早，开发人员反馈说一个测试环境报Tablespace is missing for table ‘db_rsk/XXX“，周末刚升级过，特地让开发回去查了下，说脚本中肯定没有drop table的操作。datadir下检查了下，发现frm文件在的ibd文件没有了，bing了下，没发现类似异常。于是先回到mysql.err往回搜索，半天后发现上周五下午mysql出现了一
我们都知道MySQL 的复制技术，通过主从同步可以实现读写分离，热备份，让服务器更加高可用。MySQL 的复制主要是通过 Binlog 来完成的，Binlog 记录了数据库更新的事件，从库 I/O 线程会向主库发送 Binlog 更新的请求，同时主库二进制转储线程会发送 Binlog 给从库作为中继日志进行保存，然后从库会通过中继日志重放，完成数据库的同步更新
上面我们介绍了什么是存储引擎，以及如何在建表时如何指定存储引擎，接下来我们就来介绍下来上面
MySQL里面对于表的默认的配置是每个表都有独立的文件.ibd和.frm文件对应，对于数据恢复来说，会提供很大的便利。
在MySQL中，如果我们使用了默认的存储引擎innodb创建一张表，那么在文件夹下面就会出现表名.frm和表名.ibd两个文件，如果我们使用的是Myisam存储引擎，那么就会出现三个文件，这里我们给出例子：
作者简介 肖鹏 微博研发中心数据库技术负责人，主要负责微博数据库（MySQL/Reids/HBase/Memcached）相关的业务保障，性能优化，架构设计以及周边的自动化系统建设。10年互联网数据库
不小心删除了mysql数据目录, 但还剩个.ibd文件在. 没得备份, 没得binlog , 要恢复这个ibd文件里面的数据.
巡检时发现服务器磁盘空间不足，通过查看大文件进行筛选是发现有几个#sql开头的文件,且存在超过100G及10G以上的文件。
经过分析发现，报错信息中的数据库，所有表名都混用了大小写字母，因为创建表之后，系统变量 lower_case_table_names 的值被从 0 修改为 1，导致删除这个数据库时，每个表的 ibd 文件删除成功，frm 文件删除失败。
这应该是 MySQL 原理中最底层的部分了，我们存在 MySQL 中的数据，到底在磁盘上长啥样。你可能会说，数据不都存储在聚簇索引中吗？但很遗憾，你并没有回答我的问题。我会再问你，那聚簇索引在磁盘上又长啥样？
我在研究 《xtrabackup 原理图》的时候，想通过观察确认 xtrabackup_log 是最早创建 并且是 最晚保存的文件。我们就需要知道 xtrabackup_logfile 这个文件的创建时间戳和修改时间戳。
我在上一篇文章最后，给你留下的问题是怎么在两张表中拷贝数据。如果可以控制对源表的扫描行数和加锁范围很小的话，我们简单地使用 insert … select 语句即可实现。
俗话说”常在河边走，哪有不湿鞋”。在DBA的实际运维过程中经常会遇到误删除、改错数据的情况。遇到这种情况我们除了跑路还能怎么办？我们又怎么能做到有备无患呢？我计划用三章的时间和大家聊聊数据库的备份和恢复工具xtrabackup、mysqldump以及闪回工具binlog2sql，今天先介绍下xtrabackup的原理以及使用方法。
文件中存放的是frm对应表结构的sql，直接复制出来运行就行了，此时数据库中所有的结构都恢复了，就是还没有数据
当然整理的过程不光是知识梳理的过程，也是转化为实践场景的一个过程，通过这样一个体系，对于整个MySQL对象生命周期管理有了较为深入的认识，这里我来抛砖引玉，来作为深入学习MySQL数据字典的一个入口，这个问题就是：如何较为准确的计算MySQL碎片情况？
简介： 1.后缀名为.frm的文件：这个文件主要是用来描述数据表结构和字段长度灯信息 2.后缀名为.ibd的文件：这个文件主要储存的是采用独立表储存模式时储存数据库的数据信息和索引信息； 3.后缀名为.MYD（MYData）的文件：从名字可以看出，这个是存储数据库数据信息的文件，主要是存储采用独立表储存模式时存储的数据信息； 4.后缀名为.MYI的文件：这个文件主要储存的是数据库的索引信息； 5.ibdata1文件:主要作用也是储存数据信息和索引信息
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
腾讯会议
