MYSQL SERVER
- table_definition_cache
表定义缓存，数据字典，与存储引擎无关
最小400 最大2000
default value=min(400+table_open_cache/2,2000) - table_open_cache
open table实例缓存，关连到具体存储引擎。每当MySQL访问一个表时，如果table_open_cache 中未找到，在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。
通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加table_open_cache的值。
如果你发现open_tables等于table_open_cache，并且opened_tables在不断增长，那么你就需要增加table_open_cache的值了(上述状态值可通过SHOW GLOBAL STATUS LIKE ‘Open%tables’获得)。
BINLOG
-
log_bin
设置此参数表示启用binlog功能，并指定路径名称 -
log_bin_index
设置此参数是指定二进制索引文件的路径与名称 -
binlog_format
row|statment|mixed，相应地，基于这三种模式的Replication分别称为SBR(STATEMENT BASED Replication)、RBR、MBR -
binlog_do_db
此参数表示只记录指定数据库的二进制日志 -
binlog_ignore_db
此参数表示不记录指定的数据库的二进制日志 -
binlog_cache_size
此参数表示binlog使用的内存大小，可以通过状态变量binlog_cache_use和binlog_cache_disk_use来监控、评估 -
binlog_cache_use：
使用二进制日志缓存的事务数量 -
binlog_cache_disk_use
使用二进制日志缓存但超过binlog_cache_size值并使用临时文件来保存事务中的语句的事务数量 -
max_binlog_cache_size
此参数表示单个事物binlog最大大小
它指定是一个临时磁盘文件存储由于binlog cache不足溢出的binlog event，其名字由"ML"打头，是事物级别的参数 -
max_binlog_size Binlog
文件最大值，最大和默认值是1GB，该设置并不能严格控制Binlog的大小，尤其是Binlog比较靠近最大值而又遇到一个比较大事务时，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进当前日志，直到事务结束 -
log_slave_updates
NO SQL_THREAD应用主库的LOG时，写入本SERVER的BINLOG
OFF SQL_THREAD应用主库的LOG时，不写入本SERVER的BINLOG -
sync_binlog
控制写binlog刷盘频率，这个参数直接影响mysql的性能和完整性
sync_binlog = 0：禁止MySQL服务器将二进制日志同步到磁盘。取而代之的是，MySQL服务器依赖操作系统将二进制日志不时地刷新到磁盘上，就像处理其他任何文件一样。此设置提供最佳性能，但是在电源故障或操作系统崩溃的情况下，服务器可能提交了尚未同步到二进制日志的事务。
sync_binlog = 1：在提交事务之前，将二进制日志同步到磁盘。这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响。如果发生电源故障或操作系统崩溃，二进制日志中缺少的事务将仅处于准备状态。这允许自动恢复例程回滚事务，从而保证二进制日志中不会丢失任何事务。
sync_binlog = N，其中N是0或1以外的值。在收集了N个二进制日志提交组之后，二进制日志将同步到磁盘。在电源故障或操作系统崩溃的情况下，服务器可能提交了尚未刷新到二进制日志的事务。由于磁盘写入次数的增加，此设置可能会对性能产生负面影响。较高的值可以提高性能，但是会增加数据丢失的风险。 -
expire_logs_days
保存的binlog日志的天数, 这个默认是0，也就是logs不过期，可通过设置全局的参数，使他临时生效
INNODB
-
innodb_buffer_pool_size
innodb page缓存,innodb_buffer_pool_size决定InnoDB存储引擎表数据和索引数据的最大缓存区大小。innodb buffer pool同时为数据块和索引块提供数据缓存，若innodb_buffer_pool_size值越大，缓存命中率越高，访问InnoDB表需要的磁盘I/O就越少，性能也就越高
可用以下公式InnoDB缓存池的命中率：
( 1- innodb_buffer_pool_reads/innodb_buffer_pool_read_request) * 100
若太低则应该扩充内存、增加innodb_buffer_pool_size的值 -
innodb_old_blocks_time
innodb buffer pool采用lru管理，保留热块，淘汰老块(最少访问的块),
分为两部分young sublist和old sublist old sublist：young sublist 3:5
innodb_old_blocks_time参数决定了缓存数据块由old sublist转移到young sublist的快慢，当一个缓存数据块被插入到midpoint(old sublist)后，至少要在old sublist停留超过innodb_old_blocks_time(ms)后，才有可能被转移到new sublist.
可以根据InnoDB Monitor的输出信息来调整innodb_old_blocks_time的值，在进行表扫描时，如果non-youngs/s很低，young/s很高，就应考虑将innodb_old_blocks_time适当调大，以防止表扫描将真正的热数据淘汰，此值可以进行动态设置 -
innodb buffer pool的刷新快慢主要取决于两个参数
-
innodb_max_dirty_pages_pct
控制缓存池中脏页的最大比例，默认值是75%，如果脏页的数量达到或超过该值，innoDB后台线程将开台缓存刷新 -
innodb_io_capacity
在某种程度上代表磁盘中每秒可完成的I/O次数，对于转速较低的磁盘，可将innodb_io_capacity降低。对于固态磁盘和由多个磁盘组成的阵列，innodb_io_capacity的值可适当增大
如无法增大缓存池，应将innodb_max_dirty_pages_pct的值调小，将innodb_io_capactity的值提高，以加快脏页的刷新 -
innodb_doublewrite
Command-Line Format: --innodb-doublewrite[={OFF|ON}]
Default Value: ON
由于同步到doublewrite buffer是对连续磁盘空间的顺序写，因此开启双写对性能的影响并不太大。对需要高性能并且可以容忍丢失数据的应用，可将innodb_doublewrite=0来关闭双写以满足性能 -
innodb_doublewrite_batch_size
Command-Line Format --innodb-doublewrite-batch-size=#
Introduced 8.0.20
Dynamic No
Default Value 0
Minimum Value 0
Maximum Value 256
控制要批量写入的双写页面的数量。 此变量用于高级性能调整。 默认值应适合大多数用户。 -
innodb_doublewrite_files
Command-Line Format --innodb-doublewrite-files=#
Introduced 8.0.20
Minimum Value 2
Maximum Value 256
定义双写文件的数量。 默认情况下，为每个缓冲池实例创建两个双写文件：刷新列表双写文件和LRU列表双写文件。 -
innodb_fast_shutdown
Command-Line Format --innodb-fast-shutdown=#
Dynamic Yes
Default Value 1
Valid Values 1,2,3
如果值为0，则InnoDB会执行 slow shutdown，在shutdown之前执行full purge和change buffer merge，然后再关闭。
如果值为1（默认值），则InnoDB将在关机时跳过这些操作，该过程称为fast shutdown。
如果值为2，则InnoDB刷新其日志并关闭冷启动，就好像MySQL崩溃了一样。 不会丢失任何已提交的事务，但是崩溃恢复操作会使下次启动花费更长的时间。
slow shutdown可能需要几分钟，甚至在仍然缓冲大量数据的极端情况下，甚至需要数小时。 在MySQL主要版本之间进行升级或降级之前，请使用slow shutdown技术，以便为所有数据文件做好充分准备，以防升级过程更新文件格式。
在紧急情况或故障排除情况下，使用innodb_fast_shutdown = 2可以绝对绝对最快地关闭数据，如果有损坏数据的危险。 -
innodb_flush_log_at_trx_commit
0：每秒触发一次，可满足持久化要求（效率最高，但最不安全）
1：每个事务提交时立刻将缓存中的redo日志回写到日志文件，并调用操作系统fsync刷新IO缓存（默认值，效率最低，但最安全）
2：每个事务提交时,InnoDB立刻将redo日志回写到日志文件，但并不马上调用fsync来刷新IO缓存，而是每秒只做一次磁盘IO缓存刷新操作（性能和数据安全性都在中间） -
innodb_file_per_table
Command-Line Format --innodb-file-per-table[={OFF|ON}]
Dynamic Yes
Default Value ON
启用innodb_file_per_table时，默认情况下在每个表文件表空间中创建表。 禁用后，默认情况下在系统表空间中创建表。 -
sort_buffer_size
若查看show global status看到sort_merge_passes的值很大，则可以调整参数sort_buffer_size的值来调整排序缓存区，以改善order by子句或group子句的sql性能,该参数为每线程 -
join_buffer_size
可通过调整join_buffer_size的值来改善没使用索引的查询,该参数为每线程
最好的策略是设置较小的全局join_buffer_size,对较复杂的操作session单独设置join_buffer_size -
innodb_flush_log_at_trx_commit
0：每秒触发一次，可满足持久化要求（效率最高，但最不安全）
1：每个事务提交时立刻将缓存中的redo日志回写到日志文件，并调用操作系统fsync刷新IO缓存（默认值，效率最低，但最安全）
2：每个事务提交时,InnoDB立刻将redo日志回写到日志文件，但并不马上调用fsync来刷新IO缓存，而是每秒只做一次磁盘IO缓存刷新操作（性能和数据安全性都在中间）
GTID
REPLICATE
- slave_parallel_type
并行应用类型
开始支持，并行复制的模式。默认DATABASE，表示库级别的并行复制；LOGICAL_CLOCK：基于组提交的并行复制方式。可选值：DATABASE、LOGICAL_CLOCK
表示多线程复制的模式，5.6开始支持基于库（database）的并行复制，对于只有一个库的，效果不好。5.7开始支持基于组提交（LOGICAL_CLOCK）的并行复制，提高复制的可用性。 - slave_parallel_workers
并行线程数，不建议设置大于CPU CORES - slave_preserve_commit_order
全局动态变量，默认0，可选值0、1。表示是否需要严格保持顺序，默认值为0表示并发执行忽略顺序。对于多线程slaves，来保障事务在slave上执行的顺序与relay log中的顺序严格一致，只有当slave_parallel_workers开启时有效，此时log_bin、log_slave_updates必须开启，而且slave_parallel_type值必须为LOGICAL_CLOCK（默认值为DATABASE），如果你的事务经常是跨DB操作，那么可以考虑使用此参数限定顺序。当此参数开启时，要求任何worker线程执行事务时，只有当前事务中此之前的所有事务都执行后（被其他worker线程执行），才能执行和提交。 - super_read_only
全局动态变量，默认OFF。5.7.8之后支持的参数。
表示5.7.8之前，服务器开启read_only参数，表示只有具有super权限的账号可以更新、修改表。非super权限的用户不能修改。5.7.8之后，开启super_read_only参数，具有super权限的账号也不能更新和修改表，并且read_only会无效（受super_read_only控制） - master_info_repository=TABLE;
- relay_log_info_repository=TABLE;
- rpl_semi_sync_master_wait_point
5.7引入
AFTER_SYNC (默认值):master 将每个事务写入binlog ,传递到slave，并且刷新到磁盘。master等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈，master在主库提交事务并且返回结果给会话。 在AFTER_SYNC模式下，所有的客户端在同一时刻查看已经提交的数据。假如发生主库crash，所有在主库上已经提交的事务已经同步到slave并记录到relay log。此时切换到从库，可以保障最小的数据损失。
AFTER_COMMIT: master 将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，然后在主库提交事务。master在提交事务后等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈，master将结果反馈给客户端。
在AFTER_COMMIT模式下,如果slave 没有应用日志,此时master crash，系统failover到slave，app将发现数据出现不一致，在master提交而slave 没有应用
解决了5.6 半同步复制幻读的问题
半同步复制
- MySQL5.6
show global variables like '%semi%';
+------------------------------------+-------+
| Variable_name | Value |
+------------------------------------+-------+
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_no_slave | ON |
+------------------------------------+-------+
4 rows in set (0.00 sec)
- MySQL5.7
show global variables like '%semi%';
+-------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
+-------------------------------------------+------------+
