mysql pid权限给mysql mysql pid文件

3.3 套接字文件

• UNIX系统本地连接MySQL需要一个套接字（socket）文件。一般在/tmp目录下，名为mysql.lock

3.4 pid文件

当 MySQL 实例启动时，会将自己的进程ID写入一个文件中——该文件即为 pid文件。该文件可由参数 pid_file 控制，默认位于数据库目录下，文件名为主机名.pid∶

3.5 表结构定义文件

• 因为MySQL 插件式存储引擎的体系结构的关系，MySQL 数据的存储是根据表进行的，每个表都会有与之对应的文件。但不论表采用何种存储引擎，MySQL都有一个以frm 为后缀名的文件，这个文件记录了该表的表结构定义。
• frm还用来存放视图的定义，如用户创建了一个v_a 视图，那么对应地会产生一个v_a.frm 文件，用来记录视图的定义，该文件是文本文件，可以直接使用cat命令进行查看∶

3.6 InnoDB存储引擎文件

每个表存储引擎还有其自己独有的文件，这些文件包括重做日志文件、表空间文件。

3.6.1 表空间文件

• InnoDB采用将存储的数据按表空间（tablespace）进行存放的设计。在默认配置下会有一个初始大小为10MB，名为ibdata1 的文件。该文件就是默认的表空间文件（tablespace file），用户可以通过参数 innodb data fle path 对其进行设置，格式如下∶

innodb_data_file_path=datafile_spec1[;datafile_spec2]...

用户可以通过多个文件组成一个表空间，同时制定文件的属性，如∶

[mysqld]
innodb_data_file_path =/db/ibdatal:2000M;/dr2/db/ibdata2:2000M:autoextend

• 这里将/db/ibdatal 和/dr2/db/ibdata2两个文件用来组成表空间。若这两个文件位干不同的磁盘上，磁盘的负载可能被平均，因此可以提高数据库的整体性能。同时，两个文件的文件名后都跟了属性，表示文件idbdatal的大小为 2000MB，文件ibdata2 的大小为 2000MB，如果用完了这 2000MB，该文件可以自动增长（autoextend）。
• 设置innodb_data_file_path参数后，所有基于InnoDB存储引擎的表的数据都会记录到该共享表空间中。若设置了参数 innodb_file_per _table，则用户可以将每个基于InnoDB存储引擎的表产生一个独立表空间。独立表空间的命名规则为;表名.ibd。通过这样的方式，用户不用将所有数据都存放于默认的表空间中。下面这台 MySQL 数据库服务器设置了innodb file per table，故可以观察到∶
  
  需要注意的是，这些单独的表空间文件仅存储该表的数据、索引和插入缓冲 BITMAP 等信息，其余信息还是存放在默认的表空间中。

3.6.2 重做日志文件

• 在默认情况下，在 InnoDB存储引擎的数据目录下会有两个名为ib_logfile0和ib_logfile1的文件。在 MySQL官方手册中将其称为InnoDB存储引擎的日志文件，不过更准确的定义应该是重做日志文件（redo log file）。为什么强调是重做日志文件呢?因为重做日志文件对于InnoDB存储引擎至关重要，它们记录了对于InnoDB存储引擎的事务日志。
• 当实例或介质失败（media failure）时，重做日志文件就能派上用场。例如，数据库由于所在主机掉电导致实例失败，InnoDB存储引擎会使用重做日志恢复到掉电前的时刻，以此来保证数据的完整性。
• 每个InnoDB存储引擎至少有1个重做日志文件组（group），每个文件组下至少有2个重做日志文件，如默认的ib_logfile0和ib_logfile1。为了得到更高的可靠性，用户可以设置多个的镜像日志组（mirrored log groups），将不同的文件组放在不同的磁盘上，以此提高重做日志的高可用性。在日志组中每个重做日志文件的大小一致，并以循环写入的方式运行。InnoDB存储引擎先写重做日志文件1，当达到文件的最后时会切换至重做日志文件2，再当重做日志文件2也被写满时，会再切换到重做日志文件1中。
  
  下列参数影响着重做日志文件的属性∶

1. innodb_log_file_size
2. innodb_log_fles_in_group
3. innodb_mirrored_log_groups
4. innodb_log_group_home_dir

• 参数 innodb_log_file_size指定每个重做日志文件的大小。在 InnoDB1.2.x版本之前，重做日志文件总的大小不得大于等于4GB，而1.2.x版本将该限制扩大为了512GB。
• 参数innodb_log_fles_in_group指定了日志文件组中重做日志文件的数量，默认为2。
• 参数 innodb_mirrored_log_groups指定了日志镜像文件组的数量，默认为1，表示只有一个日志文件组，没有镜像。若磁盘本身已经做了高可用的方案，如磁盘阵列，那么可以不开启重做日志镜像的功能。
• 参数innodb_log_group_home_dir指定了日志文件组所在路径，默认为./，表示在 MySOL数据库的数据目录下。以下显示了一个关于重做日志组的配置∶

重做日志文件不能设置得太大，如果设置得很大，在恢复时可能需要很长的时间。

另一方面又不能设置得太小了，否则可能导致一个事务的日志需要多次切换重做日志文件。此外，重做日志文件太小会导致频繁地发生 async checkpoint，导致性能的抖动。例如，用户可能会在错误日志中看到如下警告信息∶

如果超过了重做日志的capacity变量（代表最后的检查点不能超过这个阈值），如果超过就必须将缓冲池中的脏页列表（flush list）中的部分数据写入磁盘，可能会导致用户线程的阻塞。

那么重做日志文件和二进制文件有什么区别？

1. 二进制日志会记录所有与MySQL数据库有关的日志记录，包括 InnoDB、MyISAM、Heap等其他存储引擎的日志。而InnoDB存储引擎的重做日志只记录有关该存储引擎本身的事务日志。
2. 记录的内容不同，无论用户将二进制日志文件记录的格式设为 STATEMENT 还是 ROW，又或者是 MIXED，其记录的都是关于一个事务的具体操作内容，即该日志是逻辑日志。而InnoDB存储引擎的重做日志文件记录的是关于每个页（Page）的更改的物理情况。
3. 写入的时间也不同，二进制日志文件仅在事务提交前进行提交，即只写磁盘一次，不论这时该事务多大。而在事务进行的过程中，却不断有重做日志条目（redo entry）被写入到重做日志文件中。

在InnoDB存储引擎中，对于各种不同的操作有着不同的重做日志格式。到InnoDB 1.2.x版本为止，总共定义了51种重做日志类型。虽然各种重做日志的类型不同，但是它们有着基本的格式，显示了重做日志条目的结构∶

• redo_log_type 占用1字节，表示重做日志的类型
• space 表示表空间的 ID，但采用压缩的方式，因此占用的空间可能小于4字节
• page_no 表示页的偏移量，同样采用压缩的方式
• redo_log_body 表示每个重做日志的数据部分，恢复时需要调用相应的函数进行解析

写入重做日志文件的操作不是直接写，而是先写入一个重做日志缓冲（redo log buffer）中，然后按照一定的条件顺序地写入日志文件。

• 从重做日志缓冲往磁盘写入时，是按512个字节，也就是一个扇区的大小进行写入。因为扇区是写入的最小单位，因此可以保证写入必定是成功的。因此在重做日志的写入过程中不需要有doublewrite。
• 前面提到了从日志缓冲写入磁盘上的重做日志文件是按一定条件进行的，那这些条件有哪些呢?

1. 主线程（master thread），知道在主线程中每秒会将重做日志缓冲写入磁盘的重做日志文件中，不论事务是否已经提交。
2. 另一个触发写磁盘的过程是由参数innodb_flush_log_at_trx_commit 控制，表示在提交（commit）操作时，处理重做日志的方式。

• 参数 innodb_flush_log_at_trx_commit 的有效值有0、1、2。
• 0代表当提交事务时，并不将事务的重做日志写入磁盘上的日志文件，而是等待主线程每秒的刷新。
• 1和2不同的地方在于∶1表示在执行 commit 时将重做日志缓冲同步写到磁盘，即伴有 fsync 的调用。
• 2表示将重做日志异步写到磁盘，即写到文件系统的缓存中。因此不能完全保证在执行commit 时肯定会写入重做日志文件，只是有这个动作发生。
• 因此为了保证事务的 ACID中的持久性，必须将innodb_flush_log_at_trx_commit设置为1，也就是每当有事务提交时，就必须确保事务都已经写入重做日志文件。那么当数据库因为意外发生宕机时，可以通过重做日志文件恢复，并保证可以恢复已经提交的事务。而将重做日志文件设置为0或2，都有可能发生恢复时部分事务的丢失。不同之处在于，设置为2时，当 MySQL数据库发生宕机而操作系统及服务器并没有发生宕机时，由于此时未写入磁盘的事务日志保存在文件系统缓存中，当恢复时同样能保证数据不丢失。