标签:myisam 文件 成本 sql数据库 维护 大小 后台进程 log文件 建议
innodb_buffer_pool_size:
-------------------------------------------
innodb_buffer_pool_instances:
innodb_log_file_size :
在mysql 5.5和5.5以前innodb的logfile最大设置为4GB,在5.6以后的版本中logfile最大的可以设为512GB.
innodb的logfile就是事务日志,用来在mysql crash后的恢复.所以设置合理的大小对于mysql的性能非常重要
在5.5的版本中,default设置为5M.在新建的mysql服务器中,需要尽快修改该参数.
--------------------------------------------
innodb_log_buffer_size:
--------------------------------------------
innodb_thread_concurrency(并发线程) :
--------------------------------------------
innodb_io_capacity :
innodb_max_dirty_pages_pct :
innodb_flush_method :
---------------------------------------------
innodb_file_per_table :
------------------------------------------
innodb_flush_log_at_trx_commit :
0:每秒将log buffer的内容与事务日志并数据刷盘;-----------------------最快数据最不安全
1:每个事务提交后,将log_buffer的内容写事务日志并数据刷盘;-----------最慢最安全
2:每个事务提交后,将log_buffer的内容写事务日志,但不进行数据刷盘;---折中
------------------------------------------
sync_binlog :
请注意如果在autocommit模式,每执行一个语句向二进制日志写入一次,否则每个事务写入一次。 默认值是0,不与硬盘同步。值为1是最安全的选择,因为崩溃时,你最多丢掉二进制日志中的一个语句/事务;但是,这是最慢的选择。
双1模式,即innodb_flush_log_at_trx_commit=1,sync_binlog=1 这样主备库的数据是一致的,不会丢失数据。(在此请问你考虑到IO负载了吗?)
当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写能力有限,无复制或允许复制延迟稍微长点能接受,例如:日志性登记业务;
----------------------------------------
key_buffer_size :
key_buffer_size只能缓存MyISAM或类MyISAM引擎的索引数据,而innodb_buffer_pool_size不仅能缓存索引数据,还能缓存元数据,但是对于我们只使用InnoDB引擎的数据库系统而言,此参数值也不能设置过于偏小,因为临时表可能会使用到此键缓存区空间,索引缓存区推荐:64M
----------------------------------------
query_cache_type and query_cache_size :
query_cache_type=N:
N=0 —- 禁用查询缓存的功能;
(有人认为mysql的query cache大部分情况下其实只是鸡肋而已,而且建议全面禁用 ; 总之,如果线上环境中99%以上都是只读,很少有更新,再考虑开启QC吧,否则,就别开了。详见 http://www.wtoutiao.com/p/r9aGUI.html)
N=1 —- 启用产讯缓存的功能,缓存所有符合要求的查询结果集,除SELECT SQL_NO_CACHE.., 以及不符合查询缓存设置的结果集外;
N=2 —- 仅仅缓存SELECT SQL_CACHE …子句的查询结果集,除不符合查询缓存设置的结果集外;
query_cache_size:
查询缓存设置多大才是合理?至少需要从四个维度考虑:
① 查询缓存区对DDL和DML语句的性能影响;
② 查询缓存区的内部维护成本;
③ 查询缓存区的命中率及内存使用率等综合考虑
④ 业务类型
----------------------------------------
max_connections :
MySQL的最大连接数,增加该值增加mysqld 要求的文件描述符的数量。如果服务器的并发连接请求量比较大,建议调高此值,以增加并行连接数量,当然这建立在机器能支撑的情况下,因为如果连接数越多,介于MySQL会为每个连接提供连接缓冲区,就会开销越多的内存,所以要适当调整该值,不能盲目提高设值。
数值过小会经常出现ERROR 1040: Too many connections错误,可以过’conn%’通配符查看当前状态的连接数量,以定夺该值的大小。
show variables like ‘max_connections‘ ; 查看当前最大连接数设置值
show status like ‘max_used_connections‘ ; 查看最大响应的连接数
如下:
mysql> show variables like ‘max_connections‘;
+———————–+——-+
| Variable_name | Value |
+———————–+——-+
| max_connections | 256 |
+———————–+——-+
mysql> show status like ‘max%connections‘;
+———————–+——-+
| Variable_name | Value |
+—————————-+——-+
| max_used_connections | 256|
+—————————-+——-+
max_used_connections / max_connections * 100% (理想值≈ 85%)
如果max_used_connections跟max_connections相同 那么就是max_connections设置过低或者超过服务器负载上限了,低于10%则设置过大。
修改方法: vim /etc/my.cnf(永久生效) 或者直接修改会话全局变量(临时即时生效,重启mysql后失效,恢复原样)。所以建议修改指定参数后,同样修改my.cnf保持一致。
[mysqld]
max_connections=1000
----------------------------------------
标签:myisam 文件 成本 sql数据库 维护 大小 后台进程 log文件 建议
原文地址:http://www.cnblogs.com/hh2737/p/7098722.html