zoukankan      html  css  js  c++  java
  • (转)MySQL 参数详解

    原文:https://www.db2go.net/mysql/3.parameterintro.html

    一、参数的查看、分类及修改

    1.分类

    全局参数(GLOBAL) : 可以查看information_schema.GLOBAL_VARIABLES 与会话参数(session):可以查看information_schema.SESSION_VARIABLES 可修改参数与不可修改参数

    • 用户可以在线修改非只读参数,只读参数需要预先设置在配置文件中,重启后方能生效,有点类似于Oracle的pfile
    • 所有在线修改的参数(global/session)重启后都会丢失

    2.查看show variables

    不加like则是显示全部

    mysql> show variables like '%commit%';
    +-----------------------------------------+-------+
    | Variable_name                           | Value |
    +-----------------------------------------+-------+
    | autocommit                              | ON    |
    | binlog_group_commit_sync_delay          | 0     |
    | binlog_group_commit_sync_no_delay_count | 0     |
    | binlog_order_commits                    | ON    |
    | innodb_api_bk_commit_interval           | 5     |
    | innodb_commit_concurrency               | 0     |
    | innodb_flush_log_at_trx_commit          | 1     |
    | slave_preserve_commit_order             | OFF   |
    +-----------------------------------------+-------+
    8 rows in set (0.00 sec)
    

    3.修改参数

    3.1 设置全局参数:

    mysql> set global max_connect_errors=20000;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> set max_connect_errors=20000;
    ERROR 1229 (HY000): Variable 'max_connect_errors' is a GLOBAL variable and should be set with SET GLOBAL
    mysql>
    

    3.2 设置session参数:

    mysql> set NET_RETRY_COUNT=15;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> show variables like 'NET_RETRY_COUNT';
    +-----------------+-------+
    | Variable_name   | Value |
    +-----------------+-------+
    | net_retry_count | 15    |
    +-----------------+-------+
    1 row in set (0.00 sec)
    

    3.3 有些参数既是global的也是session的,可以用如下sql查看

    select * from information_schema.GLOBAL_VARIABLES a,information_schema.SESSION_VARIABLES b where a.VARIABLE_NAME=b.VARIABLE_NAME;
    

    需要注意的是: 加global修改代表是全局,可以在其他session查询到修改的值 不加global修改代表是session,不能在其他session中查询到修改的值

    二、参数详解

    首先强调一下:myisam的相关参数基本可以不用管了,现在没有特殊理由一般都会是采用innodb作为存储引擎,另外生产环境建议关闭query cache,用nosql来代替。

    因为参数众多,因此我拿my.cnf里面配置了的参数来重点说明

    [mysqld]
    ########basic settings########
    server-id = 11
    port = 3306
    user = mysql
    #bind_address = 192.168.0.175
    #autocommit = 0
    character_set_server=utf8mb4
    skip_name_resolve = 1
    max_connections = 800
    max_connect_errors = 100000
    datadir = /u01/mysql/mysql_data/
    transaction_isolation = READ-COMMITTED
    explicit_defaults_for_timestamp = 1
    join_buffer_size = 134217728
    tmp_table_size = 67108864
    tmpdir = /tmp
    max_allowed_packet = 16777216
    sql_mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER"
    interactive_timeout = 1800
    wait_timeout = 1800
    read_buffer_size = 16777216
    read_rnd_buffer_size = 33554432
    sort_buffer_size = 33554432
    lower_case_table_names = 1
    ########log settings########
    log_error = /u01/mysql/log/mysql_error.log
    slow_query_log = 1
    slow_query_log_file = /u01/mysql/log/mysql_slow_query.log
    log_queries_not_using_indexes = 1
    log_slow_admin_statements = 1
    log_slow_slave_statements = 1
    log_throttle_queries_not_using_indexes = 10
    expire_logs_days = 90
    long_query_time = 2
    min_examined_row_limit = 100
    ########replication settings########
    master_info_repository = TABLE
    relay_log_info_repository = TABLE
    log_bin = bin.log
    sync_binlog = 1
    gtid_mode = on
    enforce_gtid_consistency = 1
    log_slave_updates
    binlog_format = row
    relay_log = relay.log
    relay_log_recovery = 1
    binlog_gtid_simple_recovery = 1
    slave_skip_errors = ddl_exist_errors
    ########innodb settings########
    innodb_page_size = 8192
    innodb_buffer_pool_size = 4G
    innodb_buffer_pool_instances = 8
    innodb_buffer_pool_load_at_startup = 1
    innodb_buffer_pool_dump_at_shutdown = 1
    innodb_lru_scan_depth = 2000
    innodb_lock_wait_timeout = 5
    innodb_io_capacity = 4000
    innodb_io_capacity_max = 8000
    innodb_flush_method = O_DIRECT
    innodb_file_format = Barracuda
    innodb_file_format_max = Barracuda
    innodb_log_group_home_dir = /u01/mysql/mysql_redolog/
    innodb_undo_directory = /u01/mysql/mysql_undolog/
    innodb_undo_logs = 128
    innodb_undo_tablespaces = 3
    innodb_flush_neighbors = 1
    innodb_log_file_size = 1G   #注意,生产环境建议调成4G+
    innodb_log_buffer_size = 16777216
    innodb_purge_threads = 4
    innodb_large_prefix = 1
    innodb_thread_concurrency = 64
    innodb_print_all_deadlocks = 1
    innodb_strict_mode = 1
    innodb_sort_buffer_size = 67108864
    ########semi sync replication settings########
    plugin_dir=/usr/local/mysql/lib/plugin
    plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
    loose_rpl_semi_sync_master_enabled = 1
    loose_rpl_semi_sync_slave_enabled = 1
    loose_rpl_semi_sync_master_timeout = 5000
    
    [mysqld-5.7]
    innodb_buffer_pool_dump_pct = 40
    innodb_page_cleaners = 4
    innodb_undo_log_truncate = 1
    innodb_max_undo_log_size = 2G
    innodb_purge_rseg_truncate_frequency = 128
    binlog_gtid_simple_recovery=1
    log_timestamps=system
    transaction_write_set_extraction=MURMUR32
    show_compatibility_56=on
    

    根据上面的标签来

    1.基本设置的相关参数

    ########basic settings########
    server-id = 11
    port = 3306
    user = mysql
    #bind_address = 192.168.0.175
    #autocommit = 0
    character_set_server=utf8mb4
    skip_name_resolve = 1
    max_connections = 800
    max_connect_errors = 100000
    datadir = /u01/mysql/mysql_data/
    transaction_isolation = READ-COMMITTED
    explicit_defaults_for_timestamp = 1
    join_buffer_size = 134217728
    tmp_table_size = 67108864
    tmpdir = /tmp
    max_allowed_packet = 16777216
    sql_mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER"
    interactive_timeout = 1800
    wait_timeout = 1800
    read_buffer_size = 16777216
    read_rnd_buffer_size = 33554432
    sort_buffer_size = 33554432
    

    server-id

    • MySQLl server唯一标示,一般以服务器IP的后两位就可以
    • 在主从同步中使用
    • MySQL的同步的数据中是包含server-id的,用于标识该语句最初是从哪个server写入的,所以server-id一定要有的
    • 每一个同步中的slave在master上都对应一个master线程,该线程就是通过slave的server-id来标识的;每个slave在master端最多有一个master线程,如果两个slave的server-id 相同,则后一个连接成功时,前一个将被踢掉。 这里至少有这么一种考虑:slave主动连接master之后,如果slave上面执行了slave stop;则连接断开,但是master上对应的线程并没有退出;当slave start之后,master不能再创建一个线程而保留原来的线程,那样同步就可能有问题;
    • 在mysql做主主同步时,多个主需要构成一个环状,但是同步的时候有要保证一条数据不会陷入死循环,这里就是靠server-id来实现的。

    port = 3306

    • MySQLl使用的端口
    • 默认为3306

    user = mysql

    • 用户

    bind_address

    bind_address = 192.168.0.175

    • 绑定的IP地址

    autocommit

    autocommit = 0

    • 事务处理的自动提交模式。默认值为 1,因此自动提交功能是启用的,并且语句会立即生效。本质上,每条语句都是其自身的事务。将这个值设置为 0,可以禁用自动提交功能,如此一来,后续语句便只有等到提交完成(可以使用 COMMIT 语句,或者将 autocommit 设置为1来完成提交)之后才能生效。如果提交还未发生,则可以通过 ROLLBACK 来取消事务里的语句。将 autocommit 这时为1,可以重新启用自动提交(并且会隐式提交所有挂起的事务)。

    character_set_server

    character_set_server=utf8mb4

    • 服务器的默认字符集
    • 一般和collation_server(服务器默认字符集所对应的默认排序方式,启动:直接设置;作用范围:全局、会话;动态)对应一样

    skip_name_resolve

    skip_name_resolve = 1

    • 此参数默认是禁用的。
    • 启用它之后,可以禁止主机名解析,并且在权限表里必须通过IP地址或使用localhost来指定这些主机。

    skip_networking

    • 默认是禁用此参数,表示服务器允许使用TCP/IP连接。
    • 如果启用它,则会禁用TCP/IP连接。客户端只可以从本地主机进行连接,且必须使用非TCP/IP接口。
    • Unix客户端可使用Unix套接字文件。
    • Windows客户端可以使用共享内存或命名管道(如果这些链接类型被弃用了的话)连接。

    max_connections

    max_connections = 800

    • 客户端连接的最大并发数。
    • 默认值为151。

    max_connect_errors

    max_connect_errors = 100000

    • 默认值为10,也即mysqld线程没重新启动过,一台物理服务器只要连接 异常中断累计超过10次,就再也无法连接上mysqld服务,为此建议大家设置此值至少大于等于10W
    • 一个MySQL中与安全有关的计数器值,它负责阻止过多尝试失败的客户端以防止暴力破解密码的情况。
    • max_connect_errors的值与性能并无太大关系
    • mysqladmin flush-hosts命令来解锁已经被屏蔽的主机,参考状态参数Connect_errors_xxx。

      datadir

      datadir = /u01/mysql/mysql_data/
    • 数据文件目录

    transaction_isolation

    transaction_isolation = READ-COMMITTED

    • 默认为 REPEATABLE READ
    • 事务隔离级别设置的不同,对二进制日志登记格式影响非常大
    • 关于MySQL的事务处理及隔离级别:READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE

    explicit_defaults_for_timestamp

    explicit_defaults_for_timestamp = 1 MySQL 中有这样的一个默认行为,如果一行数据中某些列被更新了,如果这一行中有timestamp类型的列,那么这个timestamp列的数据也会被自动更新到 更新操作所发生的那个时间点;这个操作是由explicit_defaults_for_timestamp这个变更控制的。 explicit_defaults_for_timestamp 参数会直接影响表结构,也就是说explicit_defaults_for_timestamp的作用时间是在表定义的时候。

    在MySQL 5.7版本之前,且在MySQL 5.6.6版本之后(explicit_defaults_for_timestamp参数在MySQL 5.6.6开始加入)的版本中,如果没有设置explicit_defaults_for_timestamp=1的情况下:

    1. 在默认情况下,如果TIMESTAMP列没有显示的指明null属性,那么该列会被自动加上not null属性(而其他类型的列如果没有被显示的指定not null,那么是允许null值的),如果往这个列中插入null值,会自动的设置该列的值为current timestamp值。
    2. 表中的第一个TIMESTAMP列,如果没有指定null属性或者没有指定默认值,也没有指定ON UPDATE语句。那么该列会自动被加上DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP属性。
    3. 第一个TIMESTAMP列之后的其他的TIMESTAMP类型的列,如果没有指定null属性,也没有指定默认值,那么该列会被自动加上DEFAULT ‘0000-00-00 00:00:00’属性。如果insert语句中没有为该列指定值,那么该列中插入’0000-00-00 00:00:00’,并且没有warning。 在MySQL 5.6.6及以后的版本和MySQL 5.7之前的版本中,如果在配置文件中没有指定explicit_defaults_for_timestamp参数,启动时error日志中会报如下警告:
      [Warning] TIMESTAMP with implicit DEFAULT value is deprecated.
      Please use --explicit_defaults_for_timestamp server option (see
      documentation for more details).
      
      如果在启动的时候在配置文件中指定了explicit_defaults_for_timestamp=1,MySQL会按照如下的方式处理TIMESTAMP列:
    4. 此时如果TIMESTAMP列没有显示的指定not null属性,那么默认的该列可以为null,此时向该列中插入null值时,会直接记录null,而不是current timestamp。
    5. 不会自动的为表中的第一个TIMESTAMP列加上DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP属性,除非你在建表的时候显示的指明。
    6. 如果TIMESTAMP列被加上了not null属性,并且没有指定默认值。这时如果向表中插入记录,但是没有给该TIMESTAMP列指定值的时候,如果strict sql_mode被指定了,那么会直接报错。如果strict sql_mode没有被指定,那么会向该列中插入’0000-00-00 00:00:00’并且产生一个warning。

    join_buffer_size

    join_buffer_size = 134217728

    • 当join是all,index,rang或者Index_merge的时候使用的buffer
    • 实际上这种join被称为FULL JOIN
    • 实际上参与join的每一个表都需要一个join buffer
    • 所以在join出现的时候,至少是2个表
    • join buffer的这只在mysql5.1.23版本之前最大为4G,但是从5.1.23版本开始,再出了windows之外的64为平台上可以超出4GB的限制
    • 系统默认是128KB

    tmp_table_size

    tmp_table_size = 67108864

    • MySQL内部使用的各种临时表(即服务器在处理SQL语句的过程中自动创建的表)的最大允许长度。
    • 如果某个临时表的长度超过了max_heap_table_size和tmp_table_size当中较小的那个值,那么服务器会把它从内部内存表转换为MyISAM表,保存到磁盘上。
    • 如果有足够多的内存的话,那么增大此参数的值可以使服务器在内存里维护更大的临时表,而不必把它们转换为磁盘文件格式。

    tmpdir

    tmpdir = /tmp

    • 服务器用于创建临时文件的那个目录的路径名。
    • 此参数的值可以是一个目录列表,它们将轮换着使用。
    • 在Unix里,目录名之间使用冒号(:)隔开;在Windows里,目录名之间需要用分号(;)隔开。

    net_buffer_length

    • 它指的是服务器与客户端程序进行通信时使用的连接和结果缓冲区的初始大小
    • 此缓冲区可以扩展到max_allowed_packet个字节大小
    • 参数的取值范围是1KB~1MB
    • 默认为16KB
    • 会话值是只读的

    max_allowed_packet

    max_allowed_packet = 16777216

    • 服务器和客户之间通讯的使用的缓冲区长度
    • 该缓冲区的初始大小为net_buffer_length个字节,但是会根据需要增大到max_allowed_packet个字节
    • 这个值也会限制MySQL服务器所能处理的字符串的最大长度
    • 此参数的默认值和最大值分别是1MB和1GB
    • 它的会话值是只读的

    sql_mode

    sql_mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER"

    • 服务器的SQL模式。
    • 这个参数将改变MySQL服务器的某些行为,使它更符合SQL语言标准或是与其他数据库服务器或老版本的MySQL服务器保持兼容。此参数的值应该是一个空串(这将清除以前设置的SQL模式)或者是由下面将要介绍的一个或多个模式值以逗号分隔而构成的一系列值。
    • 自MySQL 5.6.6起,其默认值为NO_ENGINE_SUBSTITUTION;而对于之前的版本,其值为空串。
    • 有些模式值很简单,它们可以单独使用以启用某种特定的行为。
    • 其他的则是复合模式,每种复合SQL模式涵盖多种简单SQL模式,这使得用于可以方便地一次设置多种SQL模式。
    • 模式值不区分大小写。

    下面列出了一些简单的SQL模式值。

    • ALLOW_INVALID_DATES:在严格模式里,禁止对DATE和DATETIME值进行全面的日期有效性检查。唯一的要求是月份的取值范围必须为1~12,日期的取值范围必须为1到31。但是TIMASTAMP值是个例外:不管是否启用了这个SQL模式,它们都必须是有效的。
    • ANSI_QUOTES:把双引号自负解释为供标识符(如数据库名、表名和列名)使用的引号字符,而不是供字符串使用的引号字符。(不管这个模式是否启用,都可以用反引号来当作名字的引号字符。)
    • ERROR_FOR_DIVISION_BY_ZERO:对于行插入或修改操作,即使是在严格模式下,以零为除数的出发(或求余数)运算得到的结果通常是NULL,且不会返回任何警告信息。启用ERROR_FOR_DIVISION_BY_ZERO模式将更改这种行为。如果没有启用严格模式,那么以零为除数时结果将为NULL值,但会返回一条警告信息;如果启用了严格模式,那么在执行INSERT或UPDATE语句期间遇到以零为除数的情况时,将产生一个错误,并且该语句会失败。如果想要禁止在插入或更新是出现错误,并且产生一个NULL值和警告信息,可以使用INSERT IGNORE或UPDATE IGNORE。
    • HIGH_NOT_PRECEDENCE:此模式可以更改NOT操作符的优先级,使其与!操作符的优先级相同。
    • IGNORE_SPACE:让服务器忽略内建函数名与引入参数表的那个左括号“(”之间的空格。默认情况下,那个左括号必须紧跟在函数名的后面,其中间不允许有间隔。此模式会使函数名被当作保留字。
    • NO_AUTO_CREATE_USER:防止GRANT语句创建不安全的新账户。也就是说,如果某个账户不存在,那么GRANT会执行失败,并且不会创建账户,除非该语句包含一个指定有非空密码的IDENTIFIED BY子句,或者包含有一个指定身份验证插件的IDENTIFIED WITH子句。
    • NO_AUTO_VALUE_ON_ZERO:通常情况下,把0插入一个AUTO_INCREMENT列,等效于插入NULL值:MySQL将自动生成下一个序列编号,并把它保存在该列里。如果启用了此模式,那么往AUTO_INCREMENT列里插入0将会把数字0存入该列。
    • NO_BACKSLASH_ESCAPES:如果启用了这个模式,那么反斜线字符(“”)将被当作一个没有特殊含义的普通字符,而不是当作一个字符串的转义字符。
    • NO_DIR_IN_CREATE:忽略CREATE TABLE和ALTER TABLE语句时,该模式所指定的存储引擎不可用——此时,这个模式便决定着服务器将如何处理它们。如果启用了此模式,那么会出现一个错误,并且该表不会被创建(或更改)。如果禁用了此模式,那么允许替换为默认的存储引擎。
    • NO_ZERO_DATE:在严格模式下,拒绝接收’0000-00-00’作为一个有效日期值通常情况下,MySQL允许存储“零”日期值。这个模式可以通过使用INSERT IGNORE语句代替INSERT语句的办法来覆盖。
    • NO_ZERO_IN_DATE:在严格模式下,拒绝接收月或日部分是零的日期值。(年份是零的日期值是允许的。)通常情况下,MySQL允许存储这样的日期值。在非严格模式下,或者如果用户发出的是INSERT IGNORE语句,MySQL将把这样的日期值保存为’0000-00-00’。
    • ONLY_FULL_GROUP_BY:通常情况下,MySQL允许SELECT语句的输出列列表里带有非聚合型列,或者使用不是列在GROUP BY子句里的HAVING子句。例如:select a,b,count(*) from t group by a;
    • ONLY_FULL_GROUP_BY标志要求非聚合型输出列(或HAVING列)都被列在GROUP BY里:select a,b,count(*) from t group by a,b;
    • PAD_CHAR_TO_FULL_LENGTH:通常情况下,服务器在检索CHAR列值时会删除其尾部空格。如果启用了这个模式,MySQL服务器将禁止删除CHAR列的尾部空格,这样,检索到的值的长度就等于列的定义宽度。
    • PIPES_AS_CONCAT:如果启用了这个模式,那么||将被解释为字符串连接操作符,而不会解释为逻辑或。
    • REAL_AS_FLOAT:如果启用了这个模式,那么数据类型REAL将于FLOAT同义,而不是等同于DOUBLE。
    • STRICT_ALL_TABLES:如果启用了这个模式,那么所有的存储引擎都将对输入数据做更严格的检查,这将导致MySQL拒绝接收绝大多数非法值。如果想要更加严格,可以使用TRADITIONAL模式。
    • STRICT_TRANS_TABLES:如果启用了这个模式,那么事务型存储引擎将输入数据值做严格的检查,这将导致MySQL拒绝接受绝大多数非法值。在此基础上,只要有可能(例如,遇到插入单个行的INSERT语句),非事务型存储引擎也将对输入数据做严格的检查。如果想要更加严格,可以使用TRADITIONAL模式。

    下表列出的是复合SQL模式,以及每种复合模式所包含的模式内容。

    复合模式                组成模式
    ANSI            ANSI_QUOTES, IGNORE_SPACE, PIPES_AS_CONCAT, REAL_AS_FLOAT
    DB2    ANSI_QUOTES, IGNORE_SPACE, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OOPTIONS, PEPES_AS_CONCAT
    MAXDB    ANSI_QUOTES, IGNORE_SPACE, NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, PEPES_AS_CONCAT
    MSSQL    ANSI_QUOTES, IGNORE_SPACE, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OOPTIONS, PEPES_AS_CONCAT
    MYSQL323            HIGH_NOT_PRECEDENCE, NO_FIELD_OPTIONS
    MYSQL40            HIGH_NOT_PRECEDENCE, NO_FIELD_OPTIONS
    ORACLE    ANSI_QUOTES, IGNORE_SPACE, NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, PEPES_AS_CONCAT
    POSTGRESQL    ANSI_QUOTES, IGNORE_SPACE, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OOPTIONS, PEPES_AS_CONCAT
    TRADITIONAL    ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER, NO_ZERO_DATE, NO_ZERO_IN_DATE, STRICT_ALL_TABLES, STRICT_TRANS_TABLES
    之所以称之为TRADITIONAL模式,是因为它启用这样的模式——它们使得MySQL在处理输入值时,可以表现得像那些会拒绝无效数据的传统数据库一样。它有点像严格模式,但是对于更加严格的检查又包含了几个附加的约束。
    

    interactive_timeout

    interactive_timeout = 1800

    • 交互模式下的没有操作后的超时时间,单位为秒。

    wait_timeout

    wait_timeout = 1800

    • 非交互模式的没有操作后的超时时间,单位为秒。

    read_buffer_size

    read_buffer_size = 16777216

    • 对表进行顺序扫描的那个线程所使用的缓存区的大小
    • 缓冲区会根据每个客户端的需要进行分配

      read_rnd_buffer_size

      read_rnd_buffer_size = 33554432
    • 在排序后,读取结果数据的缓冲区大小

      sort_buffer_size

      sort_buffer_size = 33554432
    • 默认为256KB
    • sort_buffer_size 是一个connection级参数,在每个connection(session)第一次需要使用这个buffer的时候,一次性分配设置的内存。
    • sort_buffer_size 并不是越大越好,由于是connection级的参数,过大的设置+高并发可能会耗尽系统内存资源。例如:500个连接将会消耗 500*sort_buffer_size(8M)=4G内存
    • 当sort_buffer_size 超过2KB的时候,就会使用mmap() 而不是 malloc() 来进行内存分配,导致效率降低。

    lower_case_table_names

    lower_case_table_names = 1

    • Linux或类Unix平台,对文件名称大小写敏感,也即对数据库、表、存储过程等对象名称大小写敏 感,为减少开发人员的开发成本,为此推荐大家设置该参数使对象名称都自动转换成小写;

      2.日志有关的参数

      log_error = /u01/mysql/log/mysql_error.log
      slow_query_log = 1
      slow_query_log_file = /u01/mysql/log/mysql_slow_query.log
      log_queries_not_using_indexes = 1
      log_slow_admin_statements = 1
      log_slow_slave_statements = 1
      log_throttle_queries_not_using_indexes = 10
      expire_logs_days = 90
      long_query_time = 2
      min_examined_row_limit = 100
      

    log_error

    log_error = /u01/mysql/log/mysql_error.log

    • 错误日志文件的名字
    • 如果不设置此参数,服务器会吧出错信息输出到控制台中断
    • 如果在服务器启动时指定了此参数,但未设置具体值,则日志文件名为数据目录里的HOSTNAME.err,其中,HOSTNAME为服务器主机的名字
    • 如果其文件是以相对路径形式给出的,则服务器会将它解释为相对于数据目录
    • 如果在指定文件名时没有带扩展名,mysqld会添加一个扩展名.err
    • 非常重要的参数,重要性和Oracle的alert日志类似

    slow_query_log

    slow_query_log = 1

    • 用于指定是否要启用慢查询日志记录
    • 如果要启用,则log_output参数会控制日志的输出目标

    slow_query_log_file

    slow_query_log_file = /u01/mysql/log/mysql_slow_query.log

    • 慢查询日志文件的名字
    • 在启用了FILE日志目标时,会用到它
    • 它的默认值是数据目录里的HOSTNAME-slow.log文件,其中,HOSTNAME是服务器主机的名字
    • 如果其文件名是以相对路径形式给出的,则服务器会将它解释为相对于数据目录

      long_query_time

    • 最小值和默认值分别为0和10。
    • 此参数值的单位是秒
    • 慢查询时间限度,超过这个限度,mysqld认为是一个慢查询
    • 如果某个查询命令的执行时间大于了这个值(以及检查的记录会超过min_examined_row_limit行),则它也会被认为是一个“慢”查询,并且会导致状态参数slow_queries增加
    • 如果已启用慢查询日志记录功能,则服务器会将该查询写入该日志
    • 该值可以包含小数部分(即微秒)。
    • 只有日志目标是一个文件,而不是mysql.slow_query表时,才会记录小数部分

    log_queries_not_using_indexes

    log_queries_not_using_indexes = 1

    • 如果运行的SQL语句没有使用索引,则mysql数据库同样会将这条SQL语句记录到慢查询日志文件中
    • 为1时,会记录任何不使用索引的sql,而且会无视long_query_time参数

    log_slow_admin_statements

    log_slow_admin_statements = 1

    • 默认情况下不会记录DDL操作,不管执行时间多长,除非将log_slow_admin_statements参数设置为1,而这个参数只在5.6.11后支持

      log_slow_slave_statements

      log_slow_slave_statements=1
    • 默认slave不会记录主库传过来的慢查询
    • 当该参数为1时,会记录从库传过来的慢查询

    log_throttle_queries_not_using_indexes

    log_throttle_queries_not_using_indexes = 10

    • 在log_queries_not_using_indexes为1的情况下,默认没走索引的sql有多少就记录多少,而设置了log_throttle_queries_not_using_indexes为N后,表示1分钟内该SQL最多记录N条,这个参数在5.6.5后支持

    expire_logs_day

    expire_logs_days = 90

    • 默认为0 (不自动删除)
    • 设置binlog自动删除过期时间,单位为天
    • MySQL服务器将自动删除在expire_logs_days天之前创建的日志文件,并更新该二进制日志的索引文件
    • MySQL服务器将在它每次启动以及每次打开一个新的二进制日志文件时执行这个到期检查

    min_examined_row_limit

    min_examined_row_limit = 100

    • 默认值为0
    • 一个查询至少需要检查min_examined_row_limit个行才被允许记录到慢查询日志

    3.复制设置有关的参数

    ########replication settings########
    master_info_repository = TABLE
    relay_log_info_repository = TABLE
    log_bin = on
    sync_binlog = 1
    gtid_mode = on
    enforce_gtid_consistency = 1
    log_slave_updates
    binlog_format = row
    relay_log = relay.log
    relay_log_recovery = 1
    binlog_gtid_simple_recovery = 1
    slave_skip_errors = ddl_exist_errors
    

    master_info_repository

    master_info_repository = TABLE

    • 从服务器是将主服务器的日志信息写入文件,还是写入表
    • 如果该值为FILE(默认值),则从服务器日志文件有—master-info-file选项指定
    • 如果该值为TABLE,则服务器会把日志记录到mysql.slave_master_inro表中
    • 此参数是在MySQL 5.6.2里引入的

    relay_log_info_repository

    relay_log_info_repository = TABLE

    • 从服务器是将中继日志信息写入文件,还是写入表
    • 如果该值为FILE(默认值),那么从服务器会把日志记录到—relay-log-info-file选项所指定的文件里
    • 如果该值为TABLE,那么服务器会把日志记录到mysql.slave_relay_log_info_file表里
    • 此参数的在MySQL 5.6.2里引入的

    log_bin

    log_bin = on

    • 是否启用二进制日志记录功能
    • 需要注意的是,--log-bin选项设置的是log_bin_basename,而非log_bin

    发散一个:

    -- 查询bin-log是否开启
    SHOW VARIABLES LIKE '%log_bin%';
    
    -- 显示第一个bin-log的信息
    SHOW BINLOG EVENTS;  
    
    -- 获取bin-log列表
    SHOW BINARY LOGS;
    
    -- 查询某个bin-log信息
    SHOW BINLOG EVENTS IN 'bin-log.000001';
    
    -- 查看mysql服务器下面bin-log二进制文件方法: 
    mysqlbinlog  /u01/mysql/log/BIN-log.000009
    

    再来个实际的例子,瞬间明了:

    mysql> show variables like '%log_bin%';
    +---------------------------------+---------------------------------+
    | Variable_name                   | Value                           |
    +---------------------------------+---------------------------------+
    | log_bin                         | ON                              |
    | log_bin_basename                | /u01/mysql/mysql_data/bin       |
    | log_bin_index                   | /u01/mysql/mysql_data/bin.index |
    | log_bin_trust_function_creators | OFF                             |
    | log_bin_use_v1_row_events       | OFF                             |
    | sql_log_bin                     | ON                              |
    +---------------------------------+---------------------------------+
    6 rows in set (0.00 sec)
    

    sync_binlog

    sync_binlog = 1

    • 默认值为0
    • 像操作系统刷其他文件的机制一样,MySQL不会同步到磁盘中去而是依赖操作系统来刷新binary log
      • N>0 : 每向二进制日志文件写入N条SQL或N个事务后,会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去
      • N=0 : 不主动刷新二进制日志文件的数据到磁盘上,而是由操作系统决定;
    • 如果启用了autocommit,那么每一个语句statement就会有一次写操作;否则每个事务对应一个写操作。

    一般与innodb_flush_log_at_trx_commit同时设置

    推荐配置组合:

    • N=1,1 — 适合数据安全性要求非常高,而且磁盘IO写能力足够支持业务,比如充值消费系统;
    • N=1,0 — 适合数据安全性要求高,磁盘IO写能力支持业务不富余,允许备库落后或无复制;
    • N=2,0或2,m(0<m<100) — 适合数据安全性有要求,允许丢失一点事务日志,复制架构的延迟也能接受;
    • N=0,0 — 磁盘IO写能力有限,无复制或允许复制延迟稍微长点能接受,例如:日志性登记业务;

    gtid_mode

    gtid_mode = on GTID是MySQL 5.6的新特性,其全称是Global Transaction Identifier,可简化MySQL的主从切换以及Failover。GTID用于在binlog中唯一标识一个事务。当事务提交时,MySQL Server在写binlog的时候,会先写一个特殊的Binlog Event,类型为GTID_Event,指定下一个事务的GTID,然后再写事务的Binlog。主从同步时GTID_Event和事务的Binlog都会传递到从库,从库在执行的时候也是用同样的GTID写binlog,这样主从同步以后,就可通过GTID确定从库同步到的位置了。也就是说,无论是级联情况,还是一主多从情况,都可以通过GTID自动找点儿,而无需像之前那样通过File_name和File_position找点儿了。


    GTID(Global Transaction ID)是对于一个已提交事务的编号,并且是一个全局唯一的编号。 GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增。下面是一个GTID的具体形式: 3E11FA47-71CA-11E1-9E33-C80AA9429562:23

    • 配置方式为gtid_mode=ON/OFF
    • gtid_mode的类型为枚举类型,枚举值可以为ON和OFF,所以应该通过ON或者OFF来控制gtid_mode,不要把它配置成0或者1,否则结果可能不符合预期
    • 开启gtid_mode时,log-bin和log-slave-updates也必须开启,否则MySQL Server拒绝启动
    • 除此以外,enforce-gtid-consistency也必须开启,否则MySQL Server也拒绝启动。enforce-gtid-consistency是因为开启grid_mode以后,许多MySQL的SQL和GTID是不兼容的,比如开启ROW 格式时,CREATE TABLE ... SELECT,在binlog中会形成2个不同的事务,GTID无法唯一。另外在事务中更新MyISAM表也是不允许的。

    enforce_gtid_consistency

    enforce_gtid_consistency = 1

    • 与gtid一起使用
    • 开始该参数,保证数据的一致性

    log_slave_updates

    log_slave_updates

    • 与gtid一起使用
    • 将master服务器上获取数据变更的信息记录到从服务器的二进制文件中

    binlog_format

    binlog_format = row

    • 二进制的日志记录格式。
    • 其可取值包括:STATEMENT、ROW和MIXED,分别代表的是基于语句的日志记录格式、基于行的日志记录格式和混合型日志记录格式。
    • 如果使用unhealthy格式,则MySQL服务器将根据具体情况在基于语句的和基于行的日志记录格式之间自动切换。默认格式为STATEMENT。
    • 运行时,如果要更改此参数或者会话值,客户端必须拥有SUPER权限。

    三种模式介绍:

    • STATEMENT模式(SBR) 每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化,减少了binlog日志量,节约IO,提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数, last_insert_id(),以及user-defined functions(udf)等会出现问题)
    • ROW模式(RBR) 不记录每条sql语句的上下文信息,仅需记录哪条数据被修改了,修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志,尤其是alter table的时候会让日志暴涨。
    • MIXED模式(MBR) 以上两种模式的混合使用,一般的复制使用STATEMENT模式保存binlog,对于STATEMENT模式无法复制的操作使用ROW模式保存binlog,MySQL会根据执行的SQL语句选择日志保存方式。

    建议采用row模式,因为:

    SBR 的缺点:

    • 不是所有的UPDATE语句都能被复制,尤其是包含不确定操作的时候。
    • 调用具有不确定因素的 UDF(user-defined functions) 时复制也可能出问题
    • 使用以下函数的语句也无法被复制:
      • LOAD_FILE()
      • UUID()
      • USER()
      • FOUND_ROWS()
      • SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)
    • INSERT ... SELECT 会产生比 RBR 更多的行级锁 复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时,需要比 RBR 请求更多的行级锁 对于有 AUTO_INCREMENT 字段的 InnoDB表而言,INSERT 语句会阻塞其他 INSERT 语句 对于一些复杂的语句,在从服务器上的耗资源情况会更严重,而 RBR 模式下,只会对那个发生变化的记录产生影响 存储函数(不是存储过程)在被调用的同时也会执行一次 NOW() 函数,这个可以说是坏事也可能是好事 确定了的 UDF 也需要在从服务器上执行 数据表必须几乎和主服务器保持一致才行,否则可能会导致复制出错 执行复杂语句如果出错的话,会消耗更多资源

    RBR 的优点:

    • 任何情况都可以被复制,这对复制来说是最安全可靠的
    • 和其他大多数数据库系统的复制技术一样
    • 多数情况下,从服务器上的表如果有主键的话,复制就会快了很多
    • 复制以下几种语句时的行锁更少:
      • INSERT ... SELECT
      • 包含 AUTO_INCREMENT 字段的 INSERT
      • 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
    • 执行 INSERT,UPDATE,DELETE 语句时锁更少
    • 从服务器上采用多线程来执行复制成为可能

    当然ROW模式也有自己的缺点:

    • binlog 大了很多
    • 复杂的回滚时 binlog 中会包含大量的数据
    • 主服务器上执行 UPDATE 语句时,所有发生变化的记录都会写到 binlog 中,而 SBR 只会写一次,这会导致频繁发生 binlog 的并发写问题
    • UDF 产生的大 BLOB 值会导致复制变慢
    • 无法从 binlog 中看到都复制了写什么语句
    • 当在非事务表上执行一段堆积的SQL语句时,最好采用 SBR 模式,否则很容易导致主从服务器的数据不一致情况发生

    relay_log

    relay_log = relay.log

    • 中继日志文件的名字

    relay_log_recovery

    relay_log_recovery = 1

    • 默认是禁用的
    • 此参数在从服务器崩溃之后非常有用
    • 在启动时启用它,可以使从服务器删除所有的还未处理的中继日志,并再次从主服务器获取它们

    binlog_gtid_simple_recovery

    binlog_gtid_simple_recovery = 1

    • 影响GTID的一个参数:
      • 5.7.6以下中默认simplified_binlog_gtid_recovery=false
      • 5.7.6以上中默认binlog_gtid_simple_recovery=true

    slave_skip_errors

    slave_skip_errors = ddl_exist_errors

    • 用于指定一个错误列表
    • 在列表里的错误出现时,从服务器会忽略它们,而不是将复制过程挂起。(不过,与利用这个选项来忽略错误的做法相比,还是找出问题的根源并彻底解决更好。)
    • 如果此参数的值为all,则会忽略所有的错误。
    • 否则,此参数的值应该是以逗号分隔的一个或者多个出错编号。

    4.innodb相关参数

    ########innodb settings########
    innodb_page_size = 8192
    innodb_buffer_pool_size = 4G
    innodb_buffer_pool_instances = 8
    innodb_buffer_pool_load_at_startup = 1
    innodb_buffer_pool_dump_at_shutdown = 1
    innodb_lru_scan_depth = 2000
    innodb_lock_wait_timeout = 5
    innodb_io_capacity = 4000
    innodb_io_capacity_max = 8000
    innodb_flush_method = O_DIRECT
    innodb_file_format = Barracuda
    innodb_file_format_max = Barracuda
    innodb_log_group_home_dir = /u01/mysql/mysql_redolog/
    innodb_undo_directory = /u01/mysql/mysql_undolog/
    innodb_undo_logs = 128
    innodb_undo_tablespaces = 3
    innodb_flush_neighbors = 1
    innodb_log_file_size = 1G   #注意,生产环境建议调成4G+
    innodb_log_buffer_size = 16777216
    innodb_purge_threads = 4
    innodb_large_prefix = 1
    innodb_thread_concurrency = 64
    innodb_print_all_deadlocks = 1
    innodb_strict_mode = 1
    innodb_sort_buffer_size = 67108864
    

    innodb_page_size

    innodb_page_size = 8192

    • InnoDB表空间里的页面大小。
    • 默认大小为16KB,允许值由4KB、8KB和16KB。
    • 该设置只有在InnoDB初始化表空间的时候才会生效,因此应该在初始化MySQL之前,或者在删除并重新创建InnoDB表空间文件之前设置它。

      innodb_buffer_pool_size

      innodb_buffer_pool_size = 4G #建议调整为实际服务器内存大小的50--90%
    • innodb最重要的一个参数!
    • innodb用它来缓存被访问过的表和索引文件,建议设置为物理内存的50%--90%
    • 如果过多分配给数据库,有可能导致系统内存不够,出现swap或者oom的现象
    • 5.7版本中已经可以在线修改

    innodb_buffer_pool_instances

    innodb_buffer_pool_instances = 8

    • 如果innodb_buffer_pool_size的值至少为1GB,则需要将InnoDB缓冲池划分为innodb_buffer_pool_instances个区域
    • 默认值是1(单个缓冲池),最大值是64。表示innodb缓冲区可以划分为多个区域,可以理解为把innodb_buffer_pool划分为多个实例,提高并发性。
    • 为达到最好的效果,需要对innodb_buffer_pool_size和innodb_buffer_pool_instances的值进行选择,以便每个实例都至少为1GB
    • 在MySQL 5.5.4里引入的

    通过show engine innodb status可以看到每个instance使用内存的情况只有当innodb_buffer_pool 大于1G的时候,这个参数才生效。

    热数据加载的两个参数

    innodb_buffer_pool_load_at_startup与 innodb_buffer_pool_dump_at_shutdown 当数据库宕机后,重启数据库后有可能感觉查询速度非常的慢。这个是因为数据还没有被buffer到缓冲区去,这样对IO的压力很大。如果要把热数据快速加载起来,需要开启下面2个参数:

    mysql> show variables like 'innodb_buffer_pool_load_at%';
    +------------------------------------+-------+
    | Variable_name                      | Value |
    +------------------------------------+-------+
    | innodb_buffer_pool_load_at_startup | ON    |
    +------------------------------------+-------+
    1 row in set (0.00 sec)
    
    mysql> show variables like 'innodb_buffer_pool_dump_at%';
    +-------------------------------------+-------+
    | Variable_name                       | Value |
    +-------------------------------------+-------+
    | innodb_buffer_pool_dump_at_shutdown | ON    |
    +-------------------------------------+-------+
    1 row in set (0.01 sec)
    
    mysql> show variables like 'innodb_buffer_pool_file%';
    +-----------------------------+----------------+
    | Variable_name               | Value          |
    +-----------------------------+----------------+
    | innodb_buffer_pool_filename | ib_buffer_pool |
    +-----------------------------+----------------+
    

    innodb_buffer_pool_dump_at_shutdown参数表示在数据库shutdown的时候把数据dump出来,保存到ib_buffer_pool文件中。当实例再次启动的时候,innodb_buffer_pool_load_at_startup表示把元数据快速的加载回内存。在这儿的元数据就是space number和page number的列表信息。

    mysql> select space,page_number from information_schema.innodb_buffer_page limit 5;
    +-------+-------------+
    | space | page_number |
    +-------+-------------+
    |     0 |           7 |
    |     0 |           3 |
    |     0 |           2 |
    |     0 |           4 |
    |     0 |          11 |
    +-------+-------------+
    5 rows in set (0.70 sec)
    

    innodb_data_file_path

    mysql> show variables like 'innodb_data_file%';
    +-----------------------+------------------------+
    | Variable_name         | Value                  |
    +-----------------------+------------------------+
    | innodb_data_file_path | ibdata1:12M:autoextend |
    +-----------------------+------------------------+
    1 row in set (0.01 sec)
    

    该参数指定系统表空间文件的路径和ibdata1文件的大小。默认为10M,建议调大到至少1G。

    innodb_lru_scan_depth

    innodb_lru_scan_depth = 2000

    • InnoDB会使用一个后台操作来查找需要从其缓冲池刷新到磁盘的脏页
    • 这个参数控制的是这个操作能够查看到的页面列表(按最近最少使用的顺序排序)的长度
    • 对默认值1024的合理更改包括:对于拥有繁重写操作工作负载和大型缓冲池的服务器,可以减小这个值;而对于I/O能力还有盈余的服务器,可以增加这个值。

    innodb_lock_wait_timeout

    innodb_lock_wait_timeout = 5

    • MySQL在允许其他事务修改那些最终受事务回滚的数据之前要等待多长时间(秒数)
    • InnoDB一般都能自动检测到,并使一个事务释放锁并回退,另一个事务获得锁,继续完成事务。但在涉及外部锁,或涉及表锁的情况下,InnoDB并不能完全自动检测到死锁,这需要通过设置锁等待超时参数 innodb_lock_wait_timeout来解决。
    • 这个参数并不是只用来解决死锁问题,在并发访问比较高的情况下,如果大量事务因无法立即获得所需的锁而挂起,会占用大量计算机资源,造成严重性能问题,甚至拖跨数据库。
    • 通过设置合适的锁等待超时阈值,可以避免这种情况发生。

    innodb_io_capacity

    innodb_io_capacity = 4000

    • InnoDB对于后台任务每秒执行I/O操作次数的近似限制
    • 默认值为200,最小值为100。
    • 对于慢速旋转的磁盘,可能需要将这个值调低一点。
    • 对于SSD磁盘,可以将其适当调高,请参考innodb_io_capacity_max

      innodb_io_capacity_max

      innodb_io_capacity_max = 8000
    • 如果innodb_io_capacity的值在紧急情况下不够高,那么innodb_io_capacity_max会成为InnoDB可以将该限制扩展到的最大值。
    • 其默认值为innodb_io_capacity默认值的两倍,它受限制于服务器所使用的最低值2000。
    • 此参数是在MySQL 5.6.6里引入

    innodb_flush_method

    innodb_flush_method = O_DIRECT

    • 给InnoDB用来刷新文件的方法。它只适用于Unix系统
    • 参数的三种值:
      • fdatasync:默认为fdatasync,调用fsync()去刷数据文件与redo log的buffer
      • O_DSYNC:innodb会使用O_SYNC方式打开和刷写redo log,使用fsync()刷写数据文件
      • O_DIRECT:innodb使用O_DIRECT打开数据文件,使用fsync()刷写数据文件跟redo log
      • 在Windows里,此参数的值总是为async_unbuffered

    innodb_file_per_table

    innodb_file_per_table=1

    • 控制是否使用独立表空间模式
    • 设置为1,InnoDB将为每个新表分别创建一个独立表空间:在数据库目录里为每一个新表单独创建一个.ibd文件来存放该表的内容。在这种情况下,系统表空间只会用于InnoDB数据目录条目,而不会用于数据或索引存储。
    • 建议设置为1

    innodb_file_format_check

    innodb_file_format_check=on

    • InnoDB系统表空间包含有一个标志,它表示的是表空间里使用的最高版本的文件格式。
    • 此参数会在服务器启动时设置,主要用于控制InnoDB是否要检查这个标志,以确定此格式版本比InnoDB支持的那个版本更高。
    • 如果启用此参数(默认值),并且该格式版本更高,那么启动会失败,并产生一个错误。如果该格式版本不够高,那么InnoDB会将innodb_file_format_max设置成该格式。

    innodb_file_format

    innodb_file_format = Barracuda

    • 默认格式为Antelope;另一个允许值为Barracuda。
    • 如果启用了innodb_file_per_table,则它指的是InnoDB新表所使用的格式。
    • 使用Barracuda可以启用不被Antelope支持的功能,如COMPRESSED行格式。

      innodb_file_format_max

      innodb_file_format_max = Barracuda
    • 参考innodb_file_format_check的描述

    innodb_log_group_home_dir

    innodb_log_group_home_dir = /u01/mysql/mysql_redolog/

    • InnoDB应该将其日志文件写入的那个目录的路径名

    innodb_undo_directory

    innodb_undo_directory = /u01/mysql/mysql_undolog/

    • 如果innodb_undo_logs和innodb_undo_tablespaces都是非零值,则它指的是InnoDB在其中创建独立恢复日志表空间的那个目录。
    • 默认值为“.”,它表示的是InnoDB在其中创建其他日志文件的那个默认目录。
    • MySQL 5.6.3里引入的

    innodb_undo_logs

    innodb_undo_logs = 128

    • 在一个事务里,InnoDB在系统表空间里会使用多少回滚段。
    • 默认值为128。
    • 在MySQL 5.6.3里引入的,用于替换innodb_rollback_segments。

    innodb_undo_tablespaces

    innodb_undo_tablespaces = 3

    • InnoDB针对独立恢复日志所使用的那个表空间文件数量
    • 默认值为0

    innodb_flush_neighbors

    innodb_flush_neighbors = 1

    • InnoDB是单独刷新缓冲池的脏面,还是连同位于同一范围(页面组)内的相邻页面一起刷新。
    • 刷新相邻页面,可以将写操作结合在一起,减少磁盘设备旋转过程中的寻道时间开销。
    • MySQL 5.6.3里引入的,是一个布尔量,其默认值为ON。
    • 自MySQL 5.6.6起,这个参数允许的值包括:
      • 0:不刷新相邻页面
      • 1:刷新相邻页面
      • 2:刷新同一范围里的所有相邻页面

    innodb_log_file_size

    innodb_log_file_size = 1G #注意,生产环境建议调成4G+

    • 每个InnoDB日志文件的大小。innodb_log_file_sizeinnodb_log_files_in_group的乘积决定了InnoDB日志的总大小
    • 默认为 5M
    • 用来在 MySQL crash后的恢复,所以设置合理的大小对于mysql的性能非常重要
    • 通过show engine innodb statusG可以查看mysql checkpoint情况,可以算出上次checkpoint和最后一次checkpoint的中间值,官方文档建议最好不要超过innodb_log_files_in_group*innodb_log_file_size的0.75,由此可以推算出innodb_log_file_size比较合适的值。
    • 在MySQL 5.5和5.5以前innodb的logfile最大设置为4GB,在5.6以后的版本中logfile最大的可以设为512GB
    • 当MySQL crash后,在重启之前需要将老的innodb logfile删除,参考:

    innodb_log_buffer_size

    innodb_log_buffer_size = 16777216

    • InnoDB事务日志缓冲区的大小
    • 取值范围通常是1MB~8MB
    • 默认为1MB

    innodb_purge_threads

    innodb_purge_threads = 4

    • InnoDB使用了多少后台线程来实现清除操作(将所有事务都不再需要的待删除行删除掉)
    • 默认值为0
    • 在MySQL 5.5.4里引入

    innodb_large_prefix

    innodb_large_prefix = 1

    • InnoDB索引的最大索引前缀长度通常是767字节
    • 如果启用此参数,那么对于那些使用COMPRESSED或DYNAMIC行格式的表,允许前缀最高达到3072个字节
    • 默认值为OFF
    • MySQL 5.5.14里引入

    innodb_thread_concurrency

    innodb_thread_concurrency = 64

    • InnoDB尝试维护的线程数量上限

    innodb_print_all_deadlocks

    innodb_print_all_deadlocks = 1

    • InnoDB是否会将诊断信息写到与事务死锁有关的错误日志里

    innodb_strict_mode

    innodb_strict_mode = 1

    • InnoDB是否对表和索引的创建和修改语句的语法进行较严格要求。
    • 如果启用了此参数,那么InnoDB会把有冲突的子句当作错误;否则,它们会被当作警告
    • 类似于启用了严格的SQL默认

    innodb_sort_buffer_size

    innodb_sort_buffer_size = 67108864 (64M)

    • InnoDB在索引创建期间用于合并排序的缓冲区大小(单位为字节)
    • 默认大小为1MB
    • 在MySQL 5.6.4里最小值为512KB;在MySQL 5.6.5及以上的版本里,最小值为64KB
    • 在MySQL 5.6.4里引入,在MySQL 5.6.4之前,使用的是固定大小1MB。

    innodb_flush_log_at_trx_commit

    innodb_flush_log_at_trx_commit = 1

    • 默认为1
    • 控制log buffer写入log file和控制flush操作,三种模式:
      • innodb_flush_log_at_trx_commit=0,log buffer将每秒一次地写入log file中,并且log file的flush(刷到磁盘)操作同时进行。该模式下,在事务提交的时候,不会主动触发写入磁盘的操作
      • innodb_flush_log_at_trx_commit=1,每次事务提交时MySQL都会把log buffer的数据写入log file,并且flush(刷到磁盘)中去
      • nnodb_flush_log_at_trx_commit=2,每次事务提交时MySQL都会把log buffer的数据写入log file.但是flush(刷到磁盘)操作并不会同时进行。该模式下,MySQL会每秒执行一次 flush(刷到磁盘)操作
    • 注意: 由于进程调度策略问题,这个“每秒执行一次 flush(刷到磁盘)操作”并不是保证100%的“每秒”

    三种模式比较:

    • 当设置为0,该模式速度最快,但不太安全,mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。
    • 当设置为1,该模式是最安全的,但也是最慢的一种方式。在mysqld 服务崩溃或者服务器主机crash的情况下,binary log 只有可能丢失最多一个语句或者一个事务。。
    • 当设置为2,该模式速度较快,也比0安全,只有在操作系统崩溃或者系统断电的情况下,上一秒钟所有事务数据才可能丢失。

    一般和sync_binlog搭配使用,推荐配置组合:

    • N=1,1 — 适合数据安全性要求非常高,而且磁盘IO写能力足够支持业务,比如充值消费系统;
    • N=1,0 — 适合数据安全性要求高,磁盘IO写能力支持业务不富余,允许备库落后或无复制;
    • N=2,0或2,m(0<m<100) — 适合数据安全性有要求,允许丢失一点事务日志,复制架构的延迟也能接受;
    • N=0,0 — 磁盘IO写能力有限,无复制或允许复制延迟稍微长点能接受,例如:日志性登记业务;

    5.半同步设置有关参数

    ########semi sync replication settings########
    plugin_dir=/usr/local/mysql/lib/plugin
    plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
    loose_rpl_semi_sync_master_enabled = 1
    loose_rpl_semi_sync_slave_enabled = 1
    loose_rpl_semi_sync_master_timeout = 5000
    

    6.MySQL 5.7特性有关参数

    [mysqld-5.7]
    innodb_buffer_pool_dump_pct = 40
    innodb_page_cleaners = 4
    innodb_undo_log_truncate = 1
    innodb_max_undo_log_size = 2G
    innodb_purge_rseg_truncate_frequency = 128
    binlog_gtid_simple_recovery=1
    log_timestamps=system
    transaction_write_set_extraction=MURMUR32
    show_compatibility_56=on
    

    innodb_buffer_pool_dump_pct

    innodb_buffer_pool_dump_pct=40

    • 表示转储每个bp instance LRU上最热的page的百分比
    • 通过设置该参数可以减少转储的page数

    innodb_page_cleaners

    innodb_page_cleaners = 4

    • 从5.7开始,innodb支持多个刷新buffer pool实例的脏数据的清理线程,innodb_page_cleaners即线程数量

    innodb_undo_log_truncate

    innodb_undo_log_truncate = 1

    • innodb_undo_log_truncate参数设置为1,即开启在线回收(收缩)undo log日志文件,支持动态设置
    • 当innodb_undo_log_truncate打开,触发回收时:
      • 1、当undo 表空间超过innodb_max_undo_log_size 大小会标记为truncation,选择一个undo表空间进行截断, in a round-robin fashion ,避免两个表空间同时截断
      • 2、回滚段在undo表空间是不活跃的,并且不会被新的事物所使用,现有事物使用的回滚段,允许完成。
      • 3、清空、释放那些不在需要的回滚段
      • 4、当所有undo表空间的回滚段释放,undo表空间会执行一个truncate 操作,undo表空间变为初始化大小值。
      • 5、回滚段被重新激活,他们可以分配新的事物
    • 必须在初始化前设置innodb_undo_log_truncate 此参数为非0,后期可以通过修改参数文件/etc/my.cnf,调整undo表空间的数量,然后重启

    innodb_max_undo_log_size

    innodb_max_undo_log_size = 2G

    mysql> SELECT @@innodb_max_undo_log_size;
    +----------------------------+
    | @@innodb_max_undo_log_size |
    +----------------------------+
    |                 2147483648 |
    +----------------------------+
    1 row in set (0.00 sec)
    
    • 当超过这个阀值(默认是1G),会触发truncate回收(收缩)动作,truncate后空间缩小到10M。
    • 当undo 表空间超过innodb_max_undo_log_size 大小会标记为truncation,选择一个undo表空间进行截断, in a round-robin fashion ,避免两个表空间同时截断

    innodb_purge_rseg_truncate_frequency

    innodb_purge_rseg_truncate_frequency = 128

    • 控制回收(收缩)undo log的频率
    • undo log空间在它的回滚段没有得到释放之前不会收缩,想要增加释放回滚区间的频率,就得降低innodb_purge_rseg_truncate_frequency设定值。
    • undo 表空间一般不能直接truncate,需要在所有回滚段释放完后,才能truncate, purge system每128次释放一次回滚段
    • 默认128是最大值

    binlog_gtid_simple_recovery

    binlog_gtid_simple_recovery=1

    log_timestamps

    log_timestamps=system

    • 为了方便对于不知道是什么原因导致日志时间差异,以及不知道如何解决的用户,MySQL 在 5.7.2 版本中新增了一个参数log_timestamps,用来解决此问题。
    • 这个参数主要是控制 error log、slow_log、genera log,等等记录日志的显示时间参数,但不会影响 general log 和 slow log 写到表 (mysql.general_log, mysql.slow_log) 中的显示时间。
    • 在查询行的时候,可以使用 CONVERT_TZ() 函数,或者设置会话级别的系统参数 time_zone 来转换成所需要的时区。
    • 可以被设置的值有:UTC 和 SYSTEM,默认使用 UTC。
    • 它还支持动态设置,不过建议在配置文件中就写上,以免重启之后造成不必要的麻烦。

    transaction_write_set_extraction

    transaction_write_set_extraction=MURMUR32

    • 5.7.6版本引入
    • 用于定义一个记录事务的算法,这个算法使用hash标识来记录事务。
    • 如果使用MGR,那么这个hash值需要用于分布式冲突检测何处理,在64位的系统,官网建议设置该参数使用 XXHASH64 算法。
    • 如果线上并没有使用该功能,应该设为off

    show_compatibility_56

    show_compatibility_56=on

    • 从mysql5.7.6开始information_schema.global_status已经开始被舍弃,为了兼容性,此时需要打开 show_compatibility_56
    mysql> select * from information_schema.global_status limit 3;
    ERROR 3167 (HY000): The 'INFORMATION_SCHEMA.GLOBAL_STATUS' feature is disabled; see the documentation for 'show_compatibility_56'
    
    --查看show_compatibility_56
    mysql> show variables like '%show_compatibility_56%';
    +-----------------------+-------+
    | Variable_name         | Value |
    +-----------------------+-------+
    | show_compatibility_56 | OFF   |
    +-----------------------+-------+
    1 row in set (0.01 sec)
    
    --把show_compatibility_56打开
    mysql> set global show_compatibility_56=on;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> show variables like '%show_compatibility_56%';
    +-----------------------+-------+
    | Variable_name         | Value |
    +-----------------------+-------+
    | show_compatibility_56 | ON    |
    +-----------------------+-------+
    1 row in set (0.00 sec)
    
    mysql> select * from information_schema.global_status limit 3;
    +-----------------------+----------------+
    | VARIABLE_NAME         | VARIABLE_VALUE |
    +-----------------------+----------------+
    | ABORTED_CLIENTS       | 0              |
    | ABORTED_CONNECTS      | 0              |
    | BINLOG_CACHE_DISK_USE | 0              |
    +-----------------------+----------------+
    3 rows in set, 1 warning (0.00 sec)
    

    在MySQL 5.6版本, 系统和状态参数信息从下面语句获取:

    SHOW VARIABLES
    SHOW STATUS
    And from these INFORMATION_SCHEMA tables:
    INFORMATION_SCHEMA.GLOBAL_VARIABLES
    INFORMATION_SCHEMA.SESSION_VARIABLES
    INFORMATION_SCHEMA.GLOBAL_STATUS
    INFORMATION_SCHEMA.SESSION_STATUS
    

    在MySQL 5.7.6后,performance_schema包含以下的表作为系统和状态参数信息的新来源:

    performance_schema.global_variables
    performance_schema.session_variables
    performance_schema.variables_by_thread
    performance_schema.global_status
    performance_schema.session_status
    performance_schema.status_by_thread
    performance_schema.status_by_account
    performance_schema.status_by_host
    performance_schema.status_by_user
    技术链接
  • 相关阅读:
    《怎样解题》-波利亚
    BZOJ2631 tree
    BZOJ3669 [Noi2014]魔法森林
    BZOJ 2049 [Sdoi2008]Cave 洞穴勘测
    BZOJ2002 [Hnoi2010]Bounce 弹飞绵羊
    动态树入门
    树链剖分入门-Hdu3966 Aragorn's Story
    BZOJ1146 [CTSC2008]网络管理Network
    树的表示方法
    树状数组
  • 原文地址:https://www.cnblogs.com/liujiacai/p/14829768.html
Copyright © 2011-2022 走看看