mysql性能查询以及简单处理

发表于 | 更新于 | 分类于 ， | 评论数： | 阅读次数：
本文字数： 5.3k | 阅读时长 ≈ 5 分钟

摘要

本文部分内容来源于网络，个人收集整理，请勿传播

由于最近碰到很多关于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: 表是否被锁，这一般发生在Drop或Rename命令操作这张表时。
所以这条命令通常不能帮助解答我们常见的问题：当前某张表是否有死锁，谁拥有表上的这个锁等；但是我们能够看到当前哪个表被大量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秒刷新到磁盘，同时更新数据和索引），这种方案是不是性价比好一些，当然如何配置，决定于你对系统数据安全性的要求