1.lower_case_table_names #表名 表别名 数据库名 大小写是否敏感
0:以实际指定大小写存储,以区分大小比较,就是大小写敏感,Linux默认值
1:以小写存储,以不区分大小比较,就是大小写不敏感
2:以实际指定大小写存储,以小写比较,也算大小写不敏感
+---------------------------------+
| @@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)
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就会很慢,所以在数据库写入量或是更新量也比较大的系统,该参数不适合分配过大。而且在高并发,写入量大的系统,建系把该功能禁掉。