mysql 日志

MySQL有几个不同的日志文件，可以帮助你找出mysqld内部发生的事情：

 

日志文件	记入文件中的信息类型
错误日志	记录启动、运行或停止mysqld时出现的问题。
查询日志	记录建立的客户端连接和执行的语句。
更新日志	记录更改数据的语句。不赞成使用该日志。
二进制日志	记录所有更改数据的语句。还用于复制。
慢日志	记录所有执行时间超过long_query_time秒的所有查询或不使用索引的查询。

默认情况下，所有日志创建于mysqld数据目录中。通过刷新日志，你可以强制 mysqld来关闭和重新打开日志文件

 

执行一个FLUSH LOGS语句或执行mysqladmin flush-logs或mysqladmin refresh时，出现日志刷新

 

错误日志

错误日志文件包含了当mysqld启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。

用--log-error[=file_name]选项来指定mysqld保存错误日志文件的位置。

如果没有给定file_name值，mysqld使用错误日志名host_name.err 并在数据目录中写入日志文件。

如果你执行FLUSH LOGS，错误日志用-old重新命名后缀并且mysqld创建一个新的空日志文件。(如果未给出--log-error选项，则不会重新命名）。

在Windows中，如果未给出--console选项，错误输出总是写入.err文件。

通用查询日志

如果你想要知道mysqld内部发生了什么，你应该用--log[=file_name]或-l [file_name]选项启动它。

如果没有给定file_name的值， 默认名是host_name.log。所有连接和语句被记录到日志文件。当你怀疑在客户端发生了错误并想确切地知道该客户端发送给mysqld的语句时，该日志可能非常有用。

 

在Unix中，你可以通过下面的命令重新命名文件并创建一个新文件：

shell> mv hostname.log hostname-old.log

shell> mysqladmin flush-logs

shell> cp hostname-old.log to-backup-directory

shell> rm hostname-old.log

在Windows中，服务器打开日志文件期间你不能重新命名日志文件。你必须先停止服务器然后重新命名日志文件。然后，重启服务器来创建新的日志文件。

在mysql 5.5 中  可以使用--general-log 或者 --general-log-file 选项来启动mysql 

二进制日志

二进制日志以一种更有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息。

二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述数据更改。

注释：二进制日志已经代替了老的更新日志，更新日志在MySQL 5.1中不再使用。

二进制日志还包含关于每个更新数据库的语句的执行时间信息。它不包含没有修改任何数据的语句。如果你想要记录所有语句（例如，为了识别有问题的查询），你应使用一般查询日志。

二进制日志的主要目的是在恢复使能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新。

二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。

运行服务器时若启用二进制日志则性能大约慢1%。但是，二进制日志的好处，即用于恢复并允许设置复制超过了这个小小的性能损失。

 

当用--log-bin[=file_name]选项启动时，mysqld写入包含所有更新数据的SQL命令的日志文件。如果未给出file_name值， 默认名为-bin后面所跟的主机名。如果给出了文件名，但没有包含路径，则文件被写入数据目录。

 

如果你在日志名中提供了扩展名(例如，--log-bin=file_name.extension)，则扩展名被悄悄除掉并忽略。

 

每次启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到max_binlog_size，还会自动创建新的二进制日志。如果正使用大的事务，二进制日志还会超过max_binlog_size：事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。

 

为了能够知道还使用了哪个不同的二进制日志文件，mysqld还创建一个二进制日志索引文件，包含所有使用的二进制日志文件的文件名。默认情况下与二进制日志文件的文件名相同，扩展名为'.index'。你可以用--log-bin-index[=file_name]选项更改二进制日志索引文件的文件名。当mysqld在运行时，不应手动编辑该文件；如果这样做将会使mysqld变得混乱。

 

可以用RESET MASTER语句删除所有二进制日志文件，或用PURGE MASTER LOGS只删除部分二进制文件。

 

--binlog-do-db=db_name   如果使用该选项，你应确保只对当前的数据库进行更新。其它所有没有明显指定的数据库  被忽略。

--binlog-ignore-db=db_name  

 

可以用mysqlbinlog实用工具检查二进制日志文件。

例如，可以从二进制日志更新MySQL服务器，方法如下：

shell> mysqlbinlog log-file | mysql -h server_name

如果你正使用事务，必须使用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服务器)崩溃，有可能二进制日志中最后的语句丢失了。要想防止这种情况，你可以使用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表相同。

 

慢速查询日志

用--log-slow-queries[=file_name]选项启动时，mysqld写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件。获得初使表锁定的时间不算作执行时间。

如果没有给出file_name值， 默认未主机名，后缀为-slow.log。如果给出了文件名，但不是绝对路径名，文件则写入数据目录。

 

日志文件维护

MySQL服务器可以创建各种不同的日志文件，从而可以很容易地看见所进行的操作。参见5.11节，“MySQL日志文件”。但是，你必须定期清理这些文件，确保日志不会占用太多的硬盘空间。

当启用日志使用MySQL时，你可能想要不时地备份并删除旧的日志文件，并告诉MySQL开始记入新文件。参见5.9.1节，“数据库备份”。

在 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”。

 

MySQL处理磁盘满的方式

在本节中，介绍了MySQL响应磁盘满错误的方式（如“设备上无剩余空间”），以及响应超配额错误的方式（如“写入失败”或“达到了用户屏蔽限制”）。

本节介绍的内容与写入MyISAM表有关。它也适用于写入二进制日志文件和二进制索引文件，但对“row”和“record”的应用应被视为“event”。

出现磁盘满状况时，MySQL将：

每分钟检查一次，查看是否有足够空间写入当前行。如果有足够空间，将继续，就像什么也未发生一样。

每10分钟将1个条目写入日志文件，提醒磁盘满状况。

为了减轻问题，可采取下述措施：

要想继续，仅需有足够的磁盘空间以插入所有记录。

要想放弃线程，必须使用mysqladmin kill。下次检查磁盘时将放弃线程（1分钟）。

其他线程可能会正在等待导致磁盘满状况的表。如果有数个“已锁定”的线程，杀死正在磁盘满状况下等待的某一线程，以便允许其他线程继续。

对前述行为的例外是，当你使用REPAIR TABLE或OPTIMIZE TABLE时，或当索引是在LOAD DATA INFILE或ALTER TABLE语句后、在批操作中创建的。所有这些语句能创建大的临时文件，如果保留这些文件，会导致系统其他部分出现大问题。如果在MySQL执行这类操作的同时磁盘已满，它将删除大的临时文件，并将表标注为崩溃。但对于ALTER TABLE例外，旧表保持不变。

MySQL将临时文件储存在哪里

MySQL使用环境变量TMPDIR的值作为保存临时文件的目录的路径名。如果未设置TMPDIR，MySQL将使用系统的默认值，通常为/tmp、/var/tmp或/usr/tmp。如果包含临时文件目录的文件系统过小，可对mysqld使用“—tmpdir”选项，在具有足够空间的文件系统内指定1个目录。

在MySQL 5.1中，“—tmpdir”选项可被设置为数个路径的列表，以循环方式使用。在Unix平台上，路径用冒号字符“:”隔开，在Windows、NetWare和OS/2平台上，路径用分号字符“;”隔开。注意，为了有效分布负载，这些路径应位于不同的物理磁盘上，而不是位于相同磁盘的不同分区中。

如果MySQL服务器正作为复制从服务器使用，不应将“--tmpdir”设置为指向基于内存的文件系统的目录，或当服务器主机重启时将清空的目录。对于复制从服务器，需要在机器重启时仍保留一些临时文件，以便能够复制临时表或执行LOAD DATA INFILE操作。如果在服务器重启时丢失了临时文件目录下的文件，复制将失败。

MySQL会以隐含方式创建所有的临时文件。这样，就能确保中止mysqld时会删除所有临时文件。使用隐含文件的缺点在于，在临时文件目录所在的位置中，看不到占用了文件系统的大临时文件。

进行排序时（ORDER BY或GROUP BY），MySQL通常会使用1个或多个临时文件。所需的最大磁盘空间由下述表达式决定：

(length of what is sorted + sizeof(row pointer))

* number of matched rows

* 2

“row pointer”（行指针）的大小通常是4字节，但在以后，对于大的表，该值可能会增加。

对于某些SELECT查询，MySQL还会创建临时SQL表。它们不是隐含表，并具有SQL_*形式的名称。

ALTER TABLE会在与原始表目录相同的目录下创建临时表。

如何保护或更改MySQL套接字文件/tmp/mysql.sock

对于服务器用来与本地客户端进行通信的Unix套接字文件，其默认位置是/tmp/mysql.sock。这有可能导致问题，原因在于，在某些版本的Unix上，任何人都能删除/tmp目录下的文件。

在大多数Unix版本中，可对/tmp目录进行保护，使得文件只能被其所有这或超级用户（根用户）删除。为此，以根用户身份登录，并使用下述命令在/tmp目录上设置粘着位：

shell> chmod +t /tmp

通过执行ls -ld /tmp，可检查是否设置了粘着位。如果最后一个许可字符是“t”，表明设置了粘着位。

另一种方法是改变服务器创建Unix套接字文件的位置。如果进行了这类操作，还应让客户端程序知道文件的位置。能够以多种不同方式指定文件位置：

在全局或局部选项文件中指定路径。例如，将下述行置于文件/etc/my.cnf中：

[mysqld]

socket=/path/to/socket

 

[client]

socket=/path/to/socket

请参见4.3.2节，“使用选项文件”。

在运行客户端程序时，在命令行上为mysqld_safe指定“--socket”选项。

将MYSQL_UNIX_PORT环境变量设置为Unix套接字文件的路径。

重新从源码编译MySQL，以使用不同的默认Unix套接字文件位置。运行configure时，用“--with-unix-socket-path”选项定义文件路径。请参见2.8.2节，“典型配置选项”。

用下述命令连接服务器，能够测试新的套接字位置是否工作：

shell> mysqladmin --socket=/path/to/socket version

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

show 语句

 

1.显示当前数据库中所有表的名称

show tables 或 show tables from database_name

2.显示Mysql 中所有数据库的名称

show databases

3.显示表中列的名称

show columns from table_name from database_name

show columns from database_name.table_name

4.显示一个用户的权限，

show grants for user_name

5.显示表的索引

show index from table_name

6.显示一些系统特定资源的信息，如：正在运行的线程数量

show status

7.显示系统变量

show variables

8.显示系统中正在运行的所有进程,也就是当前正在执行的查询.

show processlist

9.显示当前使用或者指定的数据库中的每个表的信息

show table status

10.显示服务器所支持的不同权限

show privileges

11.显示创建某个数据库的 create database 语句

show create database database_name

12.显示创建某个表的 create table 语句

show create table table_name

13.显示所有事件列表

show events

14.显示innodb存储引擎的状态

show innodb status

15.显示BDB存储引擎的日志

show logs

16.显示最后一个执行语句所产生的错误，警告，通知

show warnings

17.显示最后一个执行语句所产生的错误

show errors

18.显示安装后的可用存储引擎和默认引擎

show engines

19.显示数据库中的所有存储过程基本信息，包括所属数据库，存储过程名称，创建时间

show procedure status

20. 显示一个存储过程的详细信息

show create procedure sp_name

21.显示mysql 字符集支持

show character set

22.显示字符集校对规则

show collation

23. sHOW FULL COLUMNS FROM person\G

 

 

character_set_client

来自客户端的语句的字符集。

character_set_connection

用于没有字符集导入符的文字和数字－字符串转换。

character_set_database

默认数据库使用的字符集。当默认数据库更改时，服务器则设置该变量。如果没有默认数据库，变量的值同character_set_server。

 

 character_set_results

用于向客户端返回查询结果的字符集。

 character_set_ server

服务器的默认字符集。

 character_set_system

服务器用来保存识别符的字符集。该值一定是utf8。

 

  character_sets_dir

字符集安装目录。

·         collation_connection

连接字符集的校对规则。

·         collation_database

默认数据库使用的校对规则。当默认数据库改变时服务器则设置该变量。如果没有默认数据库，变量的值同collation_server。

·         collation_server

服务器的默认校对规则。

 

 show variables like 'collation_%';   show variables like 'character_set_%';

通过MySQL命令行修改:

mysql> set character_set_client=utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set character_set_connection=utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set character_set_database=utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set character_set_results=utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set character_set_server=utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set character_set_system=utf8;
Query OK, 0 rows affected (0.01 sec)

mysql> set collation_connection=utf8;
Query OK, 0 rows affected (0.01 sec)

mysql> set collation_database=utf8;
Query OK, 0 rows affected (0.01 sec)

mysql> set collation_server=utf8;
Query OK, 0 rows affected (0.01 sec)

对于字符集的支持细化到四个层次:

服务器(server)，数据库(database)，数据表(table)和连接(connection)。