MySQL 表空间可分为共享表空间和单表空间；其中共享表空间又可分为系统表空间和通用表空间。
爱可生华东交付部 DBA，主要负责 MySQL 日常问题处理及 DMP 产品支持。爱好跳舞，追剧。
Mysql最常用的三种备份工具分别是mysqldump、Xtrabackup（innobackupex工具）、lvm-snapshot快照。 前面分别介绍了： Mysql备份系列（1）--备份方案总结性梳理 Mysql备份系列（2）--mysqldump备份（全量+增量）方案操作记录 Mysql备份系列（3）--innobackupex备份mysql大数据(全量+增量）操作记录 lvm-snapshot：基于LVM快照的备份 1.关于快照： 1）事务日志跟数据文件必须在同一个卷上； 2）刚刚创立的快照卷，里
ERROR 1146 (42S02): Table ‘xxx’ doesn’t exist 可能是很多人都遇到的问题，尤其在数据库迁移或备份的时候
共享表空间: 某一个数据库的所有的表数据，索引文件全部放在一个文件中，默认这个共享表空间的文件路径在data目录下。 默认的文件名为:ibdata1 初始化为10M。
目的：主机系统/var目录快满了，经查询最大的文件是mysql的ibdata1文件，有17G大小，故需要迁移这个文件到其他目录下，以释放/var目录空间。
故事情节：我的阿里云服务器突然被黑客攻击了，整个系统down了。 找客服，他们排查说usr目录的文件全部丢失。让我重新初始化系统盘。初始化之前先生成一个快照。还好生成了快照，让事情没有发展为不可挽救的地步。
在测试环境下没有设置过多的详细参数就初始化并启动了服务，后期优化的过程中发现innodb_data_file_path设置过小：
主要也是参考下面链接最终成功恢复。 这篇文章的步骤稍微有点多。有些是恢复不必要的，这里做一下自己的整理。
本人遇到一次在安装zabbix监控的时候，yum安装的MySQL数据库，后面用了一段时间发现data目录下的ibdata1的空间特别大，反而我的zabbix数据库的空间很小，这样的情况在后面备份zabbix数据库的时候会很不方便，所以想着要怎么解决下。 ibdata1文件是什么？
读取顺序：/etc/mysql/my.cnf>/etc/my.cnf>~/.my.cnf
之前用kill的方法杀掉了一个MySQL的进程，今天想要重启这个进程，启动的过程中，发现
MySQL 5.6中开始支持把undo log分离到独立的表空间，并放到单独的文件目录下；这给我们部署不同IO类型的文件位置带来便利，对于并发写入型负载，我们可以把undo文件部署到单独的高速存储设备上。增加了如下几个参数来控制该行为。
摘自https://www.rathishkumar.in/2016/04/understanding-mysql-architecture.html
今天我们的zabbix-server机器根空间不够了，我一步步排查结果发现是/var/lib/mysql/下的libdata1文件过大，已经达到了41G。我立即想到了zabbix的数据库原因，随后百度、谷歌才知道zabbix的数据库他的表模式是共享表空间模式，随着数据增长，ibdata1 越来越大，性能方面会有影响，而且innodb把数据和索引都放在ibdata1下。
简介： 1.后缀名为.frm的文件：这个文件主要是用来描述数据表结构和字段长度灯信息 2.后缀名为.ibd的文件：这个文件主要储存的是采用独立表储存模式时储存数据库的数据信息和索引信息； 3.后缀名为.MYD（MYData）的文件：从名字可以看出，这个是存储数据库数据信息的文件，主要是存储采用独立表储存模式时存储的数据信息； 4.后缀名为.MYI的文件：这个文件主要储存的是数据库的索引信息； 5.ibdata1文件:主要作用也是储存数据信息和索引信息
innodb_ruby是jeremycole的一个用于分析Innodb相关结构的一个程序，也是非常方便我们研究Innodb的结构的工具。 1. 工具安装
操作系统版本：CentOS Linux release 7.6.1810 (Core)，默认的yum源安装后ruby的版本是2.0 ,而innodb_ruby需要2.2及以上版本，因此修改yum源，再安装指定高版本
最近因为电脑重装了系统，导致自己原本的数据库呗覆盖，需要重新重新安装数据库，但是由于我之前数据库版本是mysql 5.0.22，版本太低，所以小编决定安装mysql 5.7.23版本的，一开始没什么问题，根据之前的安装路径安装成功后，接着配置了mysql的环境变量mysql_path，，然后在数据库编辑工具Navicat for MySQL打开后，进行了一个小小的数据库查询：select * from user；回车之后发现报错：[Err] 1146 – Table ‘performance_schema.session_status’ doesn’t exist
说起来日常的故障，其实，首先应该相到的就是：“备份”、“备份”、“备份”。毕竟再怎么牢固的系统或硬件都会有故障的时候，所以，备份放第一位。
innodb_space 的git网址：https://github.com/jeremycole...
无论何种存储引擎（InnoDB、MyISAM、MEMORY...），只要创建了表结构就会在磁盘上创建一个frm文件，文件名为：表名.frm
如果 SQL 在执行过程中读到的数据无法直接得到结果，那么就需要额外的内存来保存中间结果，得出最终结果，这个额外的内存就是内部临时表。比如 group by 执行时，就需要构建一个临时表，需要额外的字段保存聚合函数的结果，当然为了防止内存使用过大，一般超出某个限制后就会放到磁盘上。关于哪些操作会产生内部临时表，可以查看官方文档：https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html，下面主要介绍 MySQL 8.0 内部临时表存放方式的变化。
我们知道，磁盘和内存之间的数据交换是通过数据页来实现的，而最小的数据页的大小是16KB，表空间是用来存储数据页的一个池子，下面我们来说说表空间的概念。
与InnoDb存储引擎密切相关的文件包括重做日志文件和表空间文件，首先来说说我对表空间文件的理解。表空间文件是用来存储表信息和表数据的，它默认的大小是10MB,名称为ibdata1，如下面代码的第10行所示（代码可以左滑）：
今天启动mysql又一次报错：The server quit without updating PID file！记得上次出现这个问题的时候，尝试了一些常规的方法，未果，所以索性重新进行安装。但是，相同的问题今天又出现了！！！OH， my god！恰巧今天时间充裕，尝试各种办法，终于皇天不负有心人，经过一个小时的奋战后，终于让我给搞定，整个过程是这样的！
作为linux运维，多多少少会碰见这样那样的问题或故障，从中总结经验，查找问题，汇总并分析故障的原因，这是一个Linux运维工程师良好的习惯。每一次技术的突破，都经历着苦闷，伴随着快乐，可我们还是执着的继续努力，从中也积累了更多的经验，这就是实践给予我们的丰厚回报。 下面汇总了我做项目过程可能出现的故障及解决方法，看看是否与你有共鸣，并对你有帮助？ ---- 第一：常见问题解决集锦 1.shell脚本不执行 问题：某天研发某同事找我说帮他看看他写的shell脚本，死活不执行，报错。我看了下，
作为运维，多多少少会碰见这样那样的问题或故障，从中总结经验，查找问题，汇总并分析故障的原因，这是一个运维工程师良好的习惯。每一次技术的突破，都经历着苦闷，伴随着快乐，可我们还是执着的继续努力，从中也积累了更多的经验，这就是实践给予我们的丰厚回报。
问题：将A服务器下的Mysql data备份数据复制到B服务器下的Mysql data，打开表示报错：1146错误
作者简介：姚远，MySQL ACE，华为云 MVP ，专注于 Oracle、MySQL 数据库多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。现在鼎甲科技任技术顾问，为同事和客户提供数据库培训和技术支持服务。
MySQL存储引擎介绍 文件系统 操作系统组织和存取数据的一种机制。 文件系统是一种软件。 文件系统类型 ext2 ext3 ext4 xfs 数据 不管使用什么文件系统，数据内容不会变化 不同的是，存储空间、大小、速度 MySQL引擎 可以将MySQL引擎理解为：MySQL的“文件系统”，只不过功能更加强大。 MySQL引擎的功能 除了可以提供基本的存取功能，还有更多功能事务功能、锁定、备份和恢复、优化以及特殊功能。 MySQL 提供以下存储引擎： – InnoDB – MyISAM – MEMOR
再次尝试备份master数据库 [root@master-qa ~]# /usr/bin/innobackupex --defaults-file=/etc/my.cnf --user=root --password=xxxxxxx /data/fullbackup/ InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2
chown -R mysql.mysql /application/mysql-5.6.38/
ib_logfile0和ib_logfile1被覆盖但是mysql还在正常运行，复现问题记录排查流程，涉及文件系统的一些知识点。
背景： centos7.0版本，安装的是mysql5.6版本 问题： 在安装好mysql，并设置开机启动，但是在关机重启后，会发现Mysql服务无法启动 [root@hf-01 ~]# ps aux |grep mysql root 2329 0.0 0.0 112676 984 pts/0 R+ 17:05 0:00 grep --color=auto mysq [root@hf-01 ~]# service mysqld start Starting MySQL. E
最近一个安装宝塔环境的项目，mysql老是关闭停止了。连续好多次了，然后我就发现不对劲。然后去查了下日志，日志内容：
https://github.com/jeremycole/innodb_ruby
「MySQL存储引擎最大的特点就是【插件化】，可以根据自己的需求使用不同的存储引擎，innodb存储引擎支持行级锁以及事务特性，也是多种场合使用较多的存储引擎。」
最近遇到一个MySQL数据导入时候遇到问题，先来看下问题产生的具体报错信息如下所示：
早些年的MYSQL 版本大多没有那么多想法，能装上，一堆的数据库文件，都在一个ibdata1 文件的例子并不少见，可能现在想想好可怕，要是万一坏了，不想在想下去了。
续 lvm-snapshot：基于LVM快照的备份之准备工作 http://www.linuxidc.com/Linux/2014-05/101308.htm
电脑重装系统后把原来的mysql data复制进去后大部分表是可以访问的，但是有几个表提示表不存在：
表的存储会出现碎片化，每当删除了一行内容，该段空间就会变为被留空，而在一段时间内的大量删除操作，会使这种留空的空间变得比存储列表内容所使用的空间更大。
修改 innodb_data_file_path 选项值可自定义InnoDB系统表空间设置，不过要注意 autoextend 和 max 属性只能放在最后一个文件，而不能放在前面的文件。
MySQL从5.5版本开始将InnoDB作为默认存储引擎，该存储引擎是第一个完整支持事务ACID特性的存储引擎，且支持数据行锁，多版本并发控制（MVCC），外键，以及一致性非锁定读。 作为默认存储引擎，也就意味着默认创建的表都会使用此存储引擎，除非 使用ENGINE=参数指定创建其他存储引擎的表。
对于商业数据库而言，数据库升级是一个优先级很高的事情，有版本升级路线图，有相应的补丁，而且对于方案还有一系列的演练，显然是一场硬仗。而在MySQL方向上，升级这件事情就被淡化了许多，好像只能证明它的存在而已，当然正是由于这种不重视，也让我今天走了不少弯路。
这应该是 MySQL 原理中最底层的部分了，我们存在 MySQL 中的数据，到底在磁盘上长啥样。你可能会说，数据不都存储在聚簇索引中吗？但很遗憾，你并没有回答我的问题。我会再问你，那聚簇索引在磁盘上又长啥样？
任何一个技术都有其底层的关键基础技术，这些关键技术很有可能也是其他技术的关键技术，学习这些底层技术，就可以一通百通，让你很快的掌握其他技术。如何在磁盘上存储数据，如何使用日志文件保证数据不丢失以及如何落盘，不仅是MySQL等数据库的关键技术，也是MQ消息队列或者其他中间件的关键技术之一。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
