MySQL错误日志（error log）,二进制日志（binlog）,慢查询日志（slow query log）,查询日志（general log）,重写日志（redo log）
- 一参数文件
- 怎么查看有哪些配置文件
- 参数文件的作用
- 如何使用官方文档来修改
- datadir的权限不对可能导致服务启动不起来
- 进入varlibmysqlls -l看看权限
- 二日志文件
- 1 redo log重写日志
- redo log的作用
- redo log的工作原理
- redo log的特点
- 2 bin logbinary log二进制日志
- binlog二进制日志的主要作用
- 启动binlog
- 影响binlog二进制日志文件的7个参数
- max_binlog_size参数
- binlog_cache_size参数
- sync_binlog参数
- bin_do_db 和 binlog_ignore_db
- log-slave-update
- binlog_format参数重要
- 扩展_事务的4种隔离级别
-
- binlog_format参数的修改
-
- binlog二进制文件的查看
- 3 error log错误日志
- 4 慢查询日志
- 怎么看慢查询日志
- 如何分析查看慢查询
- 格式化输出慢查询
- 5 查询日志 general_log
- 参数
- 修改
- 作用
- 建议
- 1 redo log重写日志
- 三socket 套接字文件
- 四pid文件
- 五MySQL表结构文件
- 具体例子
- 六InnoDB存储引擎文件
- 表空间文件
- 重做日志文件
- 参数innodb_log_file_size innodb_log_files_in_group innodb_mirrored_log_groupsinnodb_log_group_home_dir
- 同样是记录事务日志重做日志和之前的二进制日志有什么区别
- 触发rego log 缓冲写入磁盘的参数innodb_flush_log_at_trx_commit
去IOE
去IBM（小型机）、Oracle（数据库）、EMC（存储）
一套就几百万、上千万。
互联网企业硬件架构描述，主要是存储架构：
pc server：
本地只有2块盘，做raid1，主要是用来做OS，放mysql软件的；
如果本地盘IO高的话（正常是很低的，因为本地盘只装软件啊）：
1.产生了严重的swap（缓页）；
2.数据文件建到本地盘了。 
原理是啥呢：
当互联网公司有钱了，一般都会去购买PCIE闪卡，有3T（5万一个）和6T（10万一个）的。直接插到服务器的主板上。这样，本地的两个盘就能识别它的空间。而闪卡的IOPS能够达到50万（正常的盘在100左右…）。
mysql> show variables like '%base%'; #查看数据库装在哪里了
mysql> show variables like '%data%'; #查看数据库的数据文件存在哪里MySQL数据库的文件：
- 1.参数文件：mysql启动时读取的第一个文件。/etc/my.cnf 配置参数文件
- 2.日志文件：记录mysql实例对某种条件做出响应时写入的文件。错误日志文件、二进制日志文件、慢查询日志文件、查询日志文件等。
- 3.socket文件：用UNIX域套接字方式进行连接时需要的文件。
- 4.pid文件：mysql实例的进程ID文件
- 5.MySQL表结构文件：用来存放mysql表结构定义文件。
- 6.存储引擎文件：每个存储引擎都会有自己的文件来保存各种数据。存储引擎真正存储了记录和索引等数据。
一、参数文件
数据库启动的时候，读取的第一个文件
默认在/etc/my.cnf
怎么查看有哪些配置文件？
# mysql --help | grep my.cnf/etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf、~/.my.cnf
mysql启动的时候，先找/etc/my.cnf配置文件，找不到，就找/etc/mysql/my.cnf，找到找不到都会找一遍。
所以，一般在启动mysql的时候，都手动指定参数文件：
# mysqld_safe --defaults-file=/etc/my.cnf &
（忘记mysqld_safe语法的时候，就–help）
参数文件的作用
①Oracle实例启动时，若找不到参数文件，是不能进行装载（mount）操作的。
②MySQL实例可以不需要参数文件，这时所有的参数值取决于编译MySQL时指定的默认值和源代码中指定参数的默认值。
但是，mysql如果在默认的数据库目录下找不到mysql架构，则启动会失败。可以在错误日志中找到如下内容： 
如何使用官方文档来修改
- Cmd_Line：配置文件。mysqld_safe –变量名=想设的值
- Option File：配置文件。yes的话，也可以在mysqld_safe时指定值。
- System Var：Yes的话，是系统变量，能改。
- Status Var：Yes的话，则是指标。不能改。
- Var Scope：是全局的还是会话级别的变量。set @@global.变量名=值
- Dynamic：是否是动态参数。静态就改配置文件咯。
注意：修改参数时，一定要先看官方文档！了解参数是否动态，允许的值和范围等。
datadir的权限不对，可能导致服务启动不起来
mysql>show variables like '%data%'; #看数据目录在哪
进入/var/lib/mysql，ls -l，看看权限
可以看到，数据文件目录/var/lib/mysql/下面的权限：
目录权限一般是700，属主和属组都是mysql
文件权限一般是660，属主和属组都是mysql
二、日志文件
- 1）错误日志（error log）
- 2）二进制日志（binlog）
- 3）慢查询日志（slow query log）
- 4）查询日志（log）
- 5）重写日志（redo log）
1) redo log（重写日志）
log buffer往log file里写redo log的触发机制：
- ①每1s写；
- ②大于log buffer空间的1/2的时候；
- ③submit的时候；
- ④log buffer到了1M的时候；
- ⑤WAL[日志先写机制]
当后台脏页往磁盘里写的时候，要先把日志写过来。–》WAL【日志先写】
【WAL：】
【磁盘上的数据是比较旧的，而日志文件是比较新的。】
【日志比最新的数据还要新】
redo log的作用
数据库崩了之后，先要做前滚（redo log+旧的数据块），再做回滚（undo、rollback） –》保护脏页。
redo log的工作原理
用户线程连接数据库，进行dml操作，操作数据块，产生redo log（记录的是：对哪个数据文件space no、哪个数据页page no、哪个数据行row no、做的什么dml、value）
【不管事务；只盯着脏页；按照时间顺序记录】
redo log的特点
- ①redo log是循环覆盖的，它只能保证：脏页没有写到磁盘上，对应的redo log是不能被覆盖的。
- ②所以，mysql里redo log 只能做崩溃恢复。
- ③只针对innodb这些表起作用。
2) bin log（binary log，二进制日志）
每个用户线程连上来后，工作空间里已讲的有：
sort_buffer_size（排序空间）、binlog_buffer_size…..
工作原理：假设事务里面有5条sql语句，commit的时候，binlog_buffer才会写回到磁盘的binlog。binlog不会被覆盖，是一直存在的。
binlog的特点：
- ①记录的是sql语句的形式；
- ②commit提交的时候才写回；
- ③binlog可以用来做数据备份后的恢复；
- ④对所有的表起作用
mysql> show master status \G #查看bin log的状态。binlog（二进制日志）的主要作用
- ①恢复（recovery）：某些数据的恢复需要二进制日志，例如，在一个数据库全备文件恢复后，用户可以通过二进制日志进行point-in-time的恢复。
- ②复制（replication）：其原理与恢复类似，通过复制和执行binlog（二进制日志）使一台远程的MySQL数据库（一般为slave或standby）与一台MySQL数据库（一般称为master或primary）进行实时同步。
—》主从复制（一主多从、一主一从挂从）【作用：灾备、主库的卸载等】 - ③审计（audit）：用户通过binlog日志中的信息来进行审计，判断是否有对数据库进行注入的攻击。【例如：修改游戏币…】
启动binlog
通过配置参数 log-bin[=name ］ 可以启动二进制日志 。如果不指定name ，则默认二进制日志文件名为主机名，后缀名为二进制日志的序列号，所在路径为数据库数据所在目录 (datadir ） ，如 ： 
【注意！！修改配置文件后，要先停止服务，再启动服务！！
①# mysqladmin -uroot -p shutdown -h127.0.0.1 -P3307
②#mysqld_safe --defaults-file=/etc/mysqla.cnf &
③# mysql -uroot -p -P3307 -h127.0.0.1 影响binlog二进制日志文件的7个参数
- ①max_binlog_size
- ②binlog_cache_size
- ③sync_binlog
- ④binlog-do-db
- ⑤binlog-ignore-db
- ⑥log-slave-update
- ⑦binlog_format
①max_binlog_size参数
该参数指定了单个二进制日志文件的最大值，如果超过该值，则产生新的二进制日志文件，后缀名＋1，并记录到 .index 文件 。从MySQL5.0开始的默认值为 1 073 741 824 ，代表1GB（之前的版本max-binlog-size默认大小为1.1GB）
②binlog_cache_size参数
默认32K。cache写不下了，就会往磁盘写。
当使用事务的表存储引擎 （ 如InnoDB存储引擎） 时，所有未提交 （ uncommitted ）的二进制日志会被记录到一个缓存中 ，等该事务提交时 （ committed ） 时直接将缓冲中的二进制日志写入二进制日志文件，而该缓冲的大小由 binlog_cache_size 决定，默认大小为 32KB 。此外 ，binlog_cache_size 是基于会话 （ session ） 的，也就是说 ，当一个线程开始一个事务时 ，MySQL会自动分配一个大小为 binlog_cache_size 的缓存 ，因此该值的设置需要 相当小心，不能设置过大 。当一个事务的记录大于设定的 binlog_cache_size 时，MySQL会把缓冲中的日志写入一个临时文件中 ，因此该值又不能设得太小 。通过SHOW GLOBAL STATUS命令查看 binlog_cache_use 、binlog_cache_disk_use 的状态 ，可以判断当前 binlog_cache_size 的设置是否合适。Binlog_cache_use 记录了使用缓冲写二进制日志的次数， binlog_cache_disk_use 记录了使用临时文件写二进制日志的次数 。现在来看一个数据库的状态 ：
mysql> show variables like '%binlog_cache_size%';
mysql> show global status like '%binlog_cache%';
- binlog_cache_use：使用缓冲次数；
- binlog_cache_disk_use：临时文件使用次数为0；
所以，一般当使用缓冲的次数很大很大，临时文件的使用次数也很大很大时，才有必要调整binlog_cache_size的值。
③sync_binlog参数
同步二进制文件。一般设为1–》绕过文件系统的缓存。
默认情况下，二进制日志并不是在每次写的时候同步到磁盘 （我们可以理解为缓冲写）。因此，当数据库所在操作系统发生宕机时 ，可能会有最后一部分数据没有写入二进制日志文件中 。这会给恢复和复制带来问题 。参数sync_binlog=[ N］表示每写缓冲多少次就同步到磁盘。如果将N设为 1，即 sync_binlog= 1表示采用同步写磁盘的方式来写二进制日志 ，这时写操作不使用操作系统 的缓冲来写二进制日志。该默认值为0 ，如果使用InnoDB存储引擎进行复制，并且想得到最大的高可用性，建议将该值设为ON。不过该值为ON时，确实会对数据库的IO系统带来一定的影响。
但是 ，即使将sync_binlog 设为 1，还是会有一种情况会导致问题的发生 。当使用 lnnoDB存储引擎时，在一个事务发出COMMIT动作之前 ，由于sync_binlog设为1，因此会将二进制日志立即写入磁盘 。如果这时已经写入了二进制日志，但是提交还没有发生 ，并且此时发生了宕机 ，那么在MySQL数据库下次启动时 ，因为COMMIT操作井没有发生，所以这个事务会被回滚掉。但是二进制日志已经记录了该事务信息，不能被回滚。这个问题可以通过将参数innodb_support_xa 设为1来解决，虽然innodb_support_xa 与XA事务有关，但它同时也确保了二进制日志和InnoDB存储引擎数据文件的同步。
④⑤bin_do_db 和 binlog_ignore_db
两个参数表示需要写入或者忽略写入哪些库的日志。默认为空，表示需要将所有库的日志同步到二进制日志。
⑥log-slave-update
如果当前数据库是复制中的slave角色 ，则它不会将从master取得并执行的二进制日志写入自己的二进制日志文件中。如果需要写入，则需要设置log-slave-update。如果需要搭建master=>slave=>slave 架构的复制，则必须设置该参数。
⑦binlog_format参数（重要！！）
binlog_format参数十分重要，这影响了记录二进制日志的格式。在MySQL 5.1版本之前，没有这个参数。所有二进制文件的格式都是基于SQL语句 （ statement ） 级别的，因此基于这个格式的二进制日志文件的复制 （Replication ） 和Oracle逻辑Standby有点相似。同时，对于复制是有一定要求的如rand 、uuid 等函数 ，或者有使用触发器等可能会导致主从服务器上表的数据不一致（ not sync），这可能使得复制变得没有意义。另一个影响是，会发现InnoDB存储引擎的默认事务隔离级别是REPEATABLE READ。这其实也是因为二进制日志文件格式的关系 ，如果使用READ COMMITTED的事务隔离级别（大多数数据库 如Oracle 、Microsoft SQL Server数据库的默认隔离级别） 会出现类似丢失更新的现象，从而出现主从数据库上的数据不一致。
扩展_事务的4种隔离级别：
四个级别与四种现象的关系是：
| 英文 | 更新丢失 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|---|
| Read Uncommited 读未提交 | 不会出现 | 会出现 | 会出现 | 会出现 |
| Read Commited 读已提交 | 不会出现 | 不会出现 | 会出现 | 会出现 |
| Repeatable Read 可重复读 | 不会出现 | 不会出现 | 不会出现 | 会出现 |
| Serializable 串行化 | 不会出现 | 不会出现 | 不会出现 | 不会出现 |
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 ，以获得更好的井发性 。 【用row模式可以记录dml时具体的产生的数记录下来。】
【有些语句例如update时，ROW格式会需要更大的容量，因为它记得是每行的更改信息】 - ( 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 参数还有对于存储引擎的限制 ，如表3-1所示。 
binlog_format参数的修改
binlog_format 是动态参数 ，因此可以在数据库运行环境下进行更改，我们可以将当前会话的binlog_format 设为ROW ，如 ：
mysql>set @@session.binlog_format='ROW';
#修改
mysql>select @@session.binlog_format；
#查看binlog_format的状态
mysql>show master status\G
#查看binlog文件的情况 --》可以计算binlog二进制日志的生成速度（差值/间隔）
binlog二进制文件的查看
二进制日志文件的文件格式为二进制（好像有点废话），不能像错误日志文件，慢查询日志文件用cat、head、tail等命令来查看 。想要查看二进制日志文件的内容，须通过 MySQL提供的工具 mysqlbinlog。
#mysqlbinlog -vv mysqlserver.000003【注意！只有编译安装的mysql实例，才能开启binlog功能！！】
怎么看binlog？ 
回车后，会显示的跟乱码似的。
【加个vv再显示就好了】
PS：UUID
在不同的数据库上uuid是不一样的。 
去看binlog： 
换个模式看： 
【看到，到了从库以后，跟在主库看到的是不一样的！！】
所以，用row模式可以记录dml时具体的产生的数记录下来。
3） error log：错误日志
DBA：日志查看能力才是核心的能力。
错误日志文件对MySQL的启动、运行 、关闭过程进行了记录。MySQL DBA在遇到问题时应该首先查看该文件。该文件不但记录了出错信息 ，也记录一些警告信息或者正确的 信息 。总的来说，这个文件更类似于 Oracle的alert文件 ，只不过在默认情况下是 err结尾。你可以通过 show variables like ‘log_error’ ，来定位该文件，如：
看日志的技巧：
①ll -t，看时间最新的；
②看大小最大的。一般越大的包含的核心内容越多。
#cd /var/log/
#ll
mysqld.log –>数据库系统最重要的错误日志；
messages –>linux最重要的日志。
4） 慢查询日志：
前面提到可以通过错误日志得到一些关于数据库优化的信息帮助，而慢查询能为 SQL语句的优化带来很好的帮助 。可以设一个阈值，将运行时间超过该值的所有SQL语句都记录到慢查询日志文件中。该阈值可以通过参数 long_query_time 来设置，默认值为10 , 代表10秒。
默认情况下 ，MySQL数据库并不启动慢查询日志 ，你需要手工将这个参数设为 ON , 然后启动，可以看到如下结果 ：
mysql> show variables like '%slow%';
mysql> show variables like '%long%';
这里需要注意两点 。首先，设置long_query _time这个阑值后 ，MySQL数据库会记录运行时间超过该值的所有SQL语句，但对于运行时间正好等于 long_query_time 的情况，并不会被记录下 。也就是说 ，在源代码里是判断大于 long_query_time，而非大于等于 。其次 从MySQL 5.1开始 ，long_query _time开始以 微秒 记录SQL语句运行时间 ，之前仅用秒为单 位记录。这样可以更精确地记录SQL的运行时间，供DBA分析。对DBA来说，一条SQL语 句运行0.5秒和0.05秒是非常不同的 ，前者可能已经进行了表扫 ，后面可能是走了索引。
怎么看慢查询日志
- Rows_sent：指的是update这条sql语句返回给了用户几行数据；
- Rows_examined：指的是update这条sql一共处理了几行数据；
- Lock_time：锁等待的时间；
- Query_time：这条sql的总执行时间。
重点：Row_sent： Row_examined比值==1:20 就不快了。【两个值越近越好】
【如果一个sql执行的慢，是因为锁，那就没法调优了。】
慢查询的原因一般是：
- ①lock_time锁等待的时间太长；
- ②examined一共处理的数据太多。
另一个和慢查询日志有关的参数是 log_queries_not_using_indexes，如果运行的SQL语句没有使用索引，则MySQL数据库同样会将这条 SQL语句记录到慢查询日志文件。首先 确认打开了log_queries_not_using_indexes:
mysql> show variables like '%log_queries_not_using_indexes%';
#查看是否打开了该功能
当为OFF时，表示它使用了索引，即使是慢查询，也不会记录到慢查询文件。
如何分析、查看慢查询
最经典的就是看它的执行计划：explain
mysql>explain select * from customer where c_street_1 like '%abc%';
possible_keys==NULL：表示这个表没有做索引，走的全表扫描；
MySQL5.6.5版本开始新增了一个参数 log_throttle_queries_not_using_indexes，用来表示每分钟允许记录到slow log的且未使用索引的SQL语句次数，该值默认为0，表示没有限制（不好）。在生产环境下，若没有使用索引，此类SQL语句会疯狂地被记录到slow log，从而导致slow log文件的大小不断增加，故DBA可通过此参数进行配置。
格式化输出慢查询
我们可以通过慢查询日志来找出有问题的SQL语句，对其进行优化。随着MySQL数据库服务器运行时间的增加，可能会有越来越多的 SQL查询被记录到了慢查询日志文件中，这时要分析该文件就显得不是很容易了。MySQL这时提供的 mysqldumpslow 命令，可以很好地解决这个问题：
#mysqldumpslow nh122-190-slow.log
--verbose verbose
--debug debug
--help write this text to standard output
-v verbose
-d debug
-s ORDER what to sort by (al,at，ar,c，l，r,t），'at' is default
al: average lock time
ar: average rows sent
at: average query time
c : count
l : lock time
r : rows sent
t : query time
-r reverse the sort order ( largest last instead of f irst )
-t NUM just show the top n queries
-a don't abst ract all numbers to N and strings to ’ S
-n NUM abstract numbers with at least n digits within names
-g PATTERN grep : only consider stmts that include this string
-h HOSTNAME hostname of db server for *-slow.log filename (can be wildcard),default is '＊'，i.e.match all
-i NAME name of server instance (if using mysql.server startup script)
-l don't subtract lock time f rom total time比如，我们想得到锁定时间最长的10条SQL语句，可以运行：
#/usr/local/mysql/bin/mysqldumpslow -s al -n 10 david.log参数log_output 指定了慢查询输出的格式，默认为FILE ，你可以将它设为TABLE ， 后就可以查询mysql架构下的slow_log表了 ，如：
mysql> show variables like '%log_output%';
参数log_output是动态的 ，并且是全局的。我们可以在线进行修改
慢查询的缺点：
- ①正在慢的sql 是不能查询的！
- ②只能查询已经慢的sql！！
5） 查询日志 general_log
查询日志记录了所有对 MySQL数据库请求的信息，不论这些请求是否得到了正确的执 行。默认文件名为 ：主机名.log
参数
mysql> show variables like ‘%general%’;
看到，此时查询日志是OFF关闭的。查询日志文件是/var/lib/mysql/liupeng.log
修改
mysql> set @@global.general_log=on;
作用
可以用作数据库的安全审计，看你干了什么坏事。
建议
查询日志不要打开。
因为记录的范围太大，虽然安全了，但是对性能有很大的拉低。
三、socket 套接字文件
Unix 系统下本地连接MySQL可以采用Unix域套接字方式 ，这种方式需要一个套接字 （ socke ） 文件 。
mysql> show variables like '%socket%';
【有多套数据库实例的时候这样连接】
【连哪个数据库，就连哪个数据库的sock文件】
#mysql -S /mysqldata/mysql.sock -uroot -p123123四、pid文件
当MySQL 实例启动时，会将自己的进程 ID写入一个文件中一一该文件即为pid文件。该文件可由参数 pid_file 控制。默认路径位于数据库目录下，文件名为主机名.pid 。
mysql> show variables like ‘%pid_file%’;
五、MySQL表结构文件
因为MySQL插件式存储引擎的体系结构的关系，MySQL对于数据的存储是按照表的 ，所以每个表都会有与之对应的文件（ 对比SQL Server是按照每个数据库下的所有表或索引都存在mdf文件中）。不论采用何种存储引擎，MySQL都有一个以frm为后缀名的文件，这个文件记录了该表的表结构定义。
frm还用来存放视图的定义，如我们创建了一个 v_a 视图 ，那么对应地会产生一个 v_a.frm 文件，用来记录视图的定义，该文件是文本文件，可以直接使用 cat 命令进行查看。
- 表：frm文件+ibd文件
- 视图：只有 ibd 文件
ibd文件和frm文件的区别：
- .ibd文件：表的结构信息+索引的信息
- .frm文件：只有表的结构信息
具体例子
#strings XX.frm --》可以看.frm对应的表的结构信息。
六、InnoDB存储引擎文件
共享表空间：
adaptive hash index；
insert buffer；造成它暴增的原因 –》①索引多②索引的顺序跟表的顺序差别很大
double write； –》很小
undo。–》最不可控，可能会变成很大。
将undo从ibdata里面独立出来，初始化数据库的时候，时候就不能改变了。
大事务、长事务一般会导致undo暴增。
之前介绍的文件都是MySQL数据库本身的文件，和存储引擎无关 。除了这些文件外，每个表存储引擎还有其自己独有的文件。和InnoDB存储引擎密切相关的文件，这些文件包括重做日志文件 、表空间文件。
表空间文件
InnoDB存储引擎在存储设计上模仿了 Oracle ，将存储的数据按表空间进行存放 。默认配置下，会有一个初始化大小为 10MB 、名为ibdata1 的文件。该文件就是默认的表空间文件（tablespace file）。可以通过参数innodb_data_file_path 对其进行设置 。格式如下 ：
innodb_data_file_path=datafile_spec1[ ;datafile_spec2] ……
也可以用多个文件组成一个表空间 ，同时制定文件的属性 ，如：
[ mysqld ]
innodb_data_file_path = /db /ibdata1：2000M; /dr2/db/ibdata2：2000M：autoextend
这里将/db/ibdata1 和／dr2/db/ibdata2 两个文件用来组成表空间 。若这两个文件位于不同的磁盘上 ，则可以对性能带来一定程度的提升 。两个文件的文件名后都跟了属性，表示文件idbdata1 的大小为2000MB，文件ibdata2的大小为2000MB，但是如果用满了这 2000MB 后 该文件可以自动增长 （ autoextend ）。
设置 innodb_data_file_path 参数后 ，之后对于所有基于 lnnoDB存储引擎的表的数据都会记录到该文件内 。而通过设置参数 innodb_file_per_table，我们可以将每个基于 InnoDB 存储引擎的表单独产生一个表空间 ，文件名为表名 .ibd ，这样不用将所有数据都存放于默认的表空间中。下面这台服务器设置了innodb_file_per_table ，可以看到 ：
表Profile 、t1、t2都是lnnoDB 的存储引擎 ，由于设置参数innodb_file_per_table=ON ，因此产生了单独的.ibd表空间文件 。需要注意的是，这些单独的表空间文件仅存储该表的数据、索引和插入缓冲等信息 ，其余信息还是存放在默认的表空间中 。图3-1 显示了InnoDB存储引擎对于文件的存储方式：
重做日志文件
默认情况下会有两个文件，名称分别为 ib_logfile0和ib_logfile1 。MySQL 官方手册中将其称为InnoDB存储引擎的日志文件，不过更准确的定义应该是重做日志文件（redo log file）。为什么强调是重做日志文件呢？因为重做日志文件对于InnoDB存储引擎至关重要，它们记录了对于InnoDB存储引擎的事务日志。
重做日志文件的主要目的是，万一实例或者介质失败（media failure），重做日志文件就能派上用场。如数据库由于所在主机掉电导致实例失败，InnoDB 存储引擎会使用重做日志恢复到掉电前的时刻，以此来保证数据的完整性。
每个InnoDB存储引擎至少有 1个重做日志文件组（group），每个文件组下至少有 2个重做日志文件，如默认的ib_logfile0 、ib_logfile 1 。为了得到更高的可靠性，你可以设置多个镜像日志组 （mirrored log groups），将不同的文件组放在不同的磁盘上。日志组中每个重做日志文件的大小一致 ，并以循环方式使用。InnoDB存储引擎先写重做日志文件1，当达到文件的最后时，会切换至重做日志文件 2 ，当重做日志文件 2也被写满时 ，会再切换到重做日志1中。
参数innodb_log_file_size 、innodb_log_files_in_group 、innodb_mirrored_log_groups、innodb_log_group_home_dir
参数innodb_log_file_size 、innodb_log_files_in_group 、innodb_mirrored_log_groups、innodb_log_group_home_dir影响着重做日志文件的属性：
- 参数 innodb_log_file_size 指定了 重做日志文件的大小；
- 参数 innodb_log_files_in_group 指定了日志文件组中重做日志文件的数量，默认为21；
- 参数 innodb_mirrored_log_groups 指定了日志镜像文件组的数量，默认为 1，代表 只有一个日志文件组，没有镜像；
- 参数 innodb_ log_group_home_dir 指定了 日志文件组所在路径，默认在数据库路径下。
重做日志文件的大小设置对于MySQL数据库各方面还是有影响的。一方面不能设置得太大，如果设置得很大，在恢复时可能需要很长的时间；另一方面又不能太小了，否则可能导致一个事务的日志需要多次切换重做日志文件。
redo log file：不能太大，不能太小！
同样是记录事务日志，重做日志和之前的二进制日志有什么区别
首先，二进制日志会记录所有与 MySQL有关的日志记录 ，包括InnoDB 、My ISAM 、Heap等其他存储引擎的日志 。而InnoDB 存储引擎的重做日志只记录有关其本身的事务日志 。其次，记录的内容不同，不管你将二进制日志文件记录的格式设为 STATEMENT还是ROW ,又或者是MIXED ，其记录的都是关于一个事务的具体操作内容 。而InnoDB存储引擎的重做日志文件记录的关于每个页 （ Page ） 的更改的物理情况 。此外，写入的时间也不同 ，二进制日志文件是在事务提交前进行记录的，而在事务进行的过程中，不断有重做日志条目 （ redo entry ） 被写入重做日志文件中 。
对于写入重做日志文件的操作不是直接写 ，而是先写入一个重做日志缓冲 （ redo log buffer ） 中，然后根据按照一定的条件写入日志文件 。图3-3很好地 表示了这个过程 。
从日志缓冲写入磁盘上的重做日志文件是按一定条件的 ，那这些条件有哪些呢？
主线程 （ master thread ） ，知道在主线程中每秒会将重做日志缓冲写入磁盘的重做日志文件中，不论事务是否已经提交 。另一个触发这个过程是由参数 innodb_ flush_log_at_trx_commit 控制 ，表示在提交（commit）操作时，处理重做日志的方式。
触发rego log 缓冲写入磁盘的参数innodb_flush_log_at_trx_commit
参数innodb_flush_log_at_trx_commit 可设的值有0 、1、2。
- 0代表当提交事务时 ，并不将事务的重做日志写入磁盘上的日志文件，而是等待主线程每秒的刷新；
- 1是在commit时将重做日志缓冲同步写到磁盘 ；
- 2是重做日志异步写到磁盘 ，即不能完全保证commit时肯定会写入重做日志文件 ，只是有这个动作 。