mysql性能查询以及简单处理

摘要

由于最近碰到很多关于mysql性能的问题,如:cpu、内存跑满,或者连接数跑满(rds)等,记录一下在排查过程中用到的一些查询语句,本文目前大部分资料摘自网络,很多地方不太完善,后期可能会进行更新(看心情)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
show processlist;
show full processlist;
select * from information_scema.processlist;
select concat('KILL ',id,';') from information_schema.processlist where ...;
show open tables;
show status like '%lock%';
show engine innodb status\G;
show variables like '%timeout%';
show status;
show create table table_name;
show index from table_name;
show table status from table_name;
show table status from db_name where name="table_name";
alter table table_name engine=innodb;
alter table table_name engine=myisam;

大部分资料取自网络

show processlist;

显示哪些线程正在运行。您也可以使用mysqladmin processlist语句得到此信息。如果您有SUPER权限,您可以看到所有线程。否则,您只能看到您自己的线程(也就是,与您正在使用的MySQL账户相关的线程)。

如果您得到“too many connections”错误信息,并且想要了解正在发生的情况,本语句是非常有用的。MySQL保留一个额外的连接,让拥有SUPER权限的 账户使用,以确保管理员能够随时连接和检查系统(假设您没有把此权限给予所有的用户)。

1
2
3
4
5
6
7
8
9
10
show processlist;
Id: 会话id
User: 执行用户
Host: 执行主机
db: 数据库名
Command:
Time: 执行时间
State: 数据库状态(重要)
Info: 执行sql(前100字符)

一般情况下,大致看一下是否有大量类似的sql,如果有,则很有可能是大量性能很差的sql造成的。如果需要查看完整sql信息,可以执行:

1
2
3
show full processlist;
or
select * from information_scema.processlist;

如果能定位到sql,其实就可以进行下一步处理了。

如果出现大量影响不大的sql(如select,一些不要紧、定时执行并且可以后续重复执行的update),可以临时通过执行kill杀掉当前会话。

1
kill 会话id

批量kill

1
select concat('KILL ',id,';') from information_schema.processlist where ...;

kill会话毕竟只是临时解决方案,治标不治本,真正要提高性能还要从优化sql入手(注:sql优化请看另一篇sql执行计划)。

以下取自网络

这个命令中最关键的就是state列,mysql列出的状态主要有以下几种:

  • Checking table: 正在检查数据表(这是自动的)。
  • Closing tables: 正在将表中修改的数据刷新到磁盘中,同时正在关闭已经用完的表。这是一个很快的操作,如果不是这样的话,就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。
  • Connect Out: 复制从服务器正在连接主服务器。
  • Copying to tmp table on disk: 由于临时结果集大于tmp_table_size,正在将临时表从内存存储转为磁盘存储以此节省内存。
  • Creating tmp table: 正在创建临时表以存放部分查询结果。
  • deleting from main table: 服务器正在执行多表删除中的第一部分,刚删除第一个表。
  • deleting from reference tables: 服务器正在执行多表删除中的第二部分,正在删除其他表的记录。
  • Flushing tables: 正在执行FLUSH TABLES,等待其他线程关闭数据表。
  • Killed: 发送了一个kill请求给某线程,那么这个线程将会检查kill标志位,同时会放弃下一个kill请求。MySQL会在每次的主循环中检查kill标志位,不过有些情况下该线程可能会过一小段才能死掉。如果该线程程被其他线程锁住了,那么kill请求会在锁释放时马上生效。
  • Locked: 被其他查询锁住了。
  • Sending data: 正在处理SELECT查询的记录,同时正在把结果发送给客户端。
  • Sorting for group: 正在为GROUP BY做排序。
  • Sorting for order: 正在为ORDER BY做排序。
  • Opening tables: 这个过程应该会很快,除非受到其他因素的干扰。例如,在执ALTER TABLE或LOCK TABLE语句行完以前,数据表无法被其他线程打开。正尝试打开一个表。
  • Removing duplicates: 正在执行一个SELECT DISTINCT方式的查询,但是MySQL无法在前一个阶段优化掉那些重复的记录。因此,MySQL需要再次去掉重复的记录,然后再把结果发送给客户端。
  • Reopen table: 获得了对一个表的锁,但是必须在表结构修改之后才能获得这个锁。已经释放锁,关闭数据表,正尝试重新打开数据表。
  • Repair by sorting: 修复指令正在排序以创建索引。
  • Repair with keycache: 修复指令正在利用索引缓存一个一个地创建新索引。它会比Repair by sorting慢些。
  • Searching rows for update: 正在讲符合条件的记录找出来以备更新。它必须在UPDATE要修改相关的记录之前就完成了。
  • Sleeping: 正在等待客户端发送新请求.
  • System lock: 正在等待取得一个外部的系统锁。如果当前没有运行多个mysqld服务器同时请求同一个表,那么可以通过增加–skip-external-locking参数来禁止外部系统锁。
  • Upgrading lock: INSERT DELAYED正在尝试取得一个锁表以插入新记录。
  • Updating: 正在搜索匹配的记录,并且修改它们。
  • User Lock: 正在等待GET_LOCK()。
  • Waiting for tables: 该线程得到通知,数据表结构已经被修改了,需要重新打开数据表以取得新的结构。然后,为了能的重新打开数据表,必须等到所有其他线程关闭这个表。以下几种情况下会产生这个通知:FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。
  • waiting for handler insert: INSERT DELAYED已经处理完了所有待处理的插入操作,正在等待新的请求。
     
    大部分状态对应很快的操作,只要有一个线程保持同一个状态好几秒钟,那么可能是有问题发生了,需要检查一下。

还有其他的状态没在上面中列出来,不过它们大部分只是在查看服务器是否有存在错误是才用得着。

show open tables;

这条命令能够查看当前有那些表是打开的。

1
2
3
4
5
6
7
show open tables;
show open tables from database(库名);
Database: 数据库名
Table: 表名
In_use: 有多少线程正在使用某张表
Name_locked: 表是否被锁,这一般发生在DropRename命令操作这张表时。
所以这条命令通常不能帮助解答我们常见的问题:当前某张表是否有死锁,谁拥有表上的这个锁等;但是我们能够看到当前哪个表被大量sql操作,以此来针对某个业务模块的sql进行优化。

show status like ‘%lock%’;

查看数据库锁状态

show engine innodb status\G;

查看innodb引擎状态

show variables like ‘%timeout%’;

查看数据库超时情况

show status;

查询数据库当前状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Aborted_clients 由于客户没有正确关闭连接已经死掉,已经放弃的连接数量。
Aborted_connects 尝试已经失败的MySQL服务器的连接的次数。
Connections 试图连接MySQL服务器的次数。
Created_tmp_tables 当执行语句时,已经被创造了的隐含临时表的数量。
Delayed_insert_threads 正在使用的延迟插入处理器线程的数量。
Delayed_writes 用INSERT DELAYED写入的行数。
Delayed_errors 用INSERT DELAYED写入的发生某些错误(可能重复键值)的行数。
Flush_commands 执行FLUSH命令的次数。
Handler_delete 请求从一张表中删除行的次数。
Handler_read_first 请求读入表中第一行的次数。
Handler_read_key 请求数字基于键读行。
Handler_read_next 请求读入基于一个键的一行的次数。
Handler_read_rnd 请求读入基于一个固定位置的一行的次数。
Handler_update 请求更新表中一行的次数。
Handler_write 请求向表中插入一行的次数。
Key_blocks_used 用于关键字缓存的块的数量。
Key_read_requests 请求从缓存读入一个键值的次数。
Key_reads 从磁盘物理读入一个键值的次数。
Key_write_requests 请求将一个关键字块写入缓存次数。
Key_writes 将一个键值块物理写入磁盘的次数。
Max_used_connections 同时使用的连接的最大数目。
Not_flushed_key_blocks 在键缓存中已经改变但是还没被清空到磁盘上的键块。
Not_flushed_delayed_rows 在INSERT DELAY队列中等待写入的行的数量。
Open_tables 打开表的数量。
Open_files 打开文件的数量。
Open_streams 打开流的数量(主要用于日志记载)
Opened_tables 已经打开的表的数量。
Questions 发往服务器的查询的数量。
Slow_queries 要花超过long_query_time时间的查询数量。
Threads_connected 当前打开的连接的数量。
Threads_running 不在睡眠的线程数量。
Uptime 服务器工作了多少秒。

开启慢查询日志

在my.ini中:

1
2
long_query_time=1
log-slow-queries=/data/logs/mysql_log/mysqlslow.log

把超过1秒的记录在慢查询日志中

可以用mysqlsla来分析之。也可以在mysqlreport中,有如

DMS分别分析了select ,update,insert,delete,replace等所占的百分比

MYSQL的事务配置项

1
innodb_flush_log_at_trx_commit=1

表示事务提交时立即把事务日志flush写入磁盘,同时数据和索引也更新,很费性能。

1
innodb_flush_log_at_trx_commit=0

事务提交时,不立即把事务日志写入磁盘,每隔1秒写一次,MySQL挂了可能会丢失事务的数据。

1
innodb_flush_log_at_trx_commit=2

在整个操作系统 挂了时才可能丢数据,一般不会丢失超过1-2秒的更新。

事务提交时,立即写入磁盘文件(这里只是写入到系统内核缓冲区,但不立即刷新到磁盘,而是每隔1秒刷新到磁盘,同时更新数据和索引),这种方案是不是性价比好一些,当然如何配置,决定于你对系统数据安全性的要求