19 KiB
文件
参数
参数查看
mysql参数为键值对，可以通过show variables命令查看所有的数据库参数，并可以通过like来过滤参数名称。
除了show variables命令之外，还能够在performance_schema下的global_variables视图来查找数据库参数，示例如下：
-- 查看innodb_buffer_pool_size参数
show variables like 'innodb_buffer_pool_size'
上述show variables命令的执行结果为
| Variable_name | Value |
|---|---|
| innodb_buffer_pool_size | 4294967296 |
select * from performance_schema.global_variables where variable_name like 'innodb_buffer_pool%';
上述sql的执行结果如下：
| VARIABLE_NAME | VARIABLE_VALUE |
|---|---|
| innodb_buffer_pool_chunk_size | 134217728 |
| innodb_buffer_pool_dump_at_shutdown | ON |
| innodb_buffer_pool_dump_now | OFF |
| innodb_buffer_pool_dump_pct | 25 |
| innodb_buffer_pool_filename | ib_buffer_pool |
| innodb_buffer_pool_in_core_file | ON |
| innodb_buffer_pool_instances | 4 |
| innodb_buffer_pool_load_abort | OFF |
| innodb_buffer_pool_load_at_startup | ON |
| innodb_buffer_pool_load_now | OFF |
| innodb_buffer_pool_size | 4294967296 |
参数类型
mysql中的参数可以分为动态和静态两种类型，
- 动态：动态参数代表可以在mysql运行过程中进行修改
- 静态：代表在整个实例的声明周期内都不得进行修改
动态参数修改
对于动态参数，可以在运行时通过SET命令来进行修改，SET命令语法如下：
set
| [global | session] system_var_name=expr
| [@@global. | @@session. | @@] system_var_name = expr
在上述语法中，global和session关键字代表该动态参数的修改是针对当前会话还是针对整个实例的生命周期。
- 有些动态参数只能在会话范围内进行修改，例如
autocommit - 有些参数修改后，实例整个生命周期内都会生效，例如
binglog_cache_size - 有些参数既可以在会话范围内进行修改，又可以在实例声明周期范围内进行修改，例如
read_buffer_size
使用示例如下：
查询read_buffer_size的global和session值
-- 查询read_buffer_size的global和session值
select @@session.read_buffer_size,@@global.read_buffer_size;
返回结果为
| @@session.read_buffer_size | @@global.read_buffer_size |
|---|---|
| 131072 | 131072 |
设置@@session.read_buffer_size为524288
set @@session.read_buffer_size = 1024 * 512;
设置后，再次查询read_buffer_size的global和session值，结果为
| @@session.read_buffer_size | @@global.read_buffer_size |
|---|---|
| 524288 | 131072 |
在调用set命令修改session read_buffer_size参数后，session参数发生变化，但是global参数仍然为旧的值。
set session xxx命令并不会对global参数的值造成影响，新会话的参数值仍然为修改前的值。
之后，再对global read_buffer_size值进行修改，执行如下命令
set @@global.read_buffer_size = 496 * 1024;
执行该命令后，sesion和global参数值为
| @@session.read_buffer_size | @@global.read_buffer_size |
|---|---|
| 524288 | 507904 |
set global xxx命令只会修改global参数值，对session参数值不会造成影响，新的session其session参数值, global参数值和修改后的global参数值保持一致
即使针对参数的global值进行了修改，其影响范围是当前实例的整个生命周期，
但是，其并不会对参数文件中的参数值进行修改，故而下次启动mysql实例时，仍然会从参数文件中取值，新实例的值仍然是修改前的值。如果想要修改下次启动实例的参数值，需要修改参数文件中该参数的值。（参数文件路径通常为
/etc/my.cnf）
静态参数修改
在运行时，如果尝试对静态参数进行修改，那么会发生错误，示例如下：
> set global datadir='/db/mysql'
[2025-01-30 15:05:17] [HY000][1238] Variable 'datadir' is a read only variable
日志文件
mysql中常见日志文件如下
- 错误日志(error log)
- 二进制日志（binlog）
- 慢查询日志（slow query log）
- 查询日志（log）
错误日志
错误日志针对mysql的启动、运行、关闭过程进行了记录，用户可以通过show variables like 'log_error';来获取错误日志的路径：
show variables like 'log_error';
其输出值如下：
| Variable_name | Value |
|---|---|
| log_error | /var/log/mysql/mysqld.log |
当mysql数据库无法正常启动时，应当首先查看错误日志。
慢查询日志
慢查询日志存在一个阈值，通过long_query_time参数来进行控制，该参数默认值为10，代表慢查询的限制为10s。
通过slow_query_log参数，可以控制是否日志输出慢查询日志，默认为OFF,如果需要开启慢查询日志，需要将该值设置为ON。
关于慢查询日志的输出地点，可以通过log_output参数来进行控制。该参数默认为FILE，支持FILE, TABLE, NONE。log_output支持制定多个值，多个值之间可以通过,分隔，当值中包含NONE时，以NONE优先。
log_queries_not_using_indexes
当log_queryies_not_using_indexes开启时，如果运行的sql语句没有使用索引，那么这条sql同样会被输出到慢查询日志。该参数默认关闭。
log_throttle_queries_not_using_idnexes用于记录每分钟允许记录到慢查询日志并且没有使用索引的sql语句次数，该参数值默认为0，代表每分钟输出到慢查询日志中的数量没有限制。
该参数主要用于防止大量没有使用索引的sql添加到慢查询日志中，造成慢查询日志大小快速增加。
当慢查询日志中的内容越来越多时，可以通过mysql提供的工具mysqldumpslow命令，示例如下：
mysqldumpslow -s at -n 10 ${slow_query_log_path}
查询日志
查询日志记录了对mysql数据库所有的请求信息，无论请求是否正确执行。
查询日志通过general_log参数来进行控制，默认该参数值为OFF.
二进制日志
二进制日志（binary log）记录了针对mysql数据库执行的所有更改操作（不包含select以及show这类读操作）。
对于update操作等，即使没有对数据库进行修改（affected rows为0），也会被写入到binary log中。
二进制日志的主要用途如下：
- 恢复（recovery）：某些数据恢复需要二进制日志，例如在数据库全备份文件恢复后，用户可以通过二进制日志进行point-in-time的恢复
- 复制（replication）：通过将一台主机（master）的binlog同步到另一台主机（slave），并且在另一台主机上执行该binlog，可以令slave与master进行实时同步
- 审计（audit）：用户可以对binlog中的信息进行审计，判断是否存在对数据库进行的注入攻击
通过参数log_bin可以控制是否启用二进制日志。
binlog通常存放在datadir参数所指定的目录路径下。在该路径下，还存在binlog.index文件，该文件为binlog的索引文件，文件内容包含所有binlog的文件名称。
max_binlog_size
max_binlog_size参数控制单个binlog文件的最大大小，如果单个文件超过该值，会产生新的二进制文件，新binlog的后缀会+1，并且新文件的文件名会被记录到.index文件中。
max_binlog_size的默认值大小为1G。
binlog_cache_size
当使用innodb存储引擎时，所有未提交事务的binlog会被记录到缓存中，等到事务提交后，会将缓存中的binlog写入到文件中。缓存大小通过binlog_cache_size决定，该值默认为32768，即32KB。
binlog_cache_size是基于会话的，在每个线程开启一个事务时，mysql会自动分配一个大小为binlog_cache_size大小的缓存，因而该值不能设置过大。
当一个事务的记录大于设定的binlog_cache_size时，mysql会将缓冲中的日志写入到一个临时文件中，故而，该值无法设置过小。
通过show global status like 'binlog_cache%命令可以查看binlog_cache_use和binlog_cache_disk_use的状态，可以通过上述两个状态判断binlog cache大小是否合适。
binlog_cache_use
binlog_cache_use记录了使用缓冲写binlog的次数
binlog_cache_disk_use
binlog_cache_disk_use记录了使用临时文件写二进制日志的次数
sync_binlog
sync_binlog参数控制mysql server同步binlog到磁盘的频率，该值默认为1
- 0: 如果参数值为0，代表mysql server禁用binary log同步到磁盘。mysql会依赖操作系统将binary log刷新到磁盘中，该设置性能最佳，但是遇到操作系统崩溃时，可能会出现mysql事务提交但是还没有同步到binary log的场景
- 1: 如果参数值设置为1，代表在事务提交之前将binary log同步到磁盘中，该设置最安全，但是会增加disk write次数，对性能会带来负面影响。在操作系统崩溃的场景下，binlog中缺失的事务还只处于prepared状态，从而确保binlog中没有事务丢失
- N：当参数值被设置为非
0，1的值时，每当n个binlog commit groups被收集到后，同步binlog到磁盘。在这种情况下，可能会发生事务提交但是还没有被刷新到binlog中，当n值越大时，性能会越好，但是也会增加数据丢失的风险
为了在使用innodb事务和replciation时获得最好的一致性和持久性，请使用如下设置：
sync_binlog=1
innodb_flush_log_at_trx_commit=1
innodb_flush_log_at_trx_commit
innodb_flush_log_at_trx_commit用于控制redo log的刷新。
该参数用于平衡commit操作ACID的合规性以及更高性能。通过修改该参数值，可以实现更佳的性能，但是在崩溃时可能会丢失事务：
- 1: 1为该参数默认值，代表完全的ACID合规性，日志在每次事务提交后被写入并刷新到磁盘中
- 0: 日志每秒被写入和刷新到磁盘中，如果事务没有被刷新，那么日志将会在崩溃中被丢失
- 2: 每当事务提交后，日志将会被写入，并且每秒钟都会被刷新到磁盘中。如果事务没有被刷新，崩溃同样会造成日志的丢失
如果当前数据库为slave角色，那么其不会把从master同步的binlog写入到自己的binlog中，如果要实现master=>slave=>slave的同步架构，必须设置log_slave_updates参数。
binlog_format
binlog_format用于控制二进制文件的格式，可能有如下取值：
- statement: 二进制文件记录的是日志的逻辑sql语句
- row：记录表的行更改情况，默认值为
row - mixed: 如果参数被配置为mixed，mysql默认会采用
statement格式进行记录，但是在特定场景能够下会使用row格式：- 使用了uuid, user, current_user,found_rows, row_count等不确定函数
- 使用了insert delay语句
- 使用了用户自定义函数
- 使用了临时表
使用statement可能会存在的问题
在使用statement格式时，可能会存在如下问题
- master运行rand，uuid等不确定函数时，或使用触发器操作时，会导致主从服务器上的数据不一致
- innodb的默认事务隔离级别为
repetable_read，如果使用read_commited级别时，statement格式可能会导致丢失更新的情况，从而令master和slave的数据不一致
binlog为动态参数，可以在数据库运行时进行修改，并且可以针对session和global进行修改。
mysqlbinlog
在查看二进制日志时，可以使用mysqlbinlog命令，示例如下
mysqlbinlog --start-position=203 ${binlog_path}
pid文件
mysql实例启动时，会将进程id写入到一个文件中，该文件被称为pid文件。
pid文件路径通过pid_file参数来进行控制，fedora中默认路径为/run/mysqld/mysqld.pid。
表结构定义文件
mysql中数据的存储是根据表进行的，每个表都有与之对应的文件。无论表采用何种存储引擎，都会存在一个以frm为后缀的文件，该文件中保存了该表的表结构定义。
mysql 8中，schema对应目录下不再包含frm文件。
表空间文件
innodb采用将存储的数据按照表空间（tablespace）进行存放的设计。在默认配置下，将会有一个初始大小为10MB，名称为ibdata1的文件，该文件为默认的表空间文件。
innodb_data_file_path
可以通过innodb_data_file_path参数对默认表空间文件进行设置，示例如下：
innodb_data_file_path=datafile_spec1[;datafile_spec2]...
用户可以通过多个文件组成一个表空间，示例如下：
innodb_data_file_path=/db/ibdata1:2000M;/dr2/db/ibdata2:2000M;autoextend
在上述配置中，表空间由/db/ibdata1和/dr2/db/ibdata2两个文件组成，如果两个文件位于不同的磁盘上，那么磁盘的负载将会被平均，数据库的整体性能将会被提高。
同时，在上述示例中，为两个文件都指定了后续属性，含义如下：
- ibdata1：文件大小为2000M
- ibdata2:文件大小为2000M，并且当文件大小被用完后，文件会自动增长
当innodb_data_file_path被设置后，所有基于innodb存储引擎的表，其数据都会记录到该共享表空间中。
innodb_file_per_table
如果innodb_file_per_table被启用后（默认启用），则每个基于innodb存储引擎的表都可以有一个独立的表空间，独立表空间的命名规则为表名+.ibd。
通过innodb_file_per_table,用户不需要将所有的数据都放置在默认的表空间中。
innodb_file_per_table所产生的独立表空间文件，其仅存储该表的数据、索引和插入缓冲BITMAP信息，其余信息仍然存放在默认的表空间中。
redo log文件
redo log是一个基于磁盘的数据结构，用于在crash recovery过程中纠正由未完成事务写入的错误数据。
在一般操作中，redo log对那些
会造成表数据发生改变的请求进行encode操作，请求通常由sql statement或地级别api发起。
redo log通常代表磁盘上的redo log file。写入重做日志文件的数据通常基于受影响的记录进行编码。在数据被写入到redo log file中时，LSN值也会不断增加。
循环写入
innodb会按顺序写入redo log文件，例如redo log file group中存在两个文件，innodb会先写文件1，文件1写满后会切换文件2，在文件2写满后，重新切换到文件1。
redo log capacity
从mysql 8.0.30开始，innodb_redo_log_capacity参数用于控制redo log file占用磁盘空间的大小。该参数可以在实例启动时进行设置，也可以通过set global来进行设置。
innodb_redo_log_capacity默认值为104857600，即100M。
redo log文件默认位于datadir路径下的#innodb_redo目录下。innodb会尝试维护32个redo log file，每个redo log file文件大小都相同，为1/32 * innodb_redo_log_capacity。
redo log file将会使用#ib_redoN的命名方式，N是redo log file number。
innodb redo log file分为如下两种:
- ordinary：正在被使用的redo log file
- spare：等待被使用的redo log file
相比于ordinary redo log file，spare redo log file的名称中还包含了
_tmp后缀
每个oridnary redo log file都关联了一个制定的LSN范围，可以通过查询performance_schema.innodb_redo_log_files表里获取LSN范围。
示例如下：
select file_name, start_lsn, end_lsn from performance_schema.innodb_redo_log_files;
查询结果示例如下：
| file_name | start_lsn | end_lsn |
|---|---|---|
| ./#innodb_redo/#ib_redo6 | 19656704 | 22931456 |
当执行checkpoint时，innodb会将checkpoint LSN存储在文件的header中，在recovery过程中，所有的redo log文件都将被检查，并且基于最大的LSN来执行恢复操作。
常用的redo log状态如下
# resize operation status
Innodb_redo_log_resize_status
# 当前redo log capacity
Innodb_redo_log_capacity_resized
Innodb_redo_log_checkpoint_lsn
Innodb_redo_log_current_lsn
Innodb_redo_log_flushed_to_disk_lsn
Innodb_redo_log_logical_size
Innodb_redo_log_physical_size
Innodb_redo_log_read_only
Innodb_redo_log_uuid
重做日志大小设置时，如果设置大小过大，那么在执行恢复操作时，可能需要花费很长时间；如果重做日志文件大小设置过小，可能会导致事务的日志需要多次切换重做日志文件。
此外，重做日志太小会频繁发生async checkpoint，导致性能抖动。重做日志存在一个capacity，代表了最后的checkpoint不能够超过这个阈值，如果超过必须将缓冲区中的部分脏页刷新到磁盘中，此时可能会造成用户线程的阻塞。
redo log和binlog的区别
记录内容
binlog记录的是一个事务的具体操作内容，该日志为逻辑日志。
而innodb redo log记录的是关于某个页的修改，为物理日志。
写入时机
binlog仅当事务提交前才进行提交，即只会写磁盘一次。
redo log则是在事务运行过程中，不断有重做日志被写入到redo log file中。
redo log写入时机
- master thread会每秒将redo log从buffer中刷新到redo log ile中，不露内事务是否已经提交
- innodb_flush_log_at_trx_commit控制redo log的刷新时机，默认情况下，在事务提交前会将数据从redo log buffer刷新到redo log file中