1 、参数文件及mysql参数
查看mysql 的 my.cnf 配置文件位置命令：>./bin/mysql --help | grep my.cnf
查看mysql 的参数设置命令： mysql > show variables --显示所有参数; // show variables like 'log_error%' 显示某匹配参数
mysql > select @@session.read_buffer_size; 查看当前session的read_buffer_size
mysql > select @@global.read_buffer_size; 查看全局的read_buffer_sizemysql > set @@session.read_buffer_size=1024000; 设置当前session的read_buffer_size
mysql > set @@session.read_buffer_size=1024000; 设置当前session的read_buffer_size
2、日志文件
my.cnf 的启动选项
========数据库日志选项(值为[file_name])========--log 常规日志文件
--log_bin 二进制变更日志文件
--log-bin-index 二进制变更日志文件索引文件
--log-update 变更日志文件
--log-slow-queries 慢查询日志文件
--log-isam ISAM/MyISAM日志文件
--log-long-format 设置慢查询日志和变更日志的格式
--bdb-logdir 存放BDB日志文件的位置
--innodb-log_arch_dir 存放InnoDB日志文件的归档位置
--innodb_log_group_home_dir 存放InnoDB日志文件的位置
1) 错误日志 (my.cnf 配置文件中使用 log-error [=file_name] 设置，在SQL中使用 mysql> show variables like 'log_error%'; 查看位置)错误日志文件包含了当mysqld启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。
如果mysqld莫名其妙地死掉并且mysqld_safe需要重新启动它，mysqld_safe在错误日志中写入一条restarted mysqld消息。如果mysqld注意到需要自 动检查或着修复一个表，则错误日志中写入一条消息。
在一些操作系统中，如果mysqld死掉，错误日志包含堆栈跟踪信息。跟踪信息可以用来确定mysqld死掉的地方（参见“使用堆栈跟踪”）。
如果在启动参数文件中没有给定log-error 的值，mysqld使用错误日志名host_name.err 并在数据目录中写入日志文件。如果你执行FLUSH LOGS，错 误日志用-old重新命名后缀并且mysqld创建一个新的空日志文件。(如果未给出--log-error选项，则不会重新命名）。
如果不指定--log-error，或者(在Windows中)如果你使用--console选项，错误被写入标准错误输出stderr。通常标准输出为你的终端。在Windows中， 如果未给出--console选项，错误输出总是写入.err文件。
2）查询日志（my.cnf 配置文件中使用 log[=file_name] 设置，或者在mysql启动时使用 -l file_name启动参数设置，默认值为 host_name.log）查询日志是记录建立的客户端连接和执行的语句， mysql按照它接收的顺序记语句到log文件中，这样你就可以查看 mysql 内部发生了什么；查询日志与
更新日志和二进制日志不同， 它们在查询执行后，但是任何一个锁释放之前记录日志（它还包括所有语句，而二进制文件不包含只查询语句）
服务器重新启动和日志刷新不会产生新的一般查询日志文件(尽管刷新关闭并重新打开一般查询日志文件)。
在Unix中，你可以通过下面的命令重新命名文件并创建一个新文件：简单的mv、rm、cp 命令 或者使用 mysqladmin flush-logs。
在Windows中，你只能通过先停止服务器， 把日志文件重命名再启动服务器来创建新的日志文件。
3)二进制日志 (my.cnf配件文件中使用 log-bin [=file_name]设置，默认值为 -bin_hostname)
二进制日志以一种更有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息（5.1后的版本中不再使用 更新日志）二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个 DELETE或UPDATE）的所有语句。语句以“事件”的形式保存， 它描述数据更改。 二进制日志还包含关于每个更新数据库的语句的执行时间信息，但它不包含没有修改任何数据的语句。
>二进制日志的主要目的是在恢复使能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新；
>二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句
>二进制默认写入至数据目录，以-bin<hostname>.00001 mysqld自动在每个日志后面添加一个数据扩展名 ，当前的日志大小达到 max_binlog_size 时自动创建新的二进制日志，一个事务只能写入同一个日志文件中。
>mysqld创建一个二进制日志索引文件，包含所有使用的二进制日志文件的文件名，使用户能知道 哪个不同的二进制日志文件。默认情况下二进制日志索 引 文件与二进制日志文件的文件名相同， 扩展名为".index"。
>你可以用--log-bin-index[=file_name]选项更改二进制日志索引文件的文件名;当mysqld在运行时，不应手动编辑该文件；如果这样做将会使mysqld变 得 混乱。可以用RESET MASTER语句删除所有二进制日志文件，或用PURGE MASTER LOGS只删除部分二进制文件。
二进制日志格式有一些已知限制，会影响从备份恢复。参见“复制特性和已知问题”。
>保存程序和触发器的二进制日志的描述参，“存储子程序和触发程序的二进制日志功能”。
可以使用下面的mysqld选项来影响记录到二进制日志知的内容。又见选项后面的讨论。
--binlog-do-db=db_name
告诉主服务器，如果当前的数据库(即USE选定的数据库)是db_name，应将更新记录到二进制日志中。其它所有没有明显指定的数据库 被忽略。如果使用该选项，你应确保只对当前的数据库进行更新。对于CREATE DATABASE、ALTER DATABASE和DROP DATABASE语句，有一个例外，即通过操作的数据库来决定是否应记录语句，而不是用当前的数据库。
--binlog-ignore-db=db_name
告诉主服务器，如果当前的数据库(即USE选定的数据库)是db_name，不应将更新保存到二进制日志中。如果你使用该选项，你应确保只对当前的数据库进行更新。
类似于--binlog-do-db，对于CREATE DATABASE、ALTER DATABASE和DROP DATABASE语句，有一个例外，即通过操作的数据库来决定是否应记录语句，而不是用当前的数据库。
要想记录或忽视多个数据库，使用多个选项，为每个数据库指定相应的选项。
服务器根据下面的规则对选项进行评估，以便将更新记录到二进制日志中或忽视。请注意对于CREATE/ALTER/DROP DATABASE语句有一个例外。在这些情况下，根据以下规则，所创建、修改或删除的数据库将代替当前的数据库。
1. 是否有binlog-do-db或binlog-ignore-db规则?
· 没有：将语句写入二进制日志并退出。
· 有：执行下一步。
2. 有一些规则(binlog-do-db或binlog-ignore-db或二者都有)。当前有一个数据库(USE是否选择了数据库?)?
· 没有：不要写入语句，并退出。
· 有：执行下一步。
3. 有当前的数据库。是否有binlog-do-db规则?
· 有：当前的数据库是否匹配binlog-do-db规则?
o 有：写入语句并退出。
o 没有：不要写入语句，退出。
· No：执行下一步。
4. 有一些binlog-ignore-db规则。当前的数据库是否匹配binlog-ignore-db规则?
· 有：不要写入语句，并退出。
· 没有：写入查询并退出。
例如，只用binlog-do-db=sales运行的服务器不将当前数据库不为sales的语句写入二进制日志(换句话说，binlog-do-db有时可以表示“忽视其它数据库”)。
如果你正进行复制，应确保没有从服务器在使用旧的二进制日志文件，方可删除它们。一种方法是每天一次执行mysqladmin flush-logs并删除三天前的所有日志。可以手动删除，或最好使用PURGE MASTER LOGS(参见“用于控制主服务器的SQL语句”)，该语句还会安全地更新二进制日志索引文件(可以采用日期参数)。
具有SUPER权限的客户端可以通过SET SQL_LOG_BIN=0语句禁止将自己的语句记入二进制记录。参见13.5.3节，“SET语法”。你可以用mysqlbinlog实用工具检查二进制日志文件。如果你想要重新处理日志止的语句，这很有用。例如，可以从二进制日志更新MySQL服务器，方法如下：
shell> mysqlbinlog log-file | mysql -h server_name
关于mysqlbinlog实用工具的详细信息以及如何使用它，参见“mysqlbinlog：用于处理二进制日志文件的实用工具”。
如果你正使用事务，必须使用MySQL二进制日志进行备份，而不能使用旧的更新日志。
查询结束后、锁定被释放前或提交完成后则立即记入二进制日志。这样可以确保按执行顺序记入日志。
对非事务表的更新执行完毕后立即保存到二进制日志中。对于事务表，例如BDB或InnoDB表，所有更改表的更新(UPDATE、DELETE或INSERT) 被缓存起来，直到服务器接收到COMMIT语句。在该点，执行完COMMIT之前，mysqld将整个事务写入二进制日志。当处理事务的线程启动时，它为缓冲查询分配binlog_cache_size大小的内存。如果语句大于该值，线程则打开临时文件来保存事务。线程结束后临时文件被删除。
Binlog_cache_use状态变量显示了使用该缓冲区(也可能是临时文件)保存语句的事务的数量。Binlog_cache_disk_use状态变量显示了这些事务中实际上有多少必须使用临时文件。这两个变量可以用于将binlog_cache_size调节到足够大的值，以避免使用临时文件。
max_binlog_cache_size(默认4GB)可以用来限制用来缓存多语句事务的缓冲区总大小。如果某个事务大于该值，将会失败并 回滚。
如果你正使用更新日志或二进制日志，当使用CREATE ... SELECT or INSERT ... SELECT时，并行插入被转换为普通插入。这样通过在备份时使用日志可以确保重新创建表的备份。
请注意MySQL 5.1值的二进制日志格式与以前版本的MySQL不同，因为复制改进了。参见“不同MySQL版本之间的复制兼容性”。
默认情况下，并不是每次写入时都将二进制日志与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能二进制日志中最后的语句丢失了。要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使二进制日志在每N次二进制日志写入后与硬盘同步。参见5.3.3节，“服务器系统变量”。即使sync_binlog设置为1,出现崩溃时，也有可能表内容和二进制日志内容之间存在不一致性。例如，如果使用InnoDB表，MySQL服务器处理COMMIT语句，它将整个事务写入二进制日志并将事务提交到InnoDB中。如果在两次操作之间出现崩溃，重启时，事务被InnoDB回滚，但仍然存在二进制日志中。可以用--innodb-safe-binlog选项解决该问题，可以增加InnoDB表内容和二进制日志之间的一致性。(注释：在MySQL 5.1中不需要--innodb-safe-binlog；由于引入了XA事务支持，该选项作废了）。
该选项可以提供更大程度的安全，还应对MySQL服务器进行配置，使每个事务的二进制日志(sync_binlog =1)和(默认情况为真)InnoDB日志与硬盘同步。该选项的效果是崩溃后重启时，在滚回事务后，MySQL服务器从二进制日志剪切 回滚的InnoDB事务。这样可以确保二进制日志反馈InnoDB表的确切数据等，并使从服务器保持与主服务器保持同步(不接收 回滚的语句)。
请注意即使MySQL服务器更新其它存储引擎而不是InnoDB，也可以使用--innodb-safe-binlog。在InnoDB崩溃恢复时，只从二进制日志中删除影响InnoDB表的语句/事务。如果崩溃恢复时MySQL服务器发现二进制日志变短了(即至少缺少一个成功提交的InnoDB事务)，如果sync_binlog =1并且硬盘/文件系统的确能根据需要进行同步(有些不需要)则不会发生，则输出错误消息 ("二进制日志<名>比期望的要小")。在这种情况下，二进制日志不准确，复制应从主服务器的数据快照开始。
写入二进制日志文件和二进制日志索引文件的方法与写入MyISAM表相同。参见A.4.3节，“MySQL处理磁盘满的方式”。
4) 慢速查询日志 用--log-slow-queries[=file_name]选项启动时，mysqld写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件。获得初使表锁定的时间不算作执行时间。如果没有给出file_name值， 默认未主机名，后缀为-slow.log。如果给出了文件名，但不是绝对路径名，文件则写入数据目录。语句执行完并且所有锁释放后记入慢查询日志。记录顺序可以与执行顺序不相同。
>慢查询日志可以用来找到执行时间长的查询，可以用于优化。但是，检查又长又慢的查询日志会很困难。要想容易些，你可以使用mysqldumpslow命令获得日志中显示的查询摘要来处理慢查询日志。
>在MySQL 5.1的慢查询日志中，不使用索引的慢查询同使用索引的查询一样记录。要想防止不使用索引的慢查询记入慢查询日志，使用--log-short-format选项。参见，“mysqld命令行选项”。>在MySQL 5.1中,通过--log-slow-admin-statements服务器选项，你可以请求将慢管理语句，例如OPTIMIZE TABLE、ANALYZE TABLE和 ALTER TABLE写入慢查询日志。
>用查询缓存处理的查询不加到慢查询日志中，因为表有零行或一行而不能从索引中受益的查询也不写入慢查询日志。
3、 日志文件维护
MySQL服务器可以创建各种不同的日志文件，从而可以很容易地看见所进行的操作。参见“MySQL日志文件”。但是，你必须定期清理这些文件，确保日志不会占用太多的硬盘空间。当启用日志使用MySQL时，你可能想要不时地备份并删除旧的日志文件，并告诉MySQL开始记入新文件。参见“数据库备份”。
在 Linux (Redhat)的安装上，你可为此使用mysql-log-rotate脚本。如果你从RPM分发安装MySQL，脚本应该自动被安装了。
在其它系统上，你必须自己安装短脚本，你可从cron等入手处理日志文件。
你可以通过mysqladmin flush-logs或SQL语句FLUSH LOGS来强制MySQL开始使用新的日志文件。
日志清空操作做下列事情：
如果使用标准日志(--log)或慢查询日志(--log-slow-queries)，关闭并重新打开日志文件。(默认为mysql.log和`hostname`-slow.log)。
如果使用更新日志(--log-update)或二进制日志(--log-bin)，关闭日志并且打开有更高序列号的新日志文件。
如果你只使用更新日志，你只需要重新命名日志文件，然后在备份前清空日志。例如，你可以这样做：
shell> cd mysql-data-directory
shell> mv mysql.log mysql.old
shell> mysqladmin flush-logs
然后做备份并删除“mysql.old”。