数据库模式与表空间具体区别是啥呢？数据库模式是所有数据的逻辑结构。而表空间存储了所有表数据

一、系统表空间

在 MySQL 数据目录下有一个名为 ibdata1 的文件，可以保存一张或者多张表。

923275 12M -rw-r----- 1 mysql mysql 12M 3月 18 10:42 ibdata1

这个文件就是 MySQL 的系统表空间文件，默认为 1 个，可以有多个，只需要在配置文件 my.cnf 里面这样定义即可。

innodb_data_file_path=ibdata1:200Mibdata2:200M:autoextend:max:800M系统表空间不仅可以是文件系统组成的文件，也可以是非文件系统组成的磁盘块，比如裸设备，定义也很简单innodb_data_file_path=/dev/nvme0n1p1:3Gnewraw/dev/nvme0n1p2:2Gnewraw

系统表空间里都有些啥内容？

具体内容包括：double writer buffer、 change buffer、数据字典（MySQL 8.0 之前）、表数据、表索引。

那 MySQL 为什么现在主流版本默认都不是系统表空间？

究其原因，系统表空间有三个最大的缺点：原因 1：无法做到自动收缩磁盘空间，造成很大的空间浪费。即使它包含的表都被删掉，这部分空间也不会自动释放。

二、单表空间

单表空间不同于系统表空间，每个表空间和表是一一对应的关系，每张表都有自己的表空间。具体在磁盘上表现为后缀为 .ibd 的文件。比如表 t1，对应的表空间文件为 t1.ibd917107 96K -rw-r----- 1 mysql mysql 96K 3月 18 16:13 t1.ibd

单表空间如何应用到具体的表呢？

有两种方式：方式 1：在配置文件中开启。在配置文件中开启单表空间设置参数 innodb_filer_per_table，这样默认对当前库下所有表开启单表空间。innodb_file_per_table=1另外也可以直接建表时指定单表空间mysql>create table t1 (id int, r1 char(36)) tablespace innodb_file_per_table

Query OK, 0 rows affected (0.04 sec)

单表空间除了解决之前说的系统表空间的几个缺点外，还有其他的优点，详细如下：

1. truncate table *** 作比其他的任何表空间都快；

2. 可以把不同的表按照使用场景指定在不同的磁盘目录；

比如日志表放在慢点的磁盘，把需要经常随机读的表放在 SSD 上等。

mysql>create table ytt_dedicated (id int) data directory = '/var/lib/mysql-files'

Query OK, 0 rows affected (0.04 sec)3. 可以用 optimize table 来收缩或者重建经常增删改查的表。一般过程是这样的：建立和原来表一样的表结构和数据文件，把真实数据复制到临时文件，再删掉原始表定义和数据文件，最后把临时文件的名字改为和原始表一样的。

三、通用表空间

通用表空间先是出现在 MySQL Cluster 里，也就是 NDB 引擎。从 MySQL 5.7 引入到 InnoDB 引擎。通用表空间和系统表空间一样，也是共享表空间。每个表空间可以包含一张或者多张表，也就是说通用表空间和表之间是一对多的关系。

表对象缓存： 是将某个表对象的字典信息（定义内容）缓存到内存中，用来提高对表的访问效率。某个表被访问过一次后，只要服务器没有关闭且表定义没有被修改的条件下，访问该表，只需要从内存中找到这个已经缓存起来的对象做相应 *** 作即可。

用户访问表时，表对象在缓存时： 通过HASH算法找到TABLE_SHARE，然后每个线程构造各自的实例化TABLE即可。

用户访问表时，当表没有被缓存的情况下： 第一需要打开表，首先需要从系统表中将这个表的所有信息都读入内存中，这些信息包括表名、库名、所有列信息、列的默认值、表的字符集、对应的frm文件路径、所属存储引擎、主键等，将这些信息构造一个TABLE_SHARE结构体，这个结构体是表对象缓存的第一层，所有用户共享访问且为静态不允许修改，它是缓存在table_def_cache（由参数table_definition_cache控制）中的。

而真正与用户打交道的是TABLE_SHARE的衍生品，它对应结构体为TABLE，在被使用前需要将TABLE_SHARE结构体实例化TABLE才能被使用，由每个线程构造各自的实例化TABLE即可。（实例化的TABLE由table_open_cache及table_open_cache_instance控制）

注意1： DDL *** 作时会将所有instance锁住，而DML *** 作时instance之间互不干扰。

(DDL statements still require a lock on the entire cache, but such statements are much less frequent than DML statements.)

注意2： 一个线程中如果打开表过多，超过一个instance限制的大小时，是不能跨instance缓存的

(instance大小：table_open_cache / table_open_cache_instances)

表缓存涉及其他参数： 通过下面参数判断table_open_cache参数设置是否合理

table_open_cache_hit：能够从table open cache的free list中找到table则为命中，+1

table_open_cache_misses：与table_open_cache_hit相反，如果找不到则需要重新实例化则+1，通常发生在初始化第一次加载表或超过table_open_cache的设置被淘汰后需要重新实例化。

table_open_cache_overflow：table cache淘汰的数量，每次淘汰+1

opened_tables:已经打开的表数。如果Opened_tables很大，那么table_open_cache的值可能太小了。

open_tables：总的instance (table cache)的总数

---