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

----------------------------------------