Innodb笔记

最新推荐文章于 2023-07-04 17:37:40 发布

Kin神

最新推荐文章于 2023-07-04 17:37:40 发布

阅读量640

点赞数

分类专栏：数据库文章标签：数据库架构

本文链接：https://blog.csdn.net/kinsxkins/article/details/124004719

版权

InnoDB

遗留问题：表空间、段、区、索引的关系？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KtbFBNxy-1649291208567)(mysql-innodb-架构2.png)]

1. 后台线程 BACKGROUND THREAD

Master Thread: 主要负责将缓冲池中的数据异步刷新到磁盘
IO Thread: 负责AIO（Async IO）回调处理
Purge Thread: 回收已经使用并分配的undo页。
Page Cleaner Thread: 脏页的刷新

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0zruQ6EQ-1649291208568)(…/images/2018010810173533.jpg)]

2. 内存结构

缓冲池 innodb_buffer pool

1.1 数据页 data page

1.2 索引页 index page

1.3 插入缓冲 insert buffer（现在叫 Change Buffer）

1.4 锁信息 lock info

1.5 自适应哈希索引 adaptive hash index

1.6 数据字典信息

1.7 undo页?
redo日志缓冲 redo log_buffer
额外内存池 innodb_additional_mem_pool_size
双写Double Write？

innodb buffer pool和query cache的缓存区别?

1、query cache 缓存的是SQL语句及对应的结果集,缓存在内存,最简单的情况是SQL一直不重复,那Qcache的命令率肯定是0;

2、buffer pool中缓存的是整张表中的数据,缓存在内存,SQL再变只要数据都在内存,那么命中率就是100%。

MySQL8.0不再提供对查询缓存的支持

查询缓存的效果取决于缓存的命中率，只有命中缓存的查询效果才能有改善，因此无法预测其性能。

查询缓存的另一个大问题是它受到单个互斥锁的保护。在具有多个内核的服务器上，大量查询会导致大量的互斥锁争用。

研究表明，缓存越靠近客户端，获得的好处越大。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WtmB7REC-1649291208569)(C:\kin\work\notes\数据库\images\innodb-architecture.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wa8btDyR-1649291208569)(C:\kin\work\notes\数据库\images\image-20220208232332649.png)]

缓冲池管理

LRU List（Database pages ）：当数据库刚启动时，LRU列表是空的，即没有任何的页
Free List（Free buffers ）：当数据库刚启动时页都存放在Free列表中，当需要从缓冲池中分页时，首先从Free列表中查找是否有可用的空闲页，若有则将该页从Free列表中删除，放入到LRU列表中。
Flush List （Modified db pages）：Flush列表中的页即为脏页列表。脏页既存在于LRU列表中，也存在于Flush列表中。LRU列表用来管理缓冲池中页的可用性，Flush列表用来管理将页刷新回磁盘，二者互不影响。

自适应哈希索引、Lock信息、Insert Buffer等页，不存在于LRU列表中

mysql> SHOW ENGINE INNODB STATUS;
...
Buffer pool size   131062
Free buffers       129902
Database pages     1154
Old database pages 0
Modified db pages  0
...

Checkpoint 检查点

思路：

性能：不用每次页变化都刷新到磁盘
不丢数据：从缓冲池刷新到磁盘时宕机，数据会丢失，所以采用**Write Ahead Log(WAL)**策略，即当事务提交时，先写Redo日志，再修改页。满足事务ACID中D（Durability持久性）要求。
深度思考：假如全部数据存缓冲区，不刷新磁盘，则要满足：

1）内存要足够大

2）为了数据不丢失，redo日志空间足够大，宕机时可以恢复到缓存区

3）从redo日志恢复时间要足够快

CheckPoint 解决的问题

缩短数据库的恢复时间；（Checkpoint之前的页都已经刷新回磁盘）
缓冲池不够用时，将脏页刷新到磁盘；

LRU算法会溢出最近最少使用的页，若此页为脏页，那么需要强制执行Checkpoint，将脏页也就是页的新版本刷回磁盘。
Redo日志不可用时，刷新脏页。

LSN（Log Sequence Number）日志序号

InnoDB存储引擎而言，其是通过LSN（Log Sequence Number）来标记版本的。而LSN是8字节的数字，即64位，其单位是字节。

每个页有LSN，redo日志中也有LSN，Checkpoint也有LSN。可以通过命令SHOW ENGINE INNODB STATUS来观察

...
---
LOG
---
Log sequence number          317320569
Log buffer assigned up to    317320569
Log buffer completed up to   317320569
Log written up to            317320458
Log flushed up to            317320458
Added dirty pages up to      317320569
Pages flushed up to          317319258
Last checkpoint at           317319258
40 log i/o''s done, 0.04 log i/o''s/second
...

Checkpoint发生时机

在InnoDB存储引擎中，Checkpoint发生的时间、条件及脏页的选择等都非常复杂。

Sharp Checkpoint: 数据库关闭时将所有的脏页都刷新回磁盘，这是默认的工作方式，即参数innodb_fast_shutdown=1。（Sharp可翻译为鲜明的、急剧地）
Fuzzy Checkpoint：只刷新一部分脏页，而不是刷新所有的脏页回磁盘。

❑Master Thread Checkpoint：每秒或每十秒从缓冲池的脏页列表中刷新一定比例的页回磁盘。这个过程是异步的，用户查询线程不会阻塞
❑FLUSH_LRU_LIST Checkpoint：innodb需要保证LRU列表有约100个空闲页可供使用，不足则将LRU列表尾端的页移除，当移除的页为脏页，需要进行Checkpoint。（可通过参数innodb_lru_scan_depth控制LRU列表中可用页的数量，该值默认为1024）

InnoDB1.1.x版本之前，需要检查LRU列表中是否有足够的可用空间，此操作发生在用户查询线程中，会阻塞用户的查询操作

InnoDB1.2.x版本开始，即MySQL 5.6版本开始，这个检查被放在了一个单独的Page Cleaner线程中进行。

❑Async/Sync Flush Checkpoint：指的是重做日志文件不可用的情况，这时需要强制将一些页刷新回磁盘，而此时脏页是从脏页列表中选取的。
❑Dirty Page too much Checkpoint：脏页的数量太多，导致InnoDB存储引擎强制进行Checkpoint。

innodb_max_dirty_pages_pct控制，单位为%

mysql> SHOW VARIABLES LIKE'innodb_max_dirty_pages_pct';

+----------------------------+-----------+
| Variable_name              | Value     |
+----------------------------+-----------+
| innodb_max_dirty_pages_pct | 90.000000 |
+----------------------------+-----------+

Master Thread工作方式

Master Thread具有最高的线程优先级别。其内部由多个循环（loop）组成：主循环（loop）、后台循环（backgroup loop）、刷新循环（flush loop）、暂停循环（suspend loop）。根据数据库运行的状态在loop、background loop、flush loop和suspendloop中进行切换

InnoDB 1.0.x版本之前的Master Thread

loop循环通过thread sleep，约每秒执行一次。

每秒一次的操作包括：
❑日志缓冲刷新到磁盘，即使这个事务还没有提交（总是）；–》这就是为什么再大的事务提交（commit）的时间也是很短的。
❑合并插入缓冲（可能）：前一秒内发生的IO次数是否小于5次，前一秒内发生的IO次数是否小于5次
❑至多刷新100个InnoDB的缓冲池中的脏页到磁盘（可能）：当前缓冲池中脏页的比例是否超过阈值（默认90%），将100个脏页写入磁盘中；
❑如果当前没有用户活动或者关闭时，则切换到background loop（可能）

while(true){

for(int i=0;i<10; i++){
    sleep 1s;
    // 每1秒操作
}

// 每10秒操作

}


2. 每10秒的操作，包括如下内容：

❑刷新100个脏页到磁盘（可能的情况下）；
❑合并至多5个插入缓冲（总是）；
❑将日志缓冲刷新到磁盘（总是）；
❑删除无用的Undo页（总是）；
❑刷新100个或者10个脏页到磁盘（总是）。

3. background loop操作

❑删除无用的Undo页（总是）；
❑合并20个插入缓冲（总是）；
❑跳回到主循环（总是）；
❑不断刷新100个页直到符合条件（可能）（跳转到flush loop中完成）。

若flush loop中也没有什么事情可以做了，InnoDB存储引擎会切换到suspend__loop，将Master Thread挂起。

#### InnoDB 1.2.x版本之前的Master Thread

>  以前为硬编码，InnoDB存储引擎最大只会刷新100个脏页到磁盘，合并20个插入缓冲

1. InnoDB Plugin（从InnoDB1.0.x版本开始）提供了参数innodb_io_capacity，用来表示磁盘IO的吞吐量，默认值为200；

2. 在合并插入缓冲时，合并插入缓冲的数量为innodb_io_capacity值的5%；

3. 在从缓冲区刷新脏页时，刷新脏页的数量为innodb_io_capacity；

4. buf_flush_get_desired_flush_rate通过判断产生重做日志（redo log）的速度来决定最合适的刷新脏页数量。因此，当脏页的比例小于innodb_max_dirty_pages_pct时，也会刷新一定量的脏页。

5. 参数innodb_purge_batch_size，该参数可以控制每次full purge回收的Undo页的数量。该参数的默认值为20，并可以动态修改。

6. InnoDB对其内部进行了一些优化，**当压力大时并不总是等待1秒**，1_second和sleeps的值不一定相等，**sleeps远小于1_second时，说明负载压力较大。**

#### InnoDB 1.2.x版本的Master Thread

1. 活动时进行之前1秒的操作，空闲时进行之前10秒的操作。
2. 单独的Page Cleaner Thread进行刷新脏页操作，从而减轻Master Thread压力。



## 3. InnoDB关键特性

InnoDB存储引擎的关键特性包括：
❑插入缓冲（Insert Buffer）
❑两次写（Double Write）
❑自适应哈希索引（Adaptive Hash Index）
❑异步IO（Async IO）
❑刷新邻接页（Flush Neighbor Page）
上述这些特性为InnoDB存储引擎带来更好的性能以及更高的可靠性。



### Insert Buffer （Change Buffer）

1. 聚集索引（Primary Key）一般是顺序的，不需要磁盘的随机读取。若主键类是UUID这样的类，那么插入和辅助索引一样，同样是随机的。非聚集的辅助索引（secondary index）
2. IBUF_POOL_SIZE_PER_MAX_SIZE=2，Insert Buffer默认最大可以占用到1/2的缓冲池内存（innodb_buffer_pool）。IBUF_POOL_SIZE_PER_MAX_SIZE是代码的变量，不是参数，只能改代码。
3. InnoDB从1.0.x版本开始引入了**Change Buffer**，可将其视为Insert Buffer的升级。他们分别是：Insert Buffer、Delete Buffer、Purge buffer。和之前Insert Buffer一样，Change Buffer适用的对象依然是非唯一的辅助索引。
4. 从InnoDB 1.2.x版本开始，可以通过参数innodb_change_buffer_max_size来控制Change Buffer最大使用内存的数量



InnoDB存储引擎开创性地设计了Insert Buffer，对于**非聚集索引**的插入或更新操作，不是每一次直接插入到索引页中，而是**先判断插入的非聚集索引页是否在缓冲池中，若在，则直接插入；若不在，则先放入到一个Insert Buffer对象**。

Insert Buffer的使用需要同时满足以下两个条件：
❑索引是辅助索引（secondary index）；
❑索引不是唯一（unique）的。

> 考虑这样一种情况：应用程序进行大量的插入操作，这些都涉及了不唯一的非聚集索引，也就是使用了Insert Buffer。若此时MySQL数据库发生了宕机，这时势必有大量的Insert Buffer并没有合并到实际的非聚集索引中去。因此这时恢复可能需要很长的时间，在极端情况下甚至需要几个小时。

*辅助索引不能是唯一的，因为在插入缓冲时，数据库并不去查找索引页来判断插入的记录的唯一性。如果去查找肯定又会有离散读取的情况发生，从而导致Insert Buffer失去了意义*



### 两次写 DoubleWrite (DoubleWrite Buffer)

目的：

提高可靠性。比如16KB的页，只写了前4KB，之后就发生了宕机，这种情况被称为部分写失效（partial page write）。

如果这个页本身已经发生了损坏，在应用（apply）重做日志前，用户需要一个页的副本，当写入失效发生时，先通过页的副本来还原该页，再进行重做。

原理：

1. memcpy函数将脏页（2M，128页，两个区extent）先复制到内存中的doublewrite buffer

2. doublewrite buffer再分两次，每次**1MB**写入**共享表空间**的物理磁盘上，doublewrite页是连续的，这个过程是**顺序写**，开销较小。

3. 在完成doublewrite页的写入后，再将doublewrite buffer中的页**写入各个表空间文件中**，此时的写入则是**离散的**。

注意：有些文件系统本身就提供了部分写失效的防范机制，如ZFS文件系统。在这种情况下，用户就不要启用doublewrite了

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2Vr9ROuS-1649291208569)(C:\kin\work\notes\数据库\images\doubleWrite.png)]



### 异步IO（Asynchronous IO，AIO）

1. 用户可以在**发出一个IO请求后立即再发出另一个**IO请求，当全部IO请求**发送完毕**后，**等待所有IO操作的完成**，这就是AIO。

2. AIO的另一个优势是可以进行IO Merge操作，也就是将**多个IO合并为1个IO，**这样可以**提高IOPS**的性能。

### 刷新邻接页 Flush Neighbor Page

1. 当刷新一个脏页时，InnoDB存储引擎会检测该页所在区（extent）的所有页，如果是脏页，那么一起进行刷新。

2. InnoDB存储引擎从1.2.x版本开始提供了参数innodb_flush_neighbors，用来控制是否启用该特性。对于传统机械硬盘建议启用该特性，而对于固态硬盘有着超高IOPS性能的磁盘，则建议将该参数设置为0，即关闭此特性。

### 启动、关闭与恢复

1. 参数**innodb_fast_shutdown**

0：完成所有数据刷新到磁盘。有时甚至需要几个小时。如果在进行InnoDB升级时，必须将这个参数调为0，然后再关闭数据库。

1（默认）：数据脏页会刷新回磁盘。不进行full purge和merge insert buffer操作。

2：仅将日志都写入日志文件。不会丢失数据，下次MySQL数据库启动时，会进行恢复操作（recovery）。

2. 参数**innodb_force_recovery** （大的数字表示**包含了前面所有小数字**表示的影响）

❑0：当发生需要恢复时，进行所有的恢复操作，当不能进行有效恢复时。如数据页发生了corruption，MySQL数据库可能发生宕机（crash），并把错误写入错误日志中去。

❑1(SRV_FORCE_IGNORE_CORRUPT)：忽略检查到的corrupt页。
❑2(SRV_FORCE_NO_BACKGROUND)：阻止Master Thread线程的运行，如Master Thread线程需要进行full purge操作，而这会导致crash。
❑3(SRV_FORCE_NO_TRX_UNDO)：不进行事务的回滚操作。
❑4(SRV_FORCE_NO_IBUF_MERGE)：不进行插入缓冲的合并操作。
❑5(SRV_FORCE_NO_UNDO_LOG_SCAN)：不查看撤销日志（Undo Log），InnoDB存储引擎会将未提交的事务视为已提交。
❑6(SRV_FORCE_NO_LOG_REDO)：不进行前滚的操作。

## 4. 文件

### 参数文件

1. 参数文件：MySQL实例**可以不需要参数文件**，这时所有的参数值取决于编译MySQL时指定的默认值和源代码中指定参数的默认值

2. mysql架构（mysql schema，即名称为mysql库）中记录了访问该实例的权限，如果MySQL实例在默认的数据库目录下找不到mysql架构，则启动会失败，此时可能在错误日志文件中找到如下内容：

```sh
090922 16:25:53[ERROR]Fatal error:Can't open and lock privilege tables:Table'mysql.host'doesn't exist

Oracle数据库存在所谓的隐藏参数（undocumented parameter），以供Oracle“内部人士”使用，SQL Server也有类似的参数。MySQL没有。

参数类型

❑动态（dynamic）参数
❑静态（static）参数

动态参数

动态参数意味着可以在MySQL实例运行中进行更改。global和session关键字，它们表明该参数的修改是基于当前会话还是整个实例的生命周期。有些动态参数只能在会话中进行修改，如autocommit；

SET的语法如下：

SET
|[global|session]system_var_name=expr
|[@@global.|@@session.|@@]system_var_name=expr

静态参数（静态变量）

静态参数说明在整个实例生命周期内都不得进行更改，是只读。对于静态变量，若对其进行修改，会得到类似如下错误：

mysql＞SET GLOBAL datadir='/db/mysql';
ERROR 1238(HY000):Variable'datadir'is a read only variable

日志文件

❑错误日志（error log）
❑慢查询日志（slow query log）
❑查询日志（log）
❑二进制日志（binlog）

错误日志（error log）

错误日志文件对MySQL的启动、运行、关闭过程进行了记录。默认错误文件名为：<主机名>.err。如启动失败，应该先查错误日志。

慢查询日志（slow query log）

该阈值可以通过参数long_query_time来设置，默认值为10，代表10秒。（不包括10秒）
默认情况下，MySQL数据库并不启动慢查询日志，用户需要手工将这个参数log_slow_queries设为ON
设置log_queries_not_using_indexes=ON，如果运行的SQL语句没有使用索引，则会记录到慢查询日志文件。log_throttle_queries_not_using_indexes，用来表示每分钟允许记录到slow log的且未使用索引的SQL语句次数。该值默认为0，表示没有限制。
mysqldumpslow命令，帮助分析慢查询。如果用户希望得到执行时间最长的10条SQL语句，可以运行如下命令：
```
[root@nh119-141 data]#mysqldumpslow-s al-n 10 david.log
```
参数log_output指定了慢查询输出的格式，默认为FILE，可以将它设为TABLE。MySQL 5.1开始可以将慢查询的日志记录放入一张表中，这使得用户的查询更加方便和直观。慢查询表在mysql架构下，名为slow_log。（slow_log表使用的是CSV引擎，可以把slow_log表的引擎转换到MyISAM，但是，如果已经启动了慢查询，将会提示错误）

mysql＞SELECT*FROM mysql.slow_log

long_query_io将超过指定逻辑IO次数的SQL语句记录到slow log中。该值默认为100。（物理读取：从磁盘读取，逻辑读取：磁盘和缓冲池）
slow_query_type，用来表示启用slow log的方式，可选值为：
❑0表示不将SQL语句记录到slow log
❑1表示根据运行时间将SQL语句记录到slow log
❑2表示根据逻辑IO次数将SQL语句记录到slow log
❑3表示根据运行时间及逻辑IO次数将SQL语句记录到slow log

查询日志（log）

查询日志记录了所有对MySQL数据库请求的信息，无论这些请求是否得到了正确的执行。默认文件名为：主机名.log。甚至记录了对Access denied的请求。从MySQL 5.1开始，可以将查询日志的记录放入mysql架构下的general_log表中。

SET GLOBAL general_log = 'ON'

二进制日志（binlog）

二进制文件在log目录，不在data目录

二进制日志（binary log）记录了对MySQL数据库执行更改的所有操作，但是不包括SELECT和SHOW这类操作
操作本身并没有导致数据库发生变化，那么该操作可能也会写入二进制日志。如：0 rows affected。
二进制日志主要有以下几种作用：

❑恢复（recovery）：某些数据的恢复需要二进制日志，例如，在一个数据库全备文件恢复后，用户可以通过二进制日志进行point-in-time的恢复。
❑复制（replication）：其原理与恢复类似，通过复制和执行二进制日志使一台远程的MySQL数据库（一般称为slave或standby）与一台MySQL数据库（一般称为master或primary）进行实时同步。
❑审计（audit）：用户可以通过二进制日志中的信息来进行审计，判断是否有对数据库进行注入的攻击。
bin_log.00001即为二进制日志文件。bin_log.index为二进制的索引文件，用来存储过往产生的二进制日志序号，在通常情况下，不建议手工修改这个文件。
二进制日志文件在默认情况下并没有启动？（存疑）
开启二进制日志文件性能的损失十分有限。根据MySQL官方手册中的测试表明，开启二进制日志会使性能下降1%。
参数max_binlog_size指定了单个二进制日志文件的最大值，如果超过该值，则产生新的二进制日志文件，后缀名+1，并记录到.index文件。从MySQL 5.0开始的默认值为1 073 741 824，代表1 G。
二进制日志缓冲的大小由binlog_cache_size决定，默认大小为32K。未提交（uncommitted）的二进制日志会被记录到一个缓存中去，等该事务提交（committed）时直接将缓冲中的二进制日志写入二进制日志文件。binlog_cache_size是基于会话（session）的，也就是说，当一个线程开始一个事务时，MySQL会自动分配一个大小为binlog_cache_size的缓存，不能设置过大。当一个事务的记录大于设定的binlog_cache_size时，MySQL会把缓冲中的日志写入一个临时文件中，因此该值又不能设得太小。
参数sync_binlog=[N]表示每写缓冲多少次就同步到磁盘。如果将N设为1，sync_binlog=1表示采用同步写磁盘的方式来写二进制日志，默认值为0。

但是，即使将sync_binlog设为1，还是会有一种情况导致问题的发生。当使用InnoDB存储引擎时，在一个事务发出COMMIT动作之前，由于sync_binlog为1，因此会将二进制日志立即写入磁盘。如果这时已经写入了二进制日志，但是提交还没有发生，并且此时发生了宕机，那么在MySQL数据库下次启动时，由于COMMIT操作并没有发生，这个事务会被回滚掉。但是二进制日志已经记录了该事务信息，不能被回滚。这个问题可以通过将参数innodb_support_xa设为1来解决，虽然innodb_support_xa与XA事务有关，但它同时也确保了二进制日志和InnoDB存储引擎数据文件的同步。
MySQL 5.1开始引入了binlog_format参数，该参数可设的值有STATEMENT、ROW和MIXED。

（1）STATEMENT格式和之前的MySQL版本一样，二进制日志文件记录的是日志的逻辑SQL语句。
（2）在ROW格式下，二进制日志记录的不再是简单的SQL语句了，而是记录表的行更改情况。基于ROW格式的复制类似于Oracle的物理Standby（当然，还是有些区别）。同时，对上述提及的Statement格式下复制的问题予以解决。从MySQL 5.1版本开始，如果设置了binlog_format为ROW，可以将InnoDB的事务隔离基本设为READ COMMITTED，以获得更好的并发性。

（3）在MIXED格式下，MySQL默认采用STATEMENT格式进行二进制日志文件的记录，但是在一些情况下会使用ROW格式，可能的情况有：
1）表的存储引擎为NDB，这时对表的DML操作都会以ROW格式记录。
2）使用了UUID()、USER()、CURRENT_USER()、FOUND_ROWS()、ROW_COUNT()等不确定函数。
3）使用了INSERT DELAY语句。
4）使用了用户定义函数（UDF）。
5）使用了临时表（temporary table）。

在通常情况下，我们将参数binlog_format设置为ROW，这可以为数据库的恢复和复制带来更好的可靠性。但是不能忽略的一点是，这会带来二进制文件大小的增加，有些语句下的ROW格式可能需要更大的容量。比如我们有两张一样的表，大小都为100W，分别执行UPDATE操作。
二进制日志文件的文件格式为二进制，必须通过MySQL提供的工具mysqlbinlog查看。

[root@nineyou0-43 data]#mysqlbinlog--start-position=203 test.000004
/*!40019 SET@@session.max_insert_delayed_threads=0*/;
….
#090927 15:43:11 server id 1 end_log_pos 376 Query thread_id=188 exec_time=1 error_code=0
SET TIMESTAMP=1254037391/*!*/;
update t2 set username=upper(username)where id=1
/*!*/;
#at 376
#090927 15:43:11 server id 1 end_log_pos 403 Xid=1009
COMMIT/*!*/;
DELIMITER;
#End of log file
ROLLBACK/*added by mysqlbinlog*/;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

如果这时使用ROW格式的记录方式，会发现mysqlbinlog的结果变得“不可读”（unreadable）

套接字文件

在UNIX系统下本地连接MySQL可以采用UNIX域套接字方式，这种方式需要一个套接字（socket）文件。套接字文件可由参数socket控制。一般在/tmp目录下，名为mysql.sock：
mysql＞SHOW VARIABLES LIKE’socket’\G;
1.row
Variable_name:socket
Value:/tmp/mysql.sock
1 row in set(0.00 sec)

pid文件

当MySQL实例启动时，会将自己的进程ID写入一个文件中——该文件即为pid文件。该文件可由参数pid_file控制，默认位于数据库目录下，文件名为主机名.pid：
mysql＞show variables like’pid_file’\G;
1.row

最低0.47元/天解锁文章

Kin神

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Innodb笔记

InnoDB遗留问题：表空间、段、区、索引的关系？[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KtbFBNxy-1649291208567)(mysql-innodb-架构2.png)]1. 后台线程 BACKGROUND THREADMaster Thread: 主要负责将缓冲池中的数据异步刷新到磁盘IO Thread: 负责AIO（Async IO）回调处理Purge Thread: 回收已经使用并分配的undo页。Page Cleaner Threa
复制链接

扫一扫