这几天要折腾mysql服务器，于是在网上搜索了一些维护策略，然后自己实验总结。以下是我总结的经验和其他人的一些建议。日志类型：MySQL有几个不同的日志文件，可以帮助您了解mysqld内部发生的事情：数据。主要用于复制和时间点恢复。慢日志记录所有执行时间超过long_query_time秒的查询或不使用索引的查询。事务日志记录了InnoDB等支持事务的存储引擎执行事务时产生的日志。1、启动慢查询日志：MySQL如果开启slow_query_log=ON选项，将记录执行时间超过long_query_time（默认10s）的查询（表最初被锁定的时间不算执行时间）。日志记录文件为slow_query_log_file[=file_name]，如果不给file_name值，默认为主机名，后缀为-slow.log。如果给出文件名，但不是绝对路径名，则文件将写入数据目录。【这个可以在调试mysql性能的时候开启，可以找出哪个sql命令最耗时。生产环境建议关闭】2.生产环境关闭通用查询日志：由于打开通用查询日志是为了记录所有用户操作，生产环境中这个日志量非常大，所以一般不开启，myslq默认的日志功能也是关闭的，只有在特殊情况下才开启[一般只在开发测试环境，使用特定的SQL语句定位某些功能时，日志功能会在短时间内开启日志进行相应的分析。】mysql>setglobalgeneral_log=1;#1:启用一般查询日志，0:禁用一般查询日志mysql>showglobalvariableslike'%general_log%';+----------------+---------------------------+|Variable_name|Value|+------------------+-----------------------+|general_log|ON|#是否开启通用查询日志|general_log_file|/var/run/mysqld/mysqld.日志|#日志路径+----------------+-------------------------+2组中的行（0.00秒）3。二进制日志和sql数据定时备份：[本地拷贝，远程日志主机拷贝，存储主机拷贝]在my.cnf中，log-bin=[filename]是开启二进制日志，默认是[filename]。data，因为二进制日志只记录了从现在到最近一次mysql崩溃重启]的所有sql语句，mysql会开始记录每条sql语句，一旦mysql因为各种原因需要重启，就会生成新的二进制日志，000001的后缀将被连续添加。如果mysqlcrash时mysql数据损坏（如磁盘损坏），之前的数据全部被破坏，这个备份策略可以帮你挽回损失。可以从二进制日志中恢复从最开始到最近一次mysql重启的数据。【每条sql语句都记录在binarylog中，可以用mysqlbinlog[filename]查看日志内容】4.sync_binlog全局变量的值一定要合适：默认情况下，binarylog是不结合硬盘同步的。因此，如果操作系统或机器（不仅仅是MySQL服务器）崩溃，则二进制日志中的最后一条语句可能会丢失。为防止这种情况，您可以使用sync_binlog全局变量（1是最安全的值，但也是最慢的）在每N次二进制日志写入后将二进制日志同步到磁盘。对非事务表的更新在执行后立即保存到二进制日志中。下面来解释一下sync_binlog：“sync_binlog”：这个参数对于MySQL系统来说非常重要。它不仅会影响Binlog对MySQL造成的性能损失，还会影响MySQL中数据的完整性。“sync_binlog”参数的各种设置说明如下：sync_binlog=0，事务提交时，MySQL不执行fsync等磁盘同步命令将binlog_cache中的信息刷新到磁盘，让Filesystem决定何时进行同步，或在缓存已满后同步到磁盘。sync_binlog=n，每n个事务commit后，MySQL会执行fsync等磁盘同步命令，强制将binlog_cache中的数据写入磁盘。MySQL中系统默认设置为sync_binlog=0，即不执行强制磁盘刷新命令。这个时候，性能最好，但风险也最好。因为一旦系统崩溃，binlog_cache中的所有binlog信息都会丢失。而当它设置为“1”时，它是性能损失最小的最安全设置。因为设置为1时，即使系统崩溃，也最多丢失binlog_cache中一个未完成的事务，对实际数据没有实质影响。根据以往的经验和相关测试，对于高并发事务的系统，“sync_binlog”设置为0和1的系统写入性能差距可能高达5倍甚至更多。5、如果数据库有很多事务性操作，建议将二进制日志的回滚上限设置大一些：对于事务性表，比如BDB或者InnoDB表，所有更新（UPDATE、DELETE或者INSERT）)更改表被缓存，直到服务器收到COMMIT语句。此时，mysqld在执行COMMIT之前将整个事务写入二进制日志。当事务线程启动时，它会分配binlog_cache_size内存用于缓冲查询。如果语句大于这个值，线程会打开一个临时文件来保存事务[所以如果bunlog_cache_size足够大，可以避免过多的磁盘I/O操作，所有数据都可以缓存在内存中]。临时文件在线程结束后被删除。["max_binlog_cache_size"：对应"binlog_cache_size"，但代表binlog可以使用的最大缓存内存大小。当我们执行多语句事务时，如果max_binlog_cache_size不够大，系统可能会报错“Multi-statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage”。所以***还要调大max_binlog_cache_size（具体大小取决于你的服务器）]6.Binlog日志尽量把max_binlog_size设置大一些。一般设置为512M或1G，但不能超过1G。这个大小不能严格控制Binlog的大小，尤其是当Binlog接近尾声，遇到大事务时，为了保证事务的完整性，系统不能切换日志，只能把所有的SQL都记录进去当前日志，直到事务结束。7.下面是mysql环境的情况：mysql>showvariableslike'%binlog%';+-------------------------------+------------+|变量名|值|+--------------------------------+------------+|binlog_cache_size|1048576||innodb_locks_unsafe_for_binlog|OFF||max_binlog_cache_size|4294967295||max_binlog_size|1073741824||sync_binlog|0|+--------------------------------+------------+博客来源：http://my.oschina.net/u/1759688/blog/384530
