mysql> show status like ‘Table%’;

+—————————-+———-+

| Variable_name        | Value |

+—————————-+———-+

| Table_locks_immediate | 105         |

| Table_locks_waited   | 3           |

+—————————-+———-+

2 rows in set (0.00 sec)

如果Table_locks_waited的值比较高，则说明存在着较严重的表级锁争用情况。这时，需要我们对应用做进一步的检查，来确定问题所在。

从内存的使用方式MySQL 数据库的内存使用主要分为以下两类

* 线程独享内存
* 全局共享内存

今天这篇文章暂时先分析 MySQL 中主要的 “线程独享内存” 的。

在 MySQL 中，线程独享内存主要用于各客户端连接线程存储各种操作的独享数据，如线程栈信息，分组排序操作，数据读写缓冲，结果集暂存等等，而且大多数可以通过相关参数来控制内存的使用量。

线程栈信息使用内存(thread_stack)：主要用来存放每一个线程自身的标识信息，如线程id，线程运行时基本信息等等，我们可以通过 thread_stack 参数来设置为每一个线程栈分配多大的内存。

排序使用内存(sort_buffer_size)：MySQL 用此内存区域进行排序操作（filesort），完成客户端的排序请求。当我们设置的排序区缓存大小无法满足排序实际所需内存的时候，MySQL 会将数据写入磁盘文件来完成排序。由于磁盘和内存的读写性能完全不在一个数量级，所以sort_buffer_size参数对排序操作的性能影响绝对不可 小视。排序操作的实现原理请参考：MySQL Order By 的实现分析。

Join操作使用内存(join_buffer_size)：应用程序经常会出现一些两表（或多表）Join的操作需求，MySQL在完成某些 Join 需求的时候（all/index join），为了减少参与Join的“被驱动表”的读取次数以提高性能，需要使用到 Join Buffer 来协助完成 Join操作（具体 Join 实现算法请参考：MySQL 中的 Join 基本实现原理）。当 Join Buffer 太小，MySQL 不会将该 Buffer 存入磁盘文件，而是先将Join Buffer中的结果集与需要 Join 的表进行 Join 操作，然后清空 Join Buffer 中的数据，继续将剩余的结果集写入此 Buffer 中，如此往复。这势必会造成被驱动表需要被多次读取，成倍增加 IO 访问，降低效率。

顺序读取数据缓冲区使用内存(read_buffer_size)：这部分内存主要用于当需要顺序读取数据的时候，如无发使用索引的情况下的全表 扫描，全索引扫描等。在这种时候，MySQL 按照数据的存储顺序依次读取数据块，每次读取的数据快首先会暂存在read_buffer_size中，当 buffer 空间被写满或者全部数据读取结束后，再将buffer中的数据返回给上层调用者，以提高效率。

随机读取数据缓冲区使用内存(read_rnd_buffer_size)：和顺序读取相对应，当 MySQL 进行非顺序读取（随机读取）数据块的时候，会利用这个缓冲区暂存读取的数据。如根据索引信息读取表数据，根据排序后的结果集与表进行Join等等。总的来 说，就是当数据块的读取需要满足一定的顺序的情况下，MySQL 就需要产生随机读取，进而使用到 read_rnd_buffer_size 参数所设置的内存缓冲区。

连接信息及返回客户端前结果集暂存使用内存(net_buffer_size)：这部分用来存放客户端连接线程的连接信息和返回客户端的结果集。 当 MySQL 开始产生可以返回的结果集，会在通过网络返回给客户端请求线程之前，会先暂存在通过 net_buffer_size 所设置的缓冲区中，等满足一定大小的时候才开始向客户端发送，以提高网络传输效率。不过，net_buffer_size 参数所设置的仅仅只是该缓存区的初始化大小，MySQL 会根据实际需要自行申请更多的内存以满足需求，但最大不会超过 max_allowed_packet 参数大小。

批量插入暂存使用内存(bulk_insert_buffer_size)：当我们使用如 insert … values(…),(…),(…)… 的方式进行批量插入的时候，MySQL 会先将提交的数据放如一个缓存空间中，当该缓存空间被写满或者提交完所有数据之后，MySQL 才会一次性将该缓存空间中的数据写入数据库并清空缓存。此外，当我们进行 LOAD DATA INFILE 操作来将文本文件中的数据 Load 进数据库的时候，同样会使用到此缓冲区。

临时表使用内存(tmp_table_size)：当我们进行一些特殊操作如需要使用临时表才能完成的 Order By，Group By 等等，MySQL 可能需要使用到临时表。当我们的临时表较小（小于 tmp_table_size 参数所设置的大小）的时候，MySQL 会将临时表创建成内存临时表，只有当 tmp_table_size 所设置的大小无法装下整个临时表的时候，MySQL 才会将该表创建成 MyISAM 存储引擎的表存放在磁盘上。不过，当另一个系统参数 max_heap_table_size 的大小还小于 tmp_table_size 的时候，MySQL 将使用 max_heap_table_size 参数所设置大小作为最大的内存临时表大小，而忽略 tmp_table_size 所设置的值。而且 tmp_table_size 参数从 MySQL 5.1.2 才开始有，之前一直使用 max_heap_table_size。

上面所列举的 MySQL 线程独享内存仅仅只是所有线程独享内存中的部分，并不是全部，选择的原则是可能对 MySQL 的性能产生较大的影响，且可以通过系统参数进行调节。

由于以上内存都是线程独享，极端情况下的内存总体使用量将是所有连接线程的总倍数。所以各位朋友在设置过程中一定要谨慎，切不可为了提升性能就盲目的增大各参数值，避免因为内存不够而产生 Out Of Memory 异常或者是严重的 Swap 交换反而降低整体性能。

内容方面有任何技术问题，欢迎各位朋友来拍砖，交流分享的过程也是对自身的提升。

shell> mysqlbinlog [options] log-files…
例如，要想显示二进制日志binlog.000003的内容，使用下面的命令：

shell> mysqlbinlog binlog.0000003
输出包括在binlog.000003中包含的所有语句，以及其它信息例如每个语句花费的时间、客户发出的线程ID、发出线程时的时间戳等等。

通常情况，可以使用mysqlbinlog直接读取二进制日志文件并将它们用于本地MySQL服务器。也可以使用–read-from-remote-server选项从远程服务器读取二进制日志。

当读取远程二进制日志时，可以通过连接参数选项来指示如何连接服务器，但它们经常被忽略掉，除非你还指定了–read-from-remote-server选项。这些选项是–host、–password、–port、–protocol、–socket和–user。

还可以使用mysqlbinlog来读取在复制过程中从服务器所写的中继日志文件。中继日志格式与二进制日志文件相同。
在5.11.3节，“二进制日志”中详细讨论了二进制日志。

mysqlbinlog支持下面的选项：

· —help，-？

显示帮助消息并退出。

· —database=db_name，-d db_name

只列出该数据库的条目(只用本地日志)。

· –force-read，-f

使用该选项，如果mysqlbinlog读它不能识别的二进制日志事件，它会打印警告，忽略该事件并继续。没有该选项，如果mysqlbinlog读到此类事件则停止。

· –hexdump，-H

在注释中显示日志的十六进制转储。该输出可以帮助复制过程中的调试。在MySQL 5.1.2中添加了该选项。

· –host=host_name，-h host_name

获取给定主机上的MySQL服务器的二进制日志。

· –local-load=path，-l pat

为指定目录中的LOAD DATA INFILE预处理本地临时文件。

· –offset=N，-o N

跳过前N个条目。

· –password[=password]，-p[password]

当连接服务器时使用的密码。如果使用短选项形式(-p)，选项和 密码之间不能有空格。如果在命令行中–password或-p选项后面没有 密码值，则提示输入一个密码。

· –port=port_num，-P port_num

用于连接远程服务器的TCP/IP端口号。

· –position=N，-j N

不赞成使用，应使用–start-position。

· –protocol={TCP | SOCKET | PIPE | -position

使用的连接协议。

· –read-from-remote-server，-R

从MySQL服务器读二进制日志。如果未给出该选项，任何连接参数选项将被忽略。这些选项是–host、–password、–port、–protocol、–socket和–user。

· –result-file=name, -r name

将输出指向给定的文件。

· –short-form，-s

只显示日志中包含的语句，不显示其它信息。

· –socket=path，-S path

用于连接的套接字文件。

· –start-datetime=datetime

从二进制日志中第1个日期时间等于或晚于datetime参量的事件开始读取。datetime值相对于运行mysqlbinlog的机器上的本地时区。该值格式应符合DATETIME或TIMESTAMP数据类型。例如：

shell> mysqlbinlog –start-datetime=”2004-12-25 11:25:56″ binlog.000003
该选项可以帮助点对点恢复。

· –stop-datetime=datetime

从二进制日志中第1个日期时间等于或晚于datetime参量的事件起停止读。关于datetime值的描述参见–start-datetime选项。该选项可以帮助及时恢复。

· –start-position=N

从二进制日志中第1个位置等于N参量时的事件开始读。

· –stop-position=N

从二进制日志中第1个位置等于和大于N参量时的事件起停止读。

· –to-last-logs，-t

在MySQL服务器中请求的二进制日志的结尾处不停止，而是继续打印直到最后一个二进制日志的结尾。如果将输出发送给同一台MySQL服务器，会导致无限循环。该选项要求–read-from-remote-server。

· –disable-logs-bin，-D

禁用二进制日志。如果使用–to-last-logs选项将输出发送给同一台MySQL服务器，可以避免无限循环。该选项在崩溃恢复时也很有用，可以避免复制已经记录的语句。注释：该选项要求有SUPER权限。

· –user=user_name，-u user_name

连接远程服务器时使用的MySQL用户名。

· –version，-V

显示版本信息并退出。

还可以使用–var_name=value选项设置下面的变量：

· open_files_limit

指定要保留的打开的文件描述符的数量。

可以将mysqlbinlog的输出传到mysql客户端以执行包含在二进制日志中的语句。如果你有一个旧的备份，该选项在崩溃恢复时也很有用(参见5.9.1节，“数据库备份”)：

shell> mysqlbinlog hostname-bin.000001 | mysql
或：

shell> mysqlbinlog hostname-bin.[0-9]* | mysql
如果你需要先修改含语句的日志，还可以将mysqlbinlog的输出重新指向一个文本文件。(例如，想删除由于某种原因而不想执行的语句)。编辑好文件后，将它输入到mysql程序并执行它包含的语句。

mysqlbinlog有一个–position选项，只打印那些在二进制日志中的偏移量大于或等于某个给定位置的语句(给出的位置必须匹配一个事件的开始)。它还有在看见给定日期和时间的事件后停止或启动的选项。这样可以使用–stop-datetime选项进行点对点恢复(例如，能够说“将数据库前滚动到今天10:30 AM的位置”)。

如果MySQL服务器上有多个要执行的二进制日志，安全的方法是在一个连接中处理它们。下面是一个说明什么是不安全的例子：

shell> mysqlbinlog hostname-bin.000001 | mysql # DANGER!!
shell> mysqlbinlog hostname-bin.000002 | mysql # DANGER!!
使用与服务器的不同连接来处理二进制日志时，如果第1个日志文件包含一个CREATE TEMPORARY TABLE语句，第2个日志包含一个使用该临时表的语句，则会造成问题。当第1个mysql进程结束时，服务器撤销临时表。当第2个mysql进程想使用该表时，服务器报告 “不知道该表”。

要想避免此类问题，使用一个连接来执行想要处理的所有二进制日志中的内容。下面提供了一种方法：

shell> mysqlbinlog hostname-bin.000001 hostname-bin.000002 | mysql
另一个方法是：

shell> mysqlbinlog hostname-bin.000001 > /tmp/statements.sql
shell> mysqlbinlog hostname-bin.000002 >> /tmp/statements.sql
shell> mysql -e “source /tmp/statements.sql”
mysqlbinlog产生的输出可以不需要原数据文件即可重新生成一个LOAD DATA INFILE操作。mysqlbinlog将数据复制到一个临时文件并写一个引用该文件的LOAD DATA LOCAL INFILE语句。由系统确定写入这些文件的目录的默认位置。要想显式指定一个目录，使用–local-load选项。

因为mysqlbinlog可以将LOAD DATA INFILE语句转换为LOAD DATA LOCAL INFILE语句(也就是说，它添加了LOCAL)，用于处理语句的客户端和服务器必须配置为允许LOCAL操作。参见5.6.4节，“LOAD DATA LOCAL安全问题”。

警告：为LOAD DATA LOCAL语句创建的临时文件不会自动删除，因为在实际执行完那些语句前需要它们。不再需要语句日志后应自己删除临时文件。文件位于临时文件目录中，文件名类似original_file_name-#-#。

–hexdump选项可以在注释中产生日志内容的十六进制转储：

shell> mysqlbinlog –hexdump master-bin.000001
上述命令的输出应类似：

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#051024 17:24:13 server id 1 end_log_pos 98
# Position Timestamp Type Master ID Size Master Pos Flags
# 00000004 9d fc 5c 43 0f 01 00 00 00 5e 00 00 00 62 00 00 00 00 00
# 00000017 04 00 35 2e 30 2e 31 35 2d 64 65 62 75 67 2d 6c |..5.0.15.debug.l|
# 00000027 6f 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |og…………..|
# 00000037 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
# 00000047 00 00 00 00 9d fc 5c 43 13 38 0d 00 08 00 12 00 |…….C.8……|
# 00000057 04 04 04 04 12 00 00 4b 00 04 1a |…….K…|
# Start: binlog v 4, server v 5.0.15-debug-log created 051024 17:24:13
# at startup
ROLLBACK;
十六进制转储的输出包含下面的元素：

· Position: The byte position within the log file.

· Timestamp: The event timestamp. In the example just shown, ’9d fc 5c 43′ is the representation of ’051024 17:24:13′ in hexadecimal.

· Type: The type of the log event. ’0f’ means that the example event is a FORMAT_DESCRIPTION_EVENT. The types are:

· 00 UNKNOWN_EVENT
· This event should never be present in the log.
· 01 START_EVENT_V3
· This indicates the start of a log file written by MySQL 4 or earlier.
· 02 QUERY_EVENT
· The most common type of events. These contain queries executed
· on the master.
· 03 STOP_EVENT
· Indicates that master has stopped.
· 04 ROTATE_EVENT
· Written when the master switches to a new log file.
· 05 INTVAR_EVENT
· Used mainly for AUTO_INCREMENT values and if the LAST_INSERT_ID()
· function is used in the statement.
· 06 LOAD_EVENT
· Used for LOAD DATA INFILE in MySQL 3.23.
· 07 SLAVE_EVENT
· Reserved for future use.
· 08 CREATE_FILE_EVENT
· Used for LOAD DATA INFILE statements. This indicates the start
· of execution of such a statement. A temporary file is created
· on the slave. Used in MySQL 4 only.
· 09 APPEND_BLOCK_EVENT
· Contains data for use in a LOAD DATA INFILE statement. The
· data is stored in the temporary file on the slave.
· 0a EXEC_LOAD_EVENT
· Used for LOAD DATA INFILE statements. The contents of the
· temporary file is stored in the table on the slave.
· Used in MySQL 4 only.
· 0b DELETE_FILE_EVENT
· Rollback of LOAD DATA INFILE statement. The temporary file
· should be deleted on slave.
· 0c NEW_LOAD_EVENT
· Used for LOAD DATA INFILE in MySQL 4 and earlier.
· 0d RAND_EVENT
· Used to send information about random values if the RAND()
· function is used in the query.
· 0e USER_VAR_EVENT
· Used to replicate user variables.
· 0f FORMAT_DESCRIPTION_EVENT
· This indicates the start of a log file written by MySQL 5 or later.
· 10 XID_EVENT
· Event indicating commit of XA transaction
· 11 BEGIN_LOAD_QUERY_EVENT
· Used for LOAD DATA statements in MySQL 5 and later.
· 12 EXECUTE_LOAD_QUERY_EVENT
· Used for LOAD DATA statements in MySQL 5 and later.
· 13 TABLE_MAP_EVENT
· Reserved for future use
· 14 WRITE_ROWS_EVENT
· Reserved for future use
· 15 UPDATE_ROWS_EVENT
· Reserved for future use
· 16 DELETE_ROWS_EVENT
· Reserved for future use
· Master ID: The server id of the master that created the event.

· Size: The size in bytes of the event.

· Master Pos: The position of the event in the original master log file.

· Flags: 16 flags.

· 01 LOG_EVENT_BINLOG_IN_USE_F
· Log file correctly closed (Used only in FORMAT_DESCRIPTION_EVENT)
· If this flag is set (if the flags are e.g. ’01 00′) in an
· FORMAT_DESCRIPTION_EVENT, then the log file has not been
· properly closed. Most probably because of a master crash (for
· example, due to power failure).
· 02 Reserved for future use.
· 04 LOG_EVENT_THREAD_SPECIFIC_F
· Set if the event is dependent on the connection it was
· executed in (example ’04 00′), e.g. if the event uses
· temporary tables.
· 08 LOG_EVENT_SUPPRESS_USE_F
· Set in some circumstances when the event is not dependent on
· the current database
其它标志保留用于将来使用。

在以后的版本中十六进制转储输出的格式可能会改变。

我们将要详细的讲到MySQL的剖析(Profiling),因为它很少依赖于你的应用。应用和服务器 级别的剖析有的时候都是有必要的。虽然应用级别的剖析可以给你整个应用性能的总揽。，但是对MySQL的剖析提供了信息是服务器级别所提供不了的。比如， 对PHP代码进行剖析不会显示MySQL有多少行语句执行了。

与应用剖析一样，目标是找出MySQL哪部分消耗过多的时间。我们不会剖析MySQL源码的，虽然有的 时候定制化MySQL安装很有用，但是这是另一本书的主题了。所替代的是，我们将教你一些可以技术来获取和分析不同种类的MySQL执行语句的信息。

你可以用在任意的颗粒级别以满足你的需求：你可能对整个服务器进行剖析或者单独检查一个语句或者一组语 句。下列信息你可以一点点的收集：

• MySQL经常访问的那些数据
• MySQL经常执行语句的类型
• MySQL线程大部分时间的状态
• MySQL经常执行语句的子系统
• MySQL执行语句所访问的数据类型
• 不同活动的类型，比如扫描索引。

记录执行的语句

MySQL有两种记录语句的类型：general log和slow log。他们都是记录执行语句，但是却在语句执行进程的两端。general log记录了每个服务器收到的语句，因此它的语句可能包含了那些没有执行导致错误的语句。general Log记录了所有的语句，包括了一些非执行语句的事件，比如连接和断开连接。你可以用一个指令来启用它。

log = <file_name>

根据设计，general log不会包括执行时间和其他一些仅仅在语句执行完毕的信息。相比较而言，slow log记录执行完毕的语句。尤其是，它记录那些超过指定时间执行的语句。这两种日志都对程序剖析很有用，但是slow log是获取问题语句的主要工具。我们常常推荐把它开启。

下面列出的配置会开启这个日志。获取所有执行时间超过2s的语句，以及记录那些不使用索引的语句。它也 会记录一些执行慢的管理语句，比如OPTIMIZE TABLE:

log-slow-queries  = <file_name>

long_query_time  = 2

log-queries-not-using-indexes

log-slow-admin-statements

你可以自定义这些配置，然后把它们放到my.conf文件中。更多的服务器配置将在以后的章节详细讲 述。

long_query_time的默认值是10s。这个设置太慢了，因此我们一般都设置它为2s。然 而，对于许多应用，可能1s都非常慢了。我们在下一部分将讲述如何获得颗粒度更细的日志。

在MySQL5.1中，提供了运行时调整 slow_query_log，slow_query_log_file参数来控制slow log.但是在MySQL5.0中，在不启动MySQL的情况下，不能开闭slow log。对于MySQL5.0的变通方法是，可以动态的修改long_query_time变量。下面的语句虽然不是真正开启slow log的方式，但是取得了同样的效果。（如果有语句执行超过了10000s，那么你需要优化了这些语句了）

mysql> SET GLOBAL long_query_time = 10000;

相关配置变量，log_queries_not_using_indexes 使服务器记录没有使用索引的语句。而不管它们的执行时间。虽然开启了slow log会增加一些时间的消耗，导致语句执行速度减慢，但是没有使用索引的语句还是可以经常和非常快速的执行。（比如一些查询一些数据量小的表）这样会使降 低服务器的速度，以及使用大量的硬盘空间保存日志。

不幸的是，在MySQL5.0中不能动态的开启或关闭日志。你必须修改MySQL配置文件，然后重启 MySQL。当你想关闭日志而不想重启服务器，可以把日志文件做一个/dev/null的指向。在确定了MySQL关闭了日志文件描述以及在/dev /null重新打开它，那么你仅执行FLUSH LOGS就可以了。

相比较而言，MySQL5.1能实时更改日志以及能把日志记录到表中。这是个很大的进步了。

细颗粒度的日志

MySQL5.0以及更早的版本的slow log 都有一定的限制，在一些用途下就没用了。最首要的问题就是它的颗粒度仅仅是秒。以及long_query_time在MySQL5.0中最小单位就是 1s。大部分交互的应用中，这个时间就比较长了。如果你正在开发一个高性能的WEB应用，你可能希望整个页面生成小于1s.以及在开始生成的过程中记录许 多语句。这种情况下，一个语句执行了150ms，也会被认为是个很慢的语句。

另一个问题是，并不是所有的执行语句都记录在slow log中（尤其是，子节点的线程语句不能被记录）。general log记录了所有的语句，但是是在这些语句解析之前记录的，只要就不能记录一些如执行时间，锁时间，以及执行的行数的记录了。只有slow log包含这些信息。

最终，如果你开启了log_queries_not_using_indexes参数。可能slow log就被大量的实体，高效的语句所填满。比如，如果你过你生成一个下拉菜单的数据，你可能执行SELECT * FROM STATES。这个语句就被记录了，因为它是整张表的扫描。

当程序剖析的目标是性能优化，你应该查看让MySQL服务器大量工作的语句。这并不是意味着总是执行慢 的语句。所以记录执行慢的语句可能也没什么用处了。一个例子，一个10ms的语句在一秒内执行了1000次对服务器的压力高于10s语句每秒运行一次。为 了发现这个问题，你必须记录每条语句和分析结果。

一起查看执行慢的语句和导致服务器压力过大的语句执行总量是非常有用的方法。这会让你发现不同的问题。 如一个语句导致了很差的用户体验。

我们已经开发了一个MySQL的补丁。基于Georg Richter工作之上而开发的。让你指定slow log语句时间到毫秒级别，而不是原来的秒。通过设置long_query_time=0，它也能让你记录所有的语句。这个补丁的地址是 http://www.mysqlperformanceblog.com/mysql-patches/。它的主要缺点就是你需要自己编译MySQL。 因为这个补丁在MySQL5.1之前并没有包含在MySQL发行包中。

目前，MySQL5.1包含了这个补丁，但仅能修改时间的颗粒度。这个补丁的新版本，将不会包含在 MySQL的发行包中。新版本将添加一些有用的功能。这些功能包含了语句执行的连接ID，也包含了语句执行的缓存，连接类型，临时表，以及排序。也添加了 InnoDB的统计，比如I/O行为以及锁等待。

新版本的补丁可以记录子节点所执行的语句。如果在子节点复制的过程中出现问题，这个功能就尤其有用。它 也能让你选择一些会话的日志。这些功能对程序剖析来说已经足够了，我们认为这就是最佳实践了。

这个补丁是比较新的，因此如果你要应用，要小心的使用它。我们想它已经很安全了，但是它在其他的 MySQL服务器还没有经过足够的考验。如果你担心这个还有补丁的MySQL服务器的稳定性，你不一定要一直运行它，你可以先运行它几个小时记录一些语 句，然后在恢复你自己的MySQL版本。

当程序剖析的时候，把参数long_query_time=0记录所有语句是个很好的方法。如果大部分 的读取来自于非常简单的语句，你可能想知道这些情况。记录所有语句会影响一些性能以及它要求更多的硬盘空间-这就是另一个不需要记录所有语句的理由。幸运 的是，你可以随时修改long_query_time而不用去重新启动服务器。因此很容易在一段时间内获取所有语句。然后在恢复记录那些执行比较慢的语 句。

怎样读取slow log

这是一个slow log的例子

1 # Time: 030303 0:51:27

2 # User@Host: root[root] @ localhost []

3 # Query_time: 25 Lock_time: 0 Rows_sent: 3949 Rows_examined: 378036

4 SELECT …

第一行显示了日志记录的时间，第二行显示谁执行了这些语句。第三行显示这语句执行的时间，在MySQL 服务器级别等待表锁的时间，执行语句返回的行数，以及语句检索的行数。这些语句都是被注视掉的。因此如果你把日志提供给MySQL Client,他们也不会执行。最后一行就是执行的语句。

这个例子是MySQL5.1版本的

1 # Time: 070518 9:47:00

2 # User@Host: root[root] @ localhost []

3 # Query_time: 0.000652 Lock_time: 0.000109 Rows_sent: 1 Rows_examined: 1

4 SELECT …

和上个日志基本相同，除了第三行，精度变得更高了。上一部分我们提到的补丁提供了更全面的信息

1 # Time: 071031 20:03:16

2 # User@Host: root[root] @ localhost []

3 # Thread_id: 4

4 # Query_time: 0.503016 Lock_time: 0.000048 Rows_sent: 56 Rows_examined: 1113

5 # QC_Hit: No Full_scan: No Full_join: No Tmp_table: Yes Disk_tmp_table: No

6 # Filesort: Yes Disk_filesort: No Merge_passes: 0

7 # InnoDB_IO_r_ops: 19 InnoDB_IO_r_bytes: 311296 InnoDB_IO_r_wait: 0.382176

8 # InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.067538

9 # InnoDB_pages_distinct: 20

10 SELECT …

第五行显示了这个语句是否使用了缓存，是否检索了整张表，是否没有用索引进行表连接，是否是否临时表， 以及临时表是否创建在硬盘上。第六行给出了是否进行了文件排序以及，如果是，是否保存到硬盘上以及有多少合并排序通过它执行的。

如果语句执行在InnoDB上，第7，8，9行就会显示。第7行显示了在执行语句的时候，InnoDB 计划读取的页数，与它一起的是byte数值。第7行最后的一个值是InnoDB从硬盘读取数据的时间。第8行显示了语句等待行锁以及用了多少时间等待进入 InnoDB内核。

第9行显示了语句访问唯一InnoDB大约的页面数。这个数值越大，准确度貌似就越低了。这个信息的一 种用处就是估计在页面中语句的工作集。这个就是InnoDB缓冲池缓存数据的方式。它也能显示你的集群索引是非常的有用。如果这个语句的行很好的集群索引 了，它们会填充更少的页面。以后会讲到集群索引。

使用slow log去解决慢语句并不总是很简单。虽然log包含了很多有用的信息，但是一个非常重要的信息却丢失了：那就是语句执行为什么会这么慢的一个想法。有的时 候，这是显而易见的。如果log得出了12，000，000行被检查以及1，200，000被发送到了客户端，你知道为什么这么慢的原因了–这是个很大 的执行语句。然而，这是很难的的清晰。

要注意的是，不要给slow log添加过多的含义。如果你看到一条语句在log中出现多次，那就发现了这语句很慢以及需要优化。但是仅仅因为一个语句在log出现的频率并不意味着它 是个糟糕的语句或者甚至并不是缓慢的。你可能找到了一个很慢的语句，运行它，以及发现它执行的时间只是一眨眼的时间。出现在日志中只能说明在过去的那个时 候这个语句执行时间很长，并不意味着现在或以后它会执行很长时间。一个语句有的时候很慢，在另外的时间却很快，这种情况原因是很多的：

• 一个表可能被锁定了，导致了语句必须去等待。Lock_time指明了这个语句等待锁释放的时间。
• 数据或者索引没有被缓存。在MySQL刚启动的时候或还没有调整好的情况下，这种问题很常见。
• 可能是备份正在执行，导致了硬盘I/O很慢。
• 这个服务器同时还运行着其他语句，导致了这个语句很慢。

日志分析工具

现在你已经记录了一些执行的语句了。是时候分析结果了。一般的策略是找出对服务器影响最大的语句，用 Explain检查它们执行计划进行必要的调整。在调整之后不断地重复这个过程。因为你的修改可能会影响其他语句的执行。比较常见的就是索引可以提高 SELECT的速度但是会降低INSERT或UPDATE语句。

一般来说你应该在日志中查找如下的执行语句：

1. Long queries(运行时间长的语句)：固定时间的批量任务使语句执行缓慢，但是正常的语句不应该执行的很慢。
2. High-impact queries(影响大的语句)：找出那些占用服务器执行大部分时间的语句。还记得上一部分说过的执行时间短的语句占用了很多时间。
3. new queries(新出现的语句)：找出那些昨天还没有在前100个，但是今天却出现的语句。这些语句可能是新出现的也可能是被很快的运行以及正在变得糟 糕。可能因为不同的索引或者其他别的什么改变。

mysqldumpslow：

mysql_slow_log_filter：

如果索引正在工作， Handler_read_key 的值将很高，这个值代表了一个行被索引值读的次数，很低的值表明增加索引得到的性能改善不高，因为索引并不经常使用。

Handler_read_rnd_next 的值高则意味着查询运行低效，并且应该建立索引补救。这个值的含义是在数据文件中读下一行的请求数。如果你正进行大量的表扫描，该值较高。通常说明表索引不正确或写入的查询没有利用索引。

语法：

mysql> show status like ‘Handler_read%’;

基本概念

• 字符(Character)是指人类语言中最小的表义符号。例如’A’、’B’等；

• 给定一系列字符，对每个字符赋予一个数值，用数值来代表对应的字符，这一数值就是字符的编码(Encoding)。例如，我们给字符’A’赋予数值0，给 字符’B’赋予数值1，则0就是字符’A’的编码；

• 给定一系列字符并赋予对应的编码后，所有这些字符和编码对组成的集合就是字符集(Character Set)。例如，给定字符列表为{’A’,’B’}时，{’A’=>0, ‘B’=>1}就是一个字符集；

• 字符序(Collation)是指在同一字符集内字符之间的比较规则；

• 确定字符序后，才能在一个字符集上定义什么是等价的字符，以及字符之间的大小关系；

• 每个字符序唯一对应一种字符集，但一个字符集可以对应多种字符序，其中有一个是默认字符序(Default Collation)；

• MySQL中的字符序名称遵从命名惯例：以字符序对应的字符集名称开头；以_ci(表示大小写不敏感)、_cs(表示大小写敏感)或_bin(表示按编码 值比较)结尾。例如：在字符序“utf8_general_ci”下，字符“a”和“A”是等价的； MySQL字符集设置

• 系统变量：

– character_set_server：默认的内部操作字符集

– character_set_client：客户端来源数据使用的字符集

– character_set_connection：连接层字符集

– character_set_results：查询结果字符集

– character_set_database：当前选中数据库的默认字符集

– character_set_system：系统元数据(字段名等)字符集

– 还有以collation_开头的同上面对应的变量，用来描述字符序。

• 用introducer指定文本字符串的字符集：

– 格式为：[_charset] ’string’ [COLLATE collation]

– 例如：

• SELECT _latin1 ’string’;

• SELECT _utf8 ‘你好’ COLLATE utf8_general_ci;

– 由introducer修饰的文本字符串在请求过程中不经过多余的转码，直接转换为内部字符集处理。

MySQL中的字符集转换过程

1. MySQL Server收到请求时将请求数据从character_set_client转换为character_set_connection；

2. 进行内部操作前将请求数据从character_set_connection转换为内部操作字符集，其确定方法如下：

• 使用每个数据字段的CHARACTER SET设定值；

• 若上述值不存在，则使用对应数据表的DEFAULT CHARACTER SET设定值(MySQL扩展，非SQL标准)；

• 若上述值不存在，则使用对应数据库的DEFAULT CHARACTER SET设定值；

• 若上述值不存在，则使用character_set_server设定值。

3. 将操作结果从内部操作字符集转换为character_set_results。

常见问题解析

• 向默认字符集为utf8的数据表插入utf8编码的数据前没有设置连接字符集，查询时设置连接字符集为utf8

– 插入时根据MySQL服务器的默认设置，character_set_client、character_set_connection和 character_set_results均为latin1；

– 插入操作的数据将经过latin1=>latin1=>utf8的字符集转换过程，这一过程中每个插入的汉字都会从原始的3个字节变成6个字 节保存；

– 查询时的结果将经过utf8=>utf8的字符集转换过程，将保存的6个字节原封不动返回，产生乱码……

• 向默认字符集为latin1的数据表插入utf8编码的数据前设置了连接字符集为utf8

– 插入时根据连接字符集设置，character_set_client、character_set_connection和 character_set_results均为utf8；

– 插入数据将经过utf8=>utf8=>latin1的字符集转换，若原始数据中含有\u0000~\u00ff范围以外的Unicode字 符，会因为无法在latin1字符集中表示而被转换为“?”(0×3F)符号，以后查询时不管连接字符集设置如何都无法恢复其内容了。

检测字符集问题的一些手段

• SHOW CHARACTER SET;

• SHOW COLLATION;

• SHOW VARIABLES LIKE ‘character%’;

• SHOW VARIABLES LIKE ‘collation%’;

• SQL函数HEX、LENGTH、CHAR_LENGTH

• SQL函数CHARSET、COLLATION

使用MySQL字符集时的建议

• 建立数据库/表和进行数据库操作时尽量显式指出使用的字符集，而不是依赖于MySQL的默认设置，否则MySQL升级时可能带来很大困扰；

• 数据库和连接字符集都使用latin1时虽然大部分情况下都可以解决乱码问题，但缺点是无法以字符为单位来进行SQL操作，一般情况下将数据库和连接字符 集都置为utf8是较好的选择；

• 使用mysql C API时，初始化数据库句柄后马上用mysql_options设定MYSQL_SET_CHARSET_NAME属性为utf8，这样就不用显式地用 SET NAMES语句指定连接字符集，且用mysql_ping重连断开的长连接时也会把连接字符集重置为utf8；

• 对于mysql PHP API，一般页面级的PHP程序总运行时间较短，在连接到数据库以后显式用SET NAMES语句设置一次连接字符集即可；但当使用长连接时，请注意保持连接通畅并在断开重连后用SET NAMES语句显式重置连接字符集。

其他注意事项

• my.cnf中的default_character_set设置只影响mysql命令连接服务器时的连接字符集，不会对使用 libmysqlclient库的应用程序产生任何作用！

• 对字段进行的SQL函数操作通常都是以内部操作字符集进行的，不受连接字符集设置的影响。

• SQL语句中的裸字符串会受到连接字符集或introducer设置的影响，对于比较之类的操作可能产生完全不同的结果，需要小心！

create table test(
id int,name1 varchar(300),
name2 varchar(300),
name3 varchar(500)
)charset=latin1 engine=myisam;

create index test_name on test(name1,name2,name3);

此时报错：Specified key was too long;max key length is 1000 bytes.

修改表结构:alter table test convert to charset utf8;
create index test_name3 on test(name3).
此时warning：Specified key was too long;max key length is 1000 bytes.但是索引创建成功，查看表结构可以看到创建的索引是一个前缀索引:‘key test_name3(name3(333))’

得出的结论是：对于myisam表，如果创建组合索引，所创建的索引长度和不能超过1000 bytes，否则会报错，创建失败；而对于myisam的单列索引，最大长度也不能超过1000，否则会报警，但是创建成功，最终创建的是前缀索引（取前 333个字节）。

在Innodb表中,创建组合索引：

create table test1(
id int,name1 varchar(300),
name2 varchar(300),
name3 varchar(500)
)charset=latin1 engine=innodb;
create index test1_name on test(name1,name2,name3);
此时给出warning：Specified key was too long;max key length is 767 bytes.

修改表结构:alter table test1 convert to charset utf8;
create index test1_name3 on test(name3).
此时给出warning：Specified key was too long;max key length is 767 bytes.

得出的结论是：对于创建innodb的组合索引，如果各个列中的长度不超过767，则不再计算所有列的总长度，如果有超过767的，则给出报警，索引最后创建成功，但是对于超过767字节的列取前缀索引；而对于 innodb的单列索引，超过767的，给出warning，最终索引创建成功，取前缀索引（取前255字节）。

来源：http://samyubw.blog.51cto.com/978243/223773

This section does not apply to MySQL Enterprise Server users.

SHOW PROFILE [type [, type] ... ]      [FOR QUERY n]      [LIMIT row_count [OFFSET offset]]    type:      ALL    | BLOCK IO    | CONTEXT SWITCHES    | CPU    | IPC    | MEMORY    | PAGE FAULTS    | SOURCE    | SWAPS

The SHOW PROFILES and SHOW PROFILE statements display profiling information that indicates resource usage for statements executed during the course of the current session.

Profiling is controlled by the profiling session variable, which has a default value of 0 (OFF). Profiling is enabled by setting profiling to 1 or ON:

mysql> SET profiling = 1;  

SHOW PROFILES displays a list of the most recent statements sent to the master. The size of the list is controlled by the profiling_history_size session variable, which has a default value of 15. The maximum value is 100. Setting the value to 0 has the practical effect of disabling profiling.

All statements are profiled except SHOW PROFILES and SHOW PROFILE, so you will find neither of those statements in the profile list. Malformed statements are profiled. For example, SHOW PROFILING is an illegal statement, and a syntax error occurs if you try to execute it, but it will show up in the profiling list.

SHOW PROFILE displays detailed information about a single statement. Without the FOR QUERY n clause, the output pertains to the most recently executed statement. If FOR QUERY n is included, SHOW PROFILE displays information for statement n. The values of n correspond to the Query_ID values displayed by SHOW PROFILES.

The LIMIT row_count clause may be given to limit the output to row_count rows. If LIMIT is given, OFFSEToffset may be added to begin the output offset rows into the full set of rows.

By default, SHOW PROFILE displays Status and Duration columns. The Status values are like the State values displayed by SHOW PROCESSLIST, althought there might be some minor differences in interpretion for the two statements for some status values (see Section 7.5.6, “Examining Thread Information”).

Optional type values may be specified to display specific additional types of information:

Profiling is enabled per session. When a session ends, its profiling information is lost.

mysql> SELECT @@profiling;  +-------------+  | @@profiling |  +-------------+  |           0 |  +-------------+  1 row in set (0.00 sec)    mysql> SET profiling = 1;  Query OK, 0 rows affected (0.00 sec)    mysql> DROP TABLE IF EXISTS t1;  Query OK, 0 rows affected, 1 warning (0.00 sec)    mysql> CREATE TABLE T1 (id INT);  Query OK, 0 rows affected (0.01 sec)    mysql> SHOW PROFILES;  +----------+----------+--------------------------+  | Query_ID | Duration | Query                    |  +----------+----------+--------------------------+  |        0 | 0.000088 | SET PROFILING = 1        |  |        1 | 0.000136 | DROP TABLE IF EXISTS t1  |  |        2 | 0.011947 | CREATE TABLE t1 (id INT) |  +----------+----------+--------------------------+  3 rows in set (0.00 sec)    mysql> SHOW PROFILE;  +----------------------+----------+  | Status               | Duration |  +----------------------+----------+  | checking permissions | 0.000040 |  | creating table       | 0.000056 |  | After create         | 0.011363 |  | query end            | 0.000375 |  | freeing items        | 0.000089 |  | logging slow query   | 0.000019 |  | cleaning up          | 0.000005 |  +----------------------+----------+  7 rows in set (0.00 sec)    mysql> SHOW PROFILE FOR QUERY 1;  +--------------------+----------+  | Status             | Duration |  +--------------------+----------+  | query end          | 0.000107 |  | freeing items      | 0.000008 |  | logging slow query | 0.000015 |  | cleaning up        | 0.000006 |  +--------------------+----------+  4 rows in set (0.00 sec)    mysql> SHOW PROFILE CPU FOR QUERY 2;  +----------------------+----------+----------+------------+  | Status               | Duration | CPU_user | CPU_system |  +----------------------+----------+----------+------------+  | checking permissions | 0.000040 | 0.000038 |   0.000002 |  | creating table       | 0.000056 | 0.000028 |   0.000028 |  | After create         | 0.011363 | 0.000217 |   0.001571 |  | query end            | 0.000375 | 0.000013 |   0.000028 |  | freeing items        | 0.000089 | 0.000010 |   0.000014 |  | logging slow query   | 0.000019 | 0.000009 |   0.000010 |  | cleaning up          | 0.000005 | 0.000003 |   0.000002 |  +----------------------+----------+----------+------------+  7 rows in set (0.00 sec)

SHOW PROFILES and SHOW PROFILE were added in MySQL 5.0.37.

You can also get profiling information from the PROFILING table in INFORMATION_SCHEMA. See Section 19.17, “The INFORMATION_SCHEMA PROFILING Table”. For example, the following queries produce the same result:

SHOW PROFILE FOR QUERY 2;    SELECT STATE, FORMAT(DURATION, 6) AS DURATION  FROM INFORMATION_SCHEMA.PROFILING  WHERE QUERY_ID = 2 ORDER BY SEQ;