MySQL 生产环境 参数 配置

1.lower_case_table_names     #表名 表别名 数据库名 大小写是否敏感

0：以实际指定大小写存储，以区分大小比较，就是大小写敏感，Linux默认值

1：以小写存储，以不区分大小比较，就是大小写不敏感

2：以实际指定大小写存储，以小写比较，也算大小写不敏感

只读变量，修改需要重启。如果有主从，那么主和从的这个参数一定要配置成一样的。

例：

在lower_case_table_names=0时

mysql>select @@global.lower_case_table_names;
+---------------------------------+
| @@global.lower_case_table_names |
+---------------------------------+
|                               0 |
+---------------------------------+
1 row in set (0.00 sec)

mysql> create table TesT (c1 int);
Query OK, 0 rows affected (0.46 sec)

[root@test1 incase]# ls
db.opt  TesT.frm  TesT.ibd     #这时操作系统里的文件名和指定的表名一样

mysql> select * fromtest;
ERROR 1146 (42S02): Table 'incase.test' doesn't exist
mysql> select * from Test;
ERROR 1146 (42S02): Table 'incase.Test' doesn't exist
mysql> select * from TEST;
ERROR 1146 (42S02): Table 'incase.TEST' doesn't exist
mysql> select * from TesT;
Empty set (0.01 sec)

在mysql里使用表时，只有在表名为TesT时才正确，别的写法都不对。

在lower_case_table_names=1时，在my.cnf里加上lower_case_table_names=1重启mysql

mysql> create tableTesT2(c1 int);
Query OK, 0 rows affected (0.11 sec)

[root@test1 incase]# ls
db.opt  test2.frm  test2.ibd  TesT.frm  TesT.ibd    #这时即使创建表时表名为TesT2，操作系统里文件名也全是小写

mysql> select * fromtest2;

Empty set (0.00 sec)
mysql> select * from tesT2;
Empty set (0.00 sec)
mysql> select * from TEST2;
Empty set (0.00 sec)
mysql> select * from TEst2;
Empty set (0.00 sec)

在mysql里无论表名如何写，都可正确执行。

如果这时去查询在lower_case_table_names=0时创建的TesT表时，将会找不到表：

mysql> select * from TesT;
ERROR 1146 (42S02): Table 'incase.test' doesn't exist

information_schema.tables表里也没有TesT表：

mysql> select TABLE_SCHEMA,table_type, table_name from information_schema.tables where table_schema='incase';
+--------------+------------+------------+
| TABLE_SCHEMA | table_type | table_name |
+--------------+------------+------------+
| incase       | BASE TABLE | test2      |
+--------------+------------+------------+
1 row in set (0.00 sec)

但是show tables还能看到这个表：

mysql> show tables;
+------------------+
| Tables_in_incase |
+------------------+
| TesT             |
| test2            |
+------------------+
2 rows in set (0.00 sec)

如果再将lower_case_table_names=0并重启mysql，这时TesT、test2又都可以使用：

mysql> select @@global.lower_case_table_names;
+---------------------------------+
| @@global.lower_case_table_names |
+---------------------------------+
|                               0 |
+---------------------------------+
1 row in set (0.00 sec)
mysql> select * from TesT;
Empty set (0.00 sec)
mysql> select TABLE_SCHEMA,table_type, table_name from information_schema.tables where table_schema='incase';
+--------------+------------+------------+
| TABLE_SCHEMA | table_type | table_name |
+--------------+------------+------------+
| incase       | BASE TABLE | TesT       |
| incase       | BASE TABLE | test2      |
+--------------+------------+------------+
2 rows in set (0.00 sec)

这就是MySQL，玄机很多，所以一定要知道各种参数的意义，并且所有环境要配置成一致的参数。为了书写方便和减少错误，在生产环境上应该将lower_case_table_names设置成1。

lower_case_table_names=2情况可以依照理论推出，这里不再试验。

2.max_connect_errors     #连续最大错误登录次数，5.6以后默认100

超过这个次数后，这台机器就不能再登录mysql了，可以执行flush hosts或mysqladmin flush-hosts来解除限止。

3.interactive_timeout和wait_timeout     #非活动连接持续存活interactive_timeout秒后被关闭

interactive_timeout决定交互式连接的超时时间，wait_timeout决定非交互连接时间。默认28800秒（8小时)。

4.transaction-isolation和binlog-format     #事务和日志

推荐配置
   只读为主的业务应用场景   
     transaction-isolation=read-committed
     binlog-format=mixed
   非只读为主的业务应用场景
     transaction-isolation=repeatabled-read
     binlog-format=mixed

5.innodb_adaptive_hash_index     #是否开启hash index，默认开启

InnoDB会监控使用索引的搜索，并在认为应该时建立hash index。hash index并不总有益，当show engine innodb status\G的SEMAPHORES部分出现大师线程正在等待由btr0sea.c创建的RW-latch时，就应该将innodb_adaptive_hash_index关闭。

6.innodb_max_dirty_pages_pct     #针对Buffer Pool的

值越小，mysqld服务出现问题的时候恢复时间越短，但物理I/O越繁忙。

数据库运行一段时间后如果出现大量swap，可能就是innodb_max_dirty_pages_pct值太大的原因，应当调小了。

7.innodb_commit_concurrency     #有多少个线程可以同时commit，默认0无限制，最大1000

运行时不能从0改成非0或相反，但是可以从一个非0值改成别一个非0值。

8.innodb_fast_shutdown     #InnoDB关闭方式

0：慢关闭，需要进行full purge 和 change buffer merge，可以需要数分钟到数小时。相当于ORACLE的shutdown normal

1：快关闭，默认方式，跳过full purge 和 change buffer merge，直接关闭。相当于ORACLE的shutdown immediate

2：crash关闭，刷出日志后立刻冷关闭，下次启动需要crash recovery。相当于ORACLE的shutdown abort

推荐设置：1

9.innodb_force_recovery     #InnoDB crash recovery模式，解决MySQL崩溃无法重启问题

0：默认值。正常启动，不进行强制恢复。除非紧急情况，否则不要修改默认值。修改成大于0的值时，要确认数据库已备份；以>=4的方式启动会永久损坏数据文件；非要使用非0值时，要从1开始一级一级加。

1. (SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。用SELECT *  INOT OUTFILE ‘../filename’ FROM tablename;方式完成数据备份。
2. (SRV_FORCE_NO_BACKGROUND):阻止master和purge线程的运行，如果purge会导致crash应设置成此值。
3. (SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4. (SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作，不计算表统计信息。设置成此值后需要删除和重建二级索引。
5. (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看回滚日志，InnoDB存储引擎会将未提交的事务视为已提交。
6. (SRV_FORCE_NO_LOG_REDO):不执行redo log前滚的操作。

推荐设置：0

10.innodb_buffer_pool_size     #缓存InnoDB表数据和索引

推荐设置物理内存的70%大小，通过show engine innodb status\G查看命中率，不应该小于97%。

11.innodb_flush_log_at_trx_commit 和 sync_binlog     #日志刷新方式

innodb_flush_log_at_trx_commit = N
N=0  – 每隔一秒，把事务日志缓存区的数据写到日志文件中，以及把日志文件的数据刷新到磁盘上
N=1  – 每个事务提交时候，把事务日志从缓存区写到日志文件中，并且刷新日志文件的数据到磁盘上
N=2  – 每事务提交的时候，把事务日志数据从缓存区写到日志文件中；每隔一秒，刷新一次日志文件
            但不一定刷新到磁盘上，而是取决于操作系统的调度

sync_binlog =  N
N>0  — 每向二进制日志文件写入N条SQL或N个事务后，则把二进制日志文件的数据刷新到磁盘上
N=0  — 不主动刷新二进制日志文件的数据到磁盘上，而是由操作系统决定

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

12.innodb_file_per_table     #每个表一个表空间，5.6.6及以后的默认值

表个表和它的索引存放在一个.ibd数据文件。表删除后会回收空间。

13.key_buffer_size     #MyISAM的索引缓存

计算命中率：

mysql> show status like '%key%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| Com_assign_to_keycache | 0     |
| Com_preload_keys       | 0     |
| Com_show_keys          | 0     |
| Handler_read_key       | 0     |
| Key_blocks_not_flushed | 0     |
| Key_blocks_unused      | 6694  |
| Key_blocks_used        | 4     |
| Key_read_requests      | 86    |
| Key_reads              | 4     |
| Key_write_requests     | 30    |
| Key_writes             | 30    |
+------------------------+-------+

11 rows in set (0.00 sec)

Key_reads/Key_read_requests的比率应该小于0.01，Key_writes/Key_write_requests的比率应该接近或小于1；

计算利用率：

mysql> show variables like '%key%';
+--------------------------+----------------------+
| Variable_name            | Value                |
+--------------------------+----------------------+
| delay_key_write          | ON                   |
| foreign_key_checks       | ON                   |
| have_rtree_keys          | YES                  |
| key_buffer_size          | 8388608              |
| key_cache_age_threshold  | 300                  |
| key_cache_block_size     | 1024                 |
| key_cache_division_limit | 100                  |
| max_seeks_for_key        | 18446744073709551615 |
| ssl_key                  |                      |
+--------------------------+----------------------+
9 rows in set (0.01 sec)

1 - ((Key_blocks_unused * key_cache_block_size) / key_buffer_size)

尽量使用多个MyISAM key caches。

14.query_cache_type和query_cache_size     @查询缓存

query_cache_type=N
N=0  —- 禁用查询缓存的功能
N=1  —- 启用产讯缓存的功能，缓存所有符合要求的查询结果集，除SELECT SQL_NO_CACHE..， 
               以及不符合查询缓存设置的结果集外
N=2  —- 仅仅缓存SELECT SQL_CACHE …子句的查询结果集，除不符合查询缓存设置的结果集外

query_cache_size：

一个SELECT查询在DB中工作后，DB会把该语句缓存下来，当同样的一个SQL再次来到DB里调用时，
DB在该表没发生变化的情况下把结果从缓存中返回给Client。当该语句涉及的表在这段时间内发生变更时，首先要把Query_cache和该表相关的语句全部置为失效，然后在写入更新，如果Query_cache非常大，该表的查询结构又比较多，查询语句失效也慢，一个更新或是Insert就会很慢，所以在数据库写入量或是更新量也比较大的系统，该参数不适合分配过大。而且在高并发，写入量大的系统，建系把该功能禁掉。