相关文档：
MySQL所有系统变量官方参考文档：fw_error_www
背景：
MySQL有很多参数，了解这些参数，有助于我们了解数据库的原理和优化，这里我只是把经常用到的参数列举出来：
---基本设置参数---
transaction_isolation：隔离级别
max_allowed_packet ：数据包的大小，客户端和服务端都要同时设置为一样大的值，比如在 mysqldump 备份的时候，生成整表单条 insert 语句的时候，太小的值可能导致备份失败（这1条sql构成的1个数据包大小超过参数定义的包大小限制），建议设置为 32M 或 64M
default_password_lifetime：密码过期策略（0为永不过期；N为N天后过期）
default_storage_engine：默认的永久表存储引擎
default_tmp_storage_engine：create temporary 语句显式创建的临时表默认存储引擎
internal_tmp_disk_storage_engine：内部临时表使用的默认存储引擎
super_read_only：super 权限帐号是否只读（常常在从库中设置这个参数，避免在从库中操作，导致主从不一致）
read_only：非super 权限帐号是否只读
collation_serve：排序规则，如果数据库、表、字段没有设置排序规则，就会继承它的值
character_set_server：字符集，和上面类似其他字符集参数没有单独设置就会继承它的值
autocommit：是否自动提交
auto_increment_increment：自增的步长，常常与 auto_increment_offset 变量一起用于在主主复制环境中避开双写时的主键冲突
auto_increment_offset：设置自增的偏移量
sql_mode：对sql的要求或解析规则
lower_case_table_names：数据库中的数据库名称，表名称是否区分大小写
local_infile：是否允许使用 LOAD DATA INFILE 语句的 LOCAL 方式（即 LOAD DATA LOCAL INFILE）
skip_grant_tables：登录数据库不需要密码
max_execution_time：SELECT 语句的超时时间（单位为毫秒），如果为 0表示不启用超时
slave_exec_mode：复制架构中的从库自动跳过主键冲突(1062：duplicate-key)和记录没有找到（1023：no-key-found）的复制错误
offline_mode：是否设置服务器为“离线模式”
show_compatibility_56：是否开启 information_schema 库中的 global_status 、 session_status 、global_variables、session_variables 表查询功能
tx_read_only：事务默认访问模式
sql_slave_skip_counter：从库上跳过来自主库的 events 的个数
old_alter_table：是否使用旧的方式执行 DDL 语句
max_prepared_stmt_count：允许的prepared 语句的总数
slave_max_allowed_packet：从库 SQL 和 I/O 线程的最大数据包大小，以便在基于行的复制模式中减少因为较大的事务更新产生的数据包大小超过 max_allowed_packet 的大小而导致复制报错的问题
default_authentication_plugin：默认的用户身份验证插件
---连接设置参数---
max_connections：最大支持连接数
max_user_connections：指定用户的连接数
interactive_timeout：交互连接的超时时间
wait_timeout：非交互式连接的超时时间
lock_wait_timeout：元数据锁的超时时间
skip_name_resolve：是否跳过域名解析
skip_networking：是否允许远程连接数据库
---日志设置参数---
long_query_time：慢查询时间定义
slow_query_log：是否打开慢查询日志‘
log_queries_not_using_indexes：没有使用索引的查询，是否计入慢查询日志
log_throttle_queries_not_using_indexes：如果启用 log_queries_not_using_indexes 参数则它会限制每 60 秒内可写入慢查询日志的查询语句次数
log_slow_admin_statements：是否把慢管理语句也计入慢查询日志
log_slow_slave_statements：是否把从库执行慢的语句计入从库的慢查询日志中
expire_logs_days：二进制日志保存天数，设置过大会占用大量磁盘，过小有丢失数据风险
binlog_rows_query_log_events：binlog_format=row 时控制是否记录用户原生 SQL 的参数到 binlog文件中
log_slave_updates：从库同步的主库的操作，是否记录到binlog
general_log:是否开启普通日志，生产中不打开，日志量大，消耗性能、占用空间
log_bin：是否开启binlog
sql_log_bin:是否开启对二进制日志的日志记录功能
log_bin_index：binlog 索引文件的路径+名称
log_syslog_tag：指定要添加到服务器标识符的标记，该标记用于将 mysql 的错误日志输出到系统日志中，除非启用了 log_syslog 系统变量，否则指定此变量的值无效
log_syslog：是否将错误日志输出写入 syslog
log_error：错 误 日 志 的 位 置
log_error_verbosity：错误日志的详细等级
log_warnings：是否向错误日志记录额外的警告信息
log_output：普通查询日志和慢查询日志输出的目的地
min_examined_row_limit：查询语句在存储引擎中检查的数据行数超过了这个变量的行数时，就会被记录到慢查询中（0表示不限制返回记录数量）
log_short_format：控制慢查询的长度
transaction_write_set_extraction：生成与写入事务关联的哈希算法。 在组复制架构中，哈希值将用于分布式冲突检测和处理。所以 64 位系统上运行组复制架构，建议将其设置为 XXHASH64，以避免不必要的哈希冲突导致用户事务认证失败回滚
binlog_transaction_dependency_tracking：控制事务依赖模式，让从库根据主库写入 binlog 中的 commit timestamps 或者 write sets 并行回放事务（引入该参数之后，binlog 的格式记录的内容中增加了时间戳和write sets 信息）
binlog_transaction_dependency_history_size：最近发生数据修改的事务在内存中保存的用于计算 hash 值的最大数据行数，达到上限之后，历史记录将被清除
---innodb设置参数---
innodb_buffer_pool_size：InnoDB存储引擎表的数据和索引的最大缓存区大小，和MyISAM不同，InnoDB的缓存池是同时缓存数据和索引，在保证操作系统和其它程序有足够内存的情况下，这个参数越大越好，缓存命中率越高，访问磁盘 I/O 就越少，性能也就越高，在一个专用的数据库服务器上，最大可以将 80%的物理内存分配给这个参数，但是要注意，别过大而导致使用 swap
innodb_buffer_pool_instances：调整缓存池实例数量，减少内部对缓存池数据结构的争用
innodb_buffer_pool_dump_at_shutdown：停止 MySQL 服务时，InnoDB 将 InnoDB 缓冲池中的热数据页列表保存到硬盘中，默认保存在共享表空间文件路径下的 ib_buffer_pool 文件
innodb_buffer_pool_load_at_startup：在 mysqld 启动之后，重新加载缓冲池热数据页列表 ib_buffer_pool 文件中保存的热数据到内存
innodb_buffer_pool_load_now：立即载入 datadir 下的 ib_buffer_pool 文件中的页面到缓冲池中，将热点数据页立即加载到 buffer pool 中，以迅速恢复数据库的最佳性能
innodb_buffer_pool_load_abort：中断由 innodb_buffer_pool_load_at_startup 或 innodb_buffer_pool_load_now 触发的加载 InnoDB 缓冲池内容（ib_buffer_pool 文件）的恢复过程
innodb_io_capacity：InnoDB 后台任务执行的 I/O 活动的上限，例如从缓冲池刷新页面以及从更改缓冲区合并数据。
InnoDB_flush_method：InnoDB 数据文件及 redo log 的打开、刷写模式
innodb_file_format：InnoDB 的文件格式，目前支持 barracuda、antelope 两种，配置为 antelope 时InnoDB 表可以使用 redundant 和 compact 两种行格式，配置为 barracuda 时，可以使用 redundant 和 compact，compressed 和 dynamic 四种行格式
innodb_flush_neighbors：开启与关闭刷新邻接页功能（buffer pool 中相对于磁盘上相同的区中的脏页）
innodb_log_file_size：redo log 单个文件的大小
innodb_thread_concurrency：控制同时有多少个线程进入 InnoDB 内核
innodb_write_io_threads：内部写线程数量参数
innodb_read_io_threads：内部读线程数量参数
innodb_file_per_table：表是否使用独立表空间
innodb_autoinc_lock_mode：自增长锁模式参数
innodb_open_files：限制一次打开表空间文件.ibd 文件描述符数量，只在使用独立表空间时才有用，范围 10~4294967295
innodb_adaptive_hash_index：自适应哈希索引特性是否开启参数
innodb_data_file_path：指定共享表空间文件的路径和名称，初始值大小，是否自动扩展
innodb_doublewrite：双写机制是否打开
innodb_fast_shutdown：mysqld 的关闭模式，决定了关闭的速度
innodb_flush_log_at_trx_commit：redo buffer 何时刷新到磁盘日志文件
innodb_lock_wait_timeout：事务请求行锁的超时时间限制参数
innodb_locks_unsafe_for_binlog：影响 MySQL 的 gap lock 查找和索引扫描的参数
innodb_deadlock_detect：控制是否禁用死锁检测
innodb_max_dirty_pages_pct：buffer pool 中的最大脏页比例，InnoDB 会尝试刷新脏页，以使得 buffer pool中的脏页比例不高于这个比例
innodb_max_dirty_pages_pct_lwm：控制脏页刷新的速率，定义了脏页比例的低水位标记，表示启用预刷新活动的脏页的百分比，以控制脏页率。
innodb_rollback_on_timeout：是否在等待超时后对进行中的事务进行回滚操作
innodb_sort_buffer_size：表在创建索引期间对数据排序的排序缓冲区的大小
innodb_support_xa：是否打开 mysql 内部 XA 事务（两阶段提交机制）
innodb_buffer_pool_dump_now：立即记录缓存在 InnoDB 缓冲池中的页面到 datadir 下的 ib_buffer_pool 文件中。通常与 innodb_buffer_pool load_now 结合使用
innodb_buffer_pool_dump_pct：要读取并转储的每个缓冲池最近使用的页面的百分比
innodb_buffer_pool_filename：保存由innodb_buffer_pool_dump_at_shutdown或innodb_buffer_pool_dump_now参数触发的导出 buffer pool 时生成的表空间 ID 和页面 ID 列表的文件的名称
innodb_print_all_deadlocks：是否将死锁信息记录到错误日志中。默认情况下，死锁信息只能通过 show engine innodb status 语句查看，且该语句中只记录了最后一次死锁信息，如果后续再发生死锁，前一次的死锁信息将被覆盖。
innodb_status_output：启用或禁用标准 InnoDB monitor 的周期性输出。与 innodb_status_output_locks 组合使用以启用或禁用 InnoDB Lock Monitor 的周期性输出。
innodb_status_output_locks：启用或禁用 InnoDB Lock Monitor
innodb_table_locks：是否启用 InnoDB 表级锁
innodb_strict_mode：是否启用 InnoDB 严格模式，如果启用，InnoDB 在某些条件下返回错误而不是警告
innodb_undo_log_truncate：是否启用 undo log 自动收缩
innodb_max_undo_log_size：undo log 表空间触发自动收缩的触发阈值大小
innodb_purge_rseg_truncate_frequency：purge 线程清除系统释放回滚段的频率，undo log 表空间在其对应的回滚段被释放之前是不能被回收的
innodb_undo_directory：设置独立于系统表空间的 undo logs 文件存放路径
innodb_undo_logs：回滚段数
innodb_undo_tablespaces：使用多少个独立 undo log 表空间文件来存放分配给事务数据修改使用的回滚段数量
innodb_purge_batch_size：从历史列表中一次批量清除的 undo log 日志页数
innodb_stats_method：收集有关 InnoDB 表索引值分布的统计信息时，服务器如何处理 NULL 值
innodb_stats_auto_recalc：InnoDB 引擎表中的数据发生显著变化后会自动重新计算持久性统计信息
innodb_stats_include_delete_marked：在计算持久性统计信息时，InnoDB 把打有删除标记的记录包含进来
innodb_stats_on_metadata：用于非持久化统计信息
innodb_stats_persistent：是否将 InnoDB 索引统计信息持久化磁盘中
innodb_stats_persistent_sample_pages：估算索引列的基数和其他统计信息时的采样索引页数，例如由 ANALYZE TABLE触发的计算索引统计信息时的采样索引页数。
innodb_stats_transient_sample_pages：估算索引列基数和其他统计信息时的采样索引页数
innodb_page_size：表空间的页面大小
innodb_page_cleaners：从缓冲池实例刷新脏页的页面清理线程数。页面清理线程执行 flush 列表和 LRU 刷新。
innodb_change_buffering：哪些数据变更操作需要执行缓冲，change buffer 优化可以将辅助索引的写入操作延迟，先缓存到 change buffer 中，以便可以顺序执行 I/O 操作
innodb_max_purge_lag：当 purge 操作滞后时如何延迟 INSERT，UPDATE 和 DELETE 操作。默认值为0，表示不延迟 DML 操作
innodb_max_purge_lag_delay：由 innodb_max_purge_lag 系统参数指定阀值触发的延迟执行后的最大延迟时间（以毫秒为单位）
innodb_default_row_format：InnoDB 表和用户显式创建的临时表的默认行格式
innodb_flush_sync：开启该参数时，在做 checkpoint 时，发生 I/O 突增时，会忽略 innodb_io_capacity 设置的值，全速 I/O 做 checkpoint
innodb_numa_interleave：是否启用 NUMA 交 错 内存策略来分配 InnoDB 缓冲池
innodb_read_only：以只读模式启动 InnoDB
innodb_online_alter_log_max_size：在 InnoDB 表 online DDL 操作期间用于保存 DML 操作数据的临时日志文件大小的上限
innodb_tmpdir：online ddl 需要重建表操作期间创建的临时排序文件的交换目录
innodb_change_buffer_max_size：在 buffer pool size 中用于 change buffer 的内存比例，如果你 DML 操作频繁而select 少，那么你可能需要调整这个比例值以优化 I/O 操作
innodb_log_buffer_size：redo log 日志文件的缓冲区大小（以字节为单位）
---复制设置参数---
master_info_repository：I/O 线程的对应的 master status 和 master connection 信息保存在master.info 文件中或者保存在 mysql.slave_master_info 表中
sync_master_info：I/O线程读取了主库的多少个binlog events之后把I/O线程信息保存到磁盘中，该变量依赖于 master_info_repository 的设置
sync_relay_log：I/O 线程读取主库 binlog 往 relay log 中写了多少个 events 的时候就调用fdatasync()把 binlog 数据同步到 relay log 磁盘文件中，如果为 0表示等到操作系统刷到磁盘
relay_log_info_repository：是否把 SQL 线程对应的 master status 以及从库 relay log 位置保存在relay-log.info 文件中或者mysql.slave_relay_log_info 表中
sync_relay_log_info：多少个事务或者 event 之后把 relay log 信息刷新到磁盘
relay_log_recovery：从库挂掉之后如何恢复复制及其 relay log
sync_binlog：binlog刷盘机制
gtid_mode：是否开启gtid
enforce_gtid_consistency：是否启用强制 GTID 一致性
binlog_format：binlog日志记录格式
max_binlog_size：二进制日志文件的最大值
slave_parallel_workers：从库 SQL 线程并行重放 events(事务)的 worker 线程数量（在 MySQL cluster 中不支持多线程复制，如果设置了则会自动忽略）
binlog_row_image：决定了binlog中记录的内容的完整性
max_binlog_cache_size：事务语句的总的最大 binlog 缓存大小
binlog_cache_size：每个会话的最大binlog缓存
max_binlog_stmt_cache_size：非事务语句总的 binlog cache 大小
binlog_stmt_cache_size：非事务语句的 binlog cache 大小
slave_parallel_type：从库使用多线程复制时并行执行事务的策略
slave_rows_search_algorithms：在基于行的主备复制中，如何搜索匹配行，即使用主键或唯一键，某个其它 key 或无 key 的搜索是否可以使用散列算法匹配行
binlog-row-event-max-size：row 格式下，binlog event 的最大大小
binlog_group_commit_sync_delay：在将二进制日志文件同步到磁盘之前等待多少微秒以把事务合并到一个 binlog group 中一次性提交。
binlog_group_commit_sync_no_delay_count：在 binlog-group-commit-sync-delay 指定的延迟时间之内，一次组提交允许等待的最大事务数量，达到该参数指定的事务数量即进行组提交，不会再进行等待
slave_preserve_commit_order：控制从库并行复制时，重放 binlog 是否完全按照主库的提交顺序进行提交
log_bin_trust_function_creators：MySQL 对存储函数和触发器创建的限制
binlog_checksum：主库为二进制日志中的每个事件写入校验和
master_verify_checksum：如果启用，则主库使用二进制日志中的事件长度来验证事件，以便从库从二进制日志读取完整的事件（从库也需要同时使用参数 slave_sql_verify_checksum=ON 来打开校验 checksum 的功能），此时，如果读取到 checksum 不匹配的 events 时就会报错终止复制
binlog_error_action：当服务器无法写入二进制日志时如何处理，这可能会导致主库日志变得不一致，并且从库复制不同步
slave_net_timeout：备库等待主库发送数据的超时时间，如果超过这个时间主库还未发送任何消息，则从库认为主库的 master/slave 连接已经断开了，开始尝试重连操作，重连操作的间隔时间以及重试次数由 change master 的 MASTER_CONNECT_RETRY 和MASTER_RETRY_COUNT 参数在做 change master 语句的时候指定
server_id：复制架构中全局唯一标识实例的数字编号
relay_log_purge：是否在 sql 线程重放完 relay log 之后，把对应的 relay log 自动清理掉
relay_log_index：中继日志的索引文件名称和路径
relay_log：relay log 的路径和文件名
gtid_next：如何获取 GTID 号
slave_load_tmpdir：从库创建临时文件的目录
gtid_purged：所有已经从二进制日志中清除的事务集合
binlog_gtid_simple_recovery：在 MySQL 启动或重新启动时，在搜索二进制日志中的 GTID 期间如何迭代扫描二进制日志文件
gtid_executed：当前 server 中已经提交的事务的 GTID
gtid_executed_compression_period：执行了该变量指定的事务数量之后，执行一次压缩mysql.gtid_executed 表，如果为 0 表示不压缩 mysql.gtid_executed 表
gtid_owned：此变量保存的 GTID 集合值取决于其作用范围，当使用会话级别查看时，该变量显示包含该客户端的所有 GTID 集合; 当使用全局级别查看时，该变量显示 server 中所有的 GTID 集合
binlog_order_commits：主库中 binlog 的提交顺序是否需要和 redo log 的提交顺序保持一致
---半同步设置参数---
rpl_semi_sync_master：半同步复制在 master 上使用的库文件名称，不需要使用路径
rpl_semi_sync_master_enabled：是否在主库上启用半同步复制插件
rpl_semi_sync_master_timeout：当参数 rpl_semi_sync_master_enabled 开启时，该参数控制主库使用半同步复制机制把 binlog 发送到 slave 之后，等待从库 ACK 接收确认包的时间，如果在这个超时时间之内收到 slave 的接收确认包，则继续使用半同步复制机制同步下一个事务的binlog 到从库，如果在这个超时时间之内未收到任何 slave 的接收确认包，则主库自动切换为异步复制
rpl_semi_sync_master_trace_level：在 master 控制半同步复制中的 debug 信息跟踪等级
rpl_semi_sync_master_wait_no_slave：在 rpl_semi_sync_master_timeout 超时周期内，如果连接主库的从库数量降到 0值，主库是否要继续等待从库的接收确认包
rpl_semi_sync_slave：半同步复制在 slave 上使用的库文件名称，不需要使用路径
rpl_semi_sync_slave_enabled：是否在从库上启用半同步复制插件
rpl_semi_sync_slave_trace_level：slave控制半同步复制中的 debug 信息跟踪等级
rpl_semi_sync_master_wait_for_slave_count:主库需要接收到多少个从库的 ACK 确认之后，主库的事务才进行提交
rpl_semi_sync_master_wait_point:控制半同步复制中主库在发起事务 commit 操作之后在什么节点等待从库接收 binlog 的 ACK 确认