mysqltrx

Ⅰ 怎么统计mysql中有多少个死锁

1，查看数据库的隔离级别：
mysql> select @@tx_isolation;
2，去查看先当前库的线程情况：
mysql> show processlist;
没有看到正在执行的慢SQL记录线程，再去查看innodb的事务表INNODB_TRX，看下里面是否有正在锁定的事务线程，看看ID是否在show full processlist里面的sleep线程中，如果是，就证明这个sleep的线程事务一直没有commit或者rollback而是卡住了，我们需要手动kill掉。
mysql> SELECT * FROM information_schema.INNODB_TRX;
如果有记录,则找到trx_mysql_thread_id这个字段对应的id, 将其kill掉。假如id=100
mysql->kill 100
SELECT CONCAT_WS('','kill',' ',t.trx_mysql_thread_id,';')a FROM information_schema.INNODB_TRX t;
4，总结分析
表数据量也不大，按照普通的情况来说，简单的update应该不会造成阻塞的，mysql都是autocommit，不会出现update卡住的情况，去查看下autocommit的值。
mysql> select @@autocommit;
1表示自动提交。0表示不自动提交。
如果你发现自己的数据库autocommit=0，将它改正吧。
解除死锁的两种方法：
（1）终止（或撤销）进程。终止（或撤销）系统中的一个或多个死锁进程，直至打破循环环路，使系统从死锁状态中解除出来。
（2）抢占资源。从一个或多个进程中抢占足够数量的资源，分配给死锁进程，以打破死锁状态。

Ⅱ mysql数据库锁表如何解锁

当前运行的所有事务
select * from information_schema.innodb_trx
当前出现的锁
select * from information_schema.innodb_locks
锁等待的对应关系
select * from information_schema.innodb_lock_waits
通过找到线程id号，进行kill

通过 select * from information_schema.innodb_trx 查询 trx_mysql_thread_id然后执行 kill 线程ID

Ⅲ 怎么看mysql有没阻塞

通过下面的查询，来查询当前数据库，有哪些事务，都锁定哪些资源。

SELECT
	trx_idAS`事务ID`,
	trx_stateAS`事务状态`,
	trx_requested_lock_idAS`事务需要等待的资源`,
	trx_wait_started	AS`事务开始等待时间`,
	trx_tables_in_useAS`事务使用表`,
	trx_tables_lockedAS`事务拥有锁`,
	trx_rows_lockedAS`事务锁定行`,
	trx_rows_modifiedAS`事务更改行`
FROM
	information_schema.innodb_trx;

SELECT
	lock_id			AS	`锁ID`,
	lock_trx_id	AS	`拥有锁的事务ID`,
	lock_mode		AS	`锁模式	`,
	lock_type		AS	`锁类型`,
	lock_table		AS	`被锁的表`,
	lock_index		AS	`被锁的索引`,
	lock_space		AS	`被锁的表空间号`,
	lock_page		AS	`被锁的页号`,
	lock_rec		AS	`被锁的记录号`,
	lock_data		AS	`被锁的数据`
FROM
	information_schema.innodb_locks;

SELECT
requesting_trx_idAS`请求锁的事务ID`,
requested_lock_idAS`请求锁的锁ID`,
blocking_trx_idAS`当前拥有锁的事务ID`,
blocking_lock_idAS`当前拥有锁的锁ID`
FROM
innodb_lock_waits;

Ⅳ 如何 查找 mysql 中如何 kill 引起死锁的线程id

如果遇到死锁了，怎么解决呢?找到原始的锁ID，然后KILL掉一直持有的那个线程就可以了， 但是众多线程，可怎么找到引起死锁的线程ID呢? MySQL 发展到现在，已经非常强大了，这个问题很好解决。 直接从数据字典连查找。
我们来演示下。
线程A，我们用来锁定某些记录，假设这个线程一直没提交，或者忘掉提交了。 那么就一直存在，但是数据里面显示的只是SLEEP状态。
mysql> set @@autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| demo_test |
| t3 |
+----------------+
2 rows in set (0.00 sec)

mysql> select * from t3;
+----+--------+--------+------------+----+----+----+
| id | fname | lname | birthday | c1 | c2 | c3 |
+----+--------+--------+------------+----+----+----+
| 19 | lily19 | lucy19 | 2013-04-18 | 19 | 0 | 0 |
| 20 | lily20 | lucy20 | 2013-03-13 | 20 | 0 | 0 |
+----+--------+--------+------------+----+----+----+
2 rows in set (0.00 sec)

mysql> update t3 set birthday = '2022-02-23' where id = 19;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select connection_id();
+-----------------+
| connection_id() |
+-----------------+
| 16 |
+-----------------+
1 row in set (0.00 sec)

mysql>
线程B， 我们用来进行普通的更新，但是遇到问题了，此时不知道是哪个线程把这行记录给锁定了?
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
| 1 |
+--------------+
1 row in set (0.00 sec)

mysql> update t3 set birthday='2018-01-03' where id = 19;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> select connection_id();
+-----------------+
| connection_id() |
+-----------------+
| 17 |
+-----------------+
1 row in set (0.00 sec)

mysql> show processlist;
+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+------+---------+------+-------+------------------+
| 10 | root | localhost | NULL | Sleep | 1540 | | NULL |
| 11 | root | localhost | NULL | Sleep | 722 | | NULL |
| 16 | root | localhost | test | Sleep | 424 | | NULL |
| 17 | root | localhost | test | Query | 0 | init | show processlist |
| 18 | root | localhost | NULL | Sleep | 5 | | NULL |
+----+------+-----------+------+---------+------+-------+------------------+
5 rows in set (0.00 sec)

mysql> show engine innodb status\G

------------
TRANSACTIONS
------------
Trx id counter 189327
Purge done for trx's n:o < 189323 undo n:o < 0 state: running but idle
History list length 343
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 11, OS thread handle 0x7f70a0c98700, query id 994 localhost root init
show engine innodb status
---TRANSACTION 189326, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 17, OS thread handle 0x7f70a0bd5700, query id 993 localhost root updating
update t3 set birthday='2018-01-03' where id = 19
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 529 page no 3 n bits 72 index `PRIMARY` of table `test`.`t3` trx id 189326 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
0: len 2; hex 3139; asc 19;;
1: len 6; hex 00000002e38c; asc ;;
2: len 7; hex 7e00000d2827c9; asc ~ (' ;;
3: len 6; hex 6c696c793139; asc lily19;;
4: len 6; hex 6c7563793139; asc lucy19;;
5: len 3; hex 8fcc57; asc W;;
6: len 4; hex 80000013; asc ;;
7: len 4; hex 80000000; asc ;;
8: len 4; hex 80000000; asc ;;

------------------
---TRANSACTION 189324, ACTIVE 641 sec
2 lock struct(s), heap size 376, 3 row lock(s), undo log entries 1
MySQL thread id 16, OS thread handle 0x7f70a0b94700, query id 985 localhost root cleaning up
Trx read view will not see trx with id >= 189325, sees < 189325
上面的信息很繁多，也看不清楚到底哪里是哪里。
不过现在，我们只要从数据字典里面拿出来这部分信息就OK了。
mysql> SELECT * FROM information_schema.INNODB_TRX\G
*************************** 1. row ***************************
trx_id: 189324
trx_state: RUNNING
trx_started: 2013-04-18 17:48:14
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 16
trx_query: NULL
trx_operation_state: NULL
trx_tables_in_use: 0
trx_tables_locked: 0
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 3
trx_rows_modified: 1
trx_concurrency_tickets: 0
trx_isolation_level: REPEATABLE READ
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
trx_is_read_only: 0
trx_autocommit_non_locking: 0
1 row in set (0.01 sec)

mysql>
原来是线程16忘掉COMMIT了。

Ⅳ 怎么判断mysql是否是半同步复制

在谈这个特性之前，我们先来看看mysql的复制架构衍生史。 MySQL的复制分为三种： 第一种，即普通的replication。 搭建简单，使用非常广泛，从mysql诞生之初，就产生了这种架构，性能非常好，可谓非常成熟。 但是这种架构数据是异步的，所以有丢失数据库的风险。 第二种，即mysql cluster。 搭建也简单，本身也比较稳定，是mysql里面对数据保护最最靠谱的架构，也是唯一一个数据完全同步的架构，绝对的零丢失。不过性能就差远些了。 第三种，即semi-sync replication，半同步，性能，功能都介于以上两者之间。从mysql5.5开始诞生，目的是为了折中上述两种架构的性能以及优缺点。“我们今天谈论第三种架构

我们知道，普通的replication，也即mysql的异步复制，依靠mysql二进制日志也即binary log进行数据复制。比如两台机器，一台主机也即master，另外一台是从机，也即slave。

1. 正常的复制为：事务一（t1）写入binlog buffer；mper 线程通知slave有新的事务t1；binlog buffer 进行checkpoint；slave的io线程接收到t1并写入到自己的的relay log；slave的sql线程写入到本地数据库。 这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。 2. 异常的复制为：事务一（t1）写入binlog buffer；mper 线程通知slave有新的事务t1；binlog buffer 进行checkpoint；slave因为网络不稳定，一直没有收到t1；master 挂掉，slave提升为新的master，t1丢失。

3. 很大的问题是：主机和从机事务更新的不同步，就算是没有网络或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。

为了弥补以上几种场景的不足，mysql从5.5开始推出了半同步。

即在master的mper线程通知slave后，增加了一个ack，即是否成功收到t1的标志码。也就是mper线程除了发送t1到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复。

我们可以看到半同步带来的新问题： 1. 如果异常发生，会降级为普通的复制。 那么从机出现数据不一致的几率会减少，并不是完全消失。 2. 主机mper线程承担的工作变多了，这样显然会降低整个数据库的性能。 3. 在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 没有收到事务，也就是还没有写入到relay log 之前，网络出现异常或者不稳定，此时刚好master挂了，系统切换到从机，两边的数据就会出现不一致。 在此情况下，slave会少一个事务的数据。

随着MySQL 5.7版本的发布，半同步复制技术升级为全新的Loss-less Semi-Synchronous Replication架构，其成熟度、数据一致性与执行效率得到显著的提升。

MySQL 5.7对数据复制效率进行了改进1 主从一致性加强支持在事务commit前等待ACK

新版本的semi sync 增加了rpl_semi_sync_master_wait_point参数 来控制半同步模式下 主库在返回给会话事务成功之前提交事务的方式。

该参数有两个值：

• AFTER_COMMIT（5.6默认值）

master将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，同时主库提交事务。master等待slave 反馈收到relay log，只有收到ACK后master才将commit OK结果反馈给客户端。

• AFTER_SYNC（5.7默认值，但5.6中无此模式）

master 将每个事务写入binlog , 传递到slave 刷新到磁盘(relay log)。master等待slave 反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。

因此5.7引入了after_sync模式，带来的主要收益是解决after_commit导致的master crash主从间数据不一致问题，因此在引入after_sync模式后，所有提交的数据已经都被复制，故障切换时数据一致性将得到提升。

• 2 性能提升支持发送binlog和接受ack的异步化

旧版本的semi sync 受限于mp thread ，原因是mp thread 承担了两份不同且又十分频繁的任务：传送binlog 给slave ，还需要等待slave反馈信息，而且这两个任务是串行的，mp thread 必须等待 slave 返回之后才会传送下一个 events 事务。mp thread 已然成为整个半同步提高性能的瓶颈。在高并发业务场景下，这样的机制会影响数据库整体的TPS .

• 图：Without ACK receiving thread

为了解决上述问题，在5.7版本的semi sync 框架中，独立出一个 ack collector thread ，专门用于接收slave 的反馈信息。这样master 上有两个线程独立工作，可以同时发送binlog 到slave ，和接收slave的反馈。

• 图：With ACK receiving thread3 性能提升控制主库接收slave 写事务成功反馈数量

MySQL 5.7新增了rpl_semi_sync_master_wait_slave_count参数，可以用来控制主库接受多少个slave写事务成功反馈，给高可用架构切换提供了灵活性。

• 如图所示，当count值为2时，master需等待两个slave的ack

4 性能提升

• Binlog 互斥锁改进

旧版本半同步复制在主提交binlog的写会话和mp thread读binlog的操作都会对binlog添加互斥锁，导致binlog文件的读写是串行化的，存在并发度的问题。

• MySQL 5.7对binlog lock进行了以下两方面优化

1.移除了mp thread对binlog的互斥锁

2.加入了安全边际保证binlog的读安全

• 5 性能提升组提交

5.7引入了新的变量slave-parallel-type，其可以配置的值有：

• DATABASE （5.7之前默认值），基于库的并行复制方式；LOGICAL_CLOCK （5.7新增值），基于组提交的并行复制方式；

MySQL 5.6版本也支持所谓的并行复制，但是其并行只是基于DATABASE的，也就是基于库的。如果用户的MySQL数据库实例中存在多个DATABASE ，对于从机复制的速度的确可以有比较大的帮助，如果用户实例仅有一个库，那么就无法实现并行回放，甚至性能会比原来的单线程更差。

MySQL5.7中增加了一种新的并行模式：为同时进入COMMIT阶段的事务分配相同的序列号，这些拥有相同序列号的事务在备库是可以并发执行的。

MySQL 5.7真正实现的并行复制，这其中最为主要的原因就是slave服务器的回放与主机是一致的即master服务器上是怎么并行执行的slave上就怎样进行并行回放。不再有库的并行复制限制，对于二进制日志格式也无特殊的要求（基于库的并行复制也没有要求）。

因此下面的序列中可以并发的序列为（其中前面一个数字为last_committed ，后面一个数字为sequence_number ）：

• trx1 1…..2trx2 1………….3trx3 1…………………….4trx4 2……………………….5trx5 3…………………………..6trx6 3………………………………7trx7 6………………………………..8

备库并行规则：当分发一个事务时，其last_committed 序列号比当前正在执行的事务的最小sequence_number要小时，则允许执行。

• 因此，

a)trx1执行，last_commit<2的可并发，trx2, trx3可继续分发执行

b)trx1执行完成后，last_commit < 3的可以执行， trx4可分发

c)trx2执行完成后，last_commit< 4的可以执行， trx5, trx6可分发

d)trx3、trx4、trx5完成后，last_commit < 7的可以执行，trx7可分发

• 综上所述

我们认为MySQL 5.7版对Loss-Less半同步复制技术的优化，使得其成熟度和执行效率都得到了质的提高。我们建议在使用MySQL 5.7作为生产环境的部署时，可以使用半同步技术作为高可用与读写分离方案的数据复制方案。

Ⅵ mysql半同步复制适合哪些业务场景

说实话 这个问题 很难回答

同步复制，牺牲很多性能。slave 需要等待master处理结束 不阻塞情况。
异步性能好，但是不等待master处理结束，不保证数据完整
半同步介于两者之间。数据可靠性很好，但是略微牺牲性能。

业务场景。。。。 看你数据库服务器多屌咯。都能广泛运用于各种场景。

如果硬要说的话，半同步复制，个人认为不适合大流量高失败请求的网络游戏数据储存。更适合流量一般的 非持续性的数据更替吧。比如，网商，网络订单？

PS:绝不是安利。以前我自己搭建数据库服务器。后来维护麻烦，直接用了阿x云的rds。再无烦恼。用少量金钱解决的大问题。。。。 何必自己辛苦

Ⅶ 关于MYSQL配置文件中innodb_flush_log_at_trx_commit的疑问

这是关系到事务日志的一个参数,0或者2,只是定时的刷新到log buffer,

事务日志..不知道你明白不..就是你说的也影响到更新数据的操作.但对正常的数据读写不会有影响...简单来说..就是你事务提交了..,你就可以查到commit后的数据. 但这时并不一定写入到磁盘了..可能在缓存..
这个参数也就是在commit的时候会有差异,如果为1,就每个事务提交就会要刷新到磁盘后才算提交完成....这种情况是保证了事务的acid,但性能会有很大的影响...
如果为0或者2,只要commit了就算完成了...0和2的区别在于
0：当mysql挂了之后，可能会损失前一秒的事务信息
2：当mysql挂了之后，如果系统文件系统没挂，不会有事务丢失

Ⅷ MySQL 5.7中新增sys schema有什么好处

性能优化利器:剖析MySQL 5.7新特征 sys schema

导读：很多团队在评估合适的时机切换到 MySQL 5.7，本文是在高可用架构群的分享，介绍 MySQL 5.7 新的性能分析利器。

李春，现任科技 MySQL 负责人，高级 MySQL 数据库专家，从事 MySQL 开发和运维工作 8 年。在担任 MySQL 数据库 leader 期间，主要负责应用架构的优化和部署，实现了阿里巴巴 3 亿 产品 从 Oracle 小型机到 64 台 MySQL 的平滑迁移。专注于研究 MySQL 复制、高可用、分布式和运维自动化相关领域。在大规模、分布式 MySQL 集群管理、调优、快速定位和解决问题方面有丰富经验。管理超过 1400 台 MySQL 服务器，近 3000 个实例。完成 MySQL 自动装机系统、MySQL 标准化文档和操作手册、MySQL 自动规范性检查系统、MySQL 自动信息采集系统等标准化文档和自动化运维工具。

sys schema 由来

Performance schema 引入

Oracle 早就有了 v$ 等一系列方便诊断数据库性能的工具，MySQL DBA 只有羡慕嫉妒恨的份，但是 5.7 引入的 sys schema 缓解了这个问题，让我们可以通过 sys schema 一窥 MySQL 性能损耗，诊断 MySQL 的各种问题。

说到诊断 MySQL 性能问题，不得不提在 MySQL 5.5 引入的 performance_schema，最开始引入时，MySQL 的 performance_schema 性能消耗巨大，随着版本的更新和代码优化，5.7 的 performance_schema 对 MySQL 服务器额外的消耗越来越少，我们可以放心的打开 performance_shema 来收集 MySQL 数据库的性能损耗。Tarique Saleem 同学测试了一下 sys schema 对 CPU 和 IO的额外消耗，基本在 1% - 3% 之间，有兴趣的同学可以参考他的这篇 blog：

（CPU Bound, Sysbench Read Only Mode）

performance_schema 不仅由于他的性能消耗大著名，还由于其复杂难用而臭名昭著。5.7 上的 performance schema 已经有 87 张表了，每个表都是各种统计信息的罗列；另外，他的这些表和 information_schema 中的部分表也缠夹不清，让大家用得很不习惯。

sys schema VS performance schema VS information schema

现在 MySQL 在 5.7 又新增了sys schema，它和 performance_schema 和 information schema 到底是什么关系？

Information_schema 定位基本是 MySQL 元数据信息，比如：TABLES 记录了 MySQL 有哪些表，COLUMNS 记录了各个表有哪些列 。

performance_schema 记录了 MySQL 实时底层性能消耗情况，比如：events_waits_current 记录了 MySQL 各个线程当前在等待的 event。

虽然他们之间的这个定位区别并没有那么明显：比如，Information_schema 的 innodb_locks 就记录了 innodb 当前锁的信息，它并不是 MySQL 的元数据信息。sys schema 最开始是 MarkLeith 同学为了方便读取和诊断 MySQL 性能引入到 MySQL 的。所以 sys schema 定位应该是最清晰的：它包含一系列对象，这些对象能够辅助 DBA 和开发人员了解 performance schema 和 information_schema 采集的数据。

sys schema 包含了什么？

sys schema 包含一些对象，这些对象主要用于调优和故障分析。包括：

将 performance schema 和 information schema 中的数据用更容易理解的方式来总结归纳出来的“视图”。

提供 performance schema 和 information schema 配置或者生成分析报告类似操作的“存储过程”

sys schema 本身不采集和存储什么信息，它只是为程序或者用户提供一个更加方便的诊断系统性能和排除故障的“接口”。也就是说，查询 performance schema 和 information schema 配置和提供格式化服务的“存储函数”。

避免用户在 information schema 和 performance schema 中写各种复杂的查询来获得到底谁锁了谁，每个线程消耗的内存是多少 ( 视图 memory_by_thread_by_current_bytes )，每个 SQL 执行了多少次，大致的执行时间是多少（ 视图 statements_with_runtimes_in_95th_percentile ）等，这些 sys schema 都直接帮你写好，你只需要直接查询就好了。

编写了一些现成的存储过程，方便你：直接使用 diagnostics() 存储过程创建用于诊断当前服务器状态的报告；使用 ps_trace_thread() 存储过程创建对应线程的图形化（ .dot类型 ）性能数据。

编写了一些现成的存储函数，方便你：直接使用 ps_thread_account() 存储函数获得发起这个线程的用户，使用 ps_thread_trx_info() 来获得某线程当前事务或者历史执行过的语句（ JSON 格式返回 ）。

当然，你也可以在 sys schema 下增加自己用于诊断 MySQL 性能的“视图”、“存储过程”和“存储函数”。

sys schema 举例

怎么利用 sys schema 来定位问题和诊断数据库性能？这里简单举一个 innodb 行锁的例子来说明。

模拟行锁

拿一个实际的场景来说 sys schema 能够辅助我们分析当前数据库上哪个 session 被锁住了，并且提供“清理”锁的语句。我们模拟一个表的某一行被锁住的情况，假设表创建语句如下：

CREATE TABLE `test2` (

`id` int(11) NOT NULL,

`name` varchar(16) DEFAULT NULL,

`age` int(11) DEFAULT NULL,

`sex` int(11) DEFAULT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1

有一条数据如下：

mysql > select * from test2;

+----+---------+------+------+

| id | name | age | sex |

+----+---------+------+------+

| 2 | pickup1 | 1 | 1 |

+----+---------+------+------+

我们分别在 session 1 和 session 2 上同时操作这条数据，这样的话必然对同一行记录相互有锁死的情况，然后我们通过 session 3 来查看 sys schema 里面的 innodb_lock_waits，确定到底是谁锁了谁，怎么解锁？操作步骤如下：

通过 sys.innodb_lock_waits 查看 innodb 锁表情况

对应的在 session 3上查看到的记录：

mysql > select * from sys.innodb_lock_waitsG

*************************** 1. row ***************************

wait_started: 2016-05-04 01:04:38

wait_age: 00:00:02

wait_age_secs: 2

locked_table: `test`.`test2`

locked_index: PRIMARY

locked_type: RECORD

waiting_trx_id: 5382

waiting_trx_started: 2016-05-04 00:24:21

waiting_trx_age: 00:40:19

waiting_trx_rows_locked: 4

waiting_trx_rows_modified: 0

waiting_pid: 3

waiting_query: update test2 set name='pickup3' where id=2

waiting_lock_id: 5382:31:3:3

waiting_lock_mode: X

blocking_trx_id: 5381

blocking_pid: 2

blocking_query: NULL

blocking_lock_id: 5381:31:3:3

blocking_lock_mode: X

blocking_trx_started: 2016-05-04 00:23:49

blocking_trx_age: 00:40:51

blocking_trx_rows_locked: 1

blocking_trx_rows_modified: 1

sql_kill_blocking_query: KILL QUERY 2

sql_kill_blocking_connection: KILL 2

这里我们可以看到 3 号线程（ waiting_pid: 3 ）在等待 2 号线程（ blocking_pid: 2 ）的 X 锁（ blocking_lock_mode: X ），如果需要解锁，需要杀掉 2 号线程（ sql_kill_blocking_connection: KILL 2 ）。

innodb_lock_waits 本质

其实 sys schema 的 innodb_lock_waits 只是 information schema 的视图而已。

CREATE ALGORITHM = TEMPTABLE DEFINER = `mysql.sys`@`localhost` SQL SECURITY INVOKER VIEW `innodb_lock_waits` AS

SELECT

`r`.`trx_wait_started` AS `wait_started`,

TIMEDIFF(NOW(),

`r`.`trx_wait_started`) AS `wait_age`,

TIMESTAMPDIFF(

SECOND,

`r`.`trx_wait_started`,

NOW()) AS `wait_age_secs`,

`rl`.`lock_table` AS `locked_table`,

`rl`.`lock_index` AS `locked_index`,

`rl`.`lock_type` AS `locked_type`,

`r`.`trx_id` AS `waiting_trx_id`,

`r`.`trx_started` AS `waiting_trx_started`,

TIMEDIFF(NOW(),

`r`.`trx_started`) AS `waiting_trx_age`,

`r`.`trx_rows_locked` AS `waiting_trx_rows_locked`,

`r`.`trx_rows_modified` AS `waiting_trx_rows_modified`,

`r`.`trx_mysql_thread_id` AS `waiting_pid`,

`sys`.`format_statement`(`r`.`trx_query`) AS `waiting_query`,

`rl`.`lock_id` AS `waiting_lock_id`,

`rl`.`lock_mode` AS `waiting_lock_mode`,

`b`.`trx_id` AS `blocking_trx_id`,

`b`.`trx_mysql_thread_id` AS `blocking_pid`,

`sys`.`format_statement`(`b`.`trx_query`) AS `blocking_query`,

`bl`.`lock_id` AS `blocking_lock_id`,

`bl`.`lock_mode` AS `blocking_lock_mode`,

`b`.`trx_started` AS `blocking_trx_started`,

TIMEDIFF(NOW(),

`b`.`trx_started`) AS `blocking_trx_age`,

`b`.`trx_rows_locked` AS `blocking_trx_rows_locked`,

`b`.`trx_rows_modified` AS `blocking_trx_rows_modified`,

CONCAT(

'KILL QUERY ',

`b`.`trx_mysql_thread_id`

) AS `sql_kill_blocking_query`,

CONCAT('KILL ',

`b`.`trx_mysql_thread_id`) AS `sql_kill_blocking_connection`

FROM

(

(

(

(

`information_schema`.`innodb_lock_waits` `w`

JOIN

`information_schema`.`innodb_trx` `b` ON((`b`.`trx_id` = `w`.`blocking_trx_id`))

)

JOIN

`information_schema`.`innodb_trx` `r` ON(

(`r`.`trx_id` = `w`.`requesting_trx_id`)

)

)

JOIN

`information_schema`.`innodb_locks` `bl` ON(

(

`bl`.`lock_id` = `w`.`blocking_lock_id`

)

)

)

JOIN

`information_schema`.`innodb_locks` `rl` ON(

(

`rl`.`lock_id` = `w`.`requested_lock_id`

)

)

)

ORDER BY

`r`.`trx_wait_started`

innodb_lock_waits和x$innodb_lock_waits区别

有心的同学可能会注意到，sys schema 里面有 innodb_lock_waits 和 x$innodb_lock_waits。其实 sys schema 的这些视图大部分都成对出现，其中一个的名字除了 x$ 前缀以外跟另外一个是一模一样的。例如，host_summmary_by_file_io 视图分析汇总的是根据主机汇总的文件 IO 情况，并将延迟从皮秒（ picoseconds ）转换成更加易读值（ 带单位 ）显示出来：

mysql> SELECT * FROM host_summary_by_file_io;

+------------+-------+------------+

| host | ios | io_latency |

+------------+-------+------------+

| localhost | 67570 | 5.38 s |

| background | 3468 | 4.18 s |

+------------+-------+------------+

而 x$host_summary_by_file_io 视图分析汇总的是同样的数据，但是显示的是未格式化过的皮秒（ picosecond ）延迟值

mysql> SELECT * FROM x$host_summary_by_file_io;

+------------+-------+---------------+

| host | ios | io_latency |

+------------+-------+---------------+

| localhost | 67574 | 5380678125144 |

| background | 3474 | 4758696829416 |

+------------+-------+---------------+

没有 x$ 前缀的视图是为了提供更加友好，对人更加易读的输出格式。带 x$ 前缀的视图显示了数据原始格式，它方便其他工具基于这些数据进行自己的处理。需要了解非 x$ 和 x$ 视图的不同点的进一步信息。

Q&A

提问：sys schema 只是在 performance_schema 和 information_schema 之上创建视图和存储过程？

李春：对，sys schema 主要针对的其实是 iperformance schema，有部分 information schema 的表也会整理到 sys schema 中统一展现。

提问：运行 KILL 2 杀掉 2 线程？blocking_lock_mode: X 的 X 什么意思？

李春：blocking_lock_mode 的 X 是指 X 锁，exclusive 锁，排它锁，跟它对应的是 S 锁，共享锁。kill 2 是杀掉 2 号线程，这样可以将锁释放，让被锁的这个线程正常执行下去。

提问：可以放心的打开 performance_schema，为何不使用 performance_schema 再造一个 sys schema？

李春：performance schema 是 MySQL 采集数据库性能的存储空间。sys schema 其实只是对 performance schema 多个表 join 和整合。两者的定位有所不同，如果直接放在 performance schema 中，分不清哪些是基表，哪些是视图，会比较混淆。

提问：pt-query-digest 这些工具的有开始使用 sys schema 吗？

李春：没有，pt-query-digest 主要用于分析慢查和 tcpmp 的结果，跟 sys schema 的定位有部分重叠的地方，sys schema 会分析得更细，更内核，更偏底层一些，pt-query-digest 主要还是从慢查和 tcpmp 中抽取 SQL 来格式化展现。

提问：阿里这么多数据库实例，使用什么运维工具？分布式事务又是怎么解决的呢？

李春：阿里内部有非常多的运维工具，dbfree，idb 等，用于数据库资源池管理，数据库脱敏，开发测试库同步，数据库订正，表结构变更等。分布式事务主要通过业务上的修改去屏蔽掉，比如：电影买票并不是你选了座位和付款就必须在一个事务里面，抢票，选座，付款分别是自己的子事务，系统耦合性比较弱，相互通知解决问题。

提问：Oracle 有 v$，MySQL 有 x$ ？两个 $ 是完成相似功能的吗？

李春：MySQL 的 x$ 可以说是仿照 Oracle 的 v$ 来做的，但是目前离 Oracle 的那么强大的数据库诊断功能还有一些距离。

提问：数据库脱敏能否简单介绍下实现方式？

李春：开发测试人员无法访问线上数据库，需要通过一个专门的 idb 来访问，而 idb 系统每个字段都有密级定义，满足权限的才能被访问；这个系统页控制了用户是否可以访问某个表，可以访问数据表的行数，只有主管同意了，用户才能访问某个表的数据，并且加密数据是以*显示的。

Ⅸ MYSQL安装完以后如何设置

key_buffer_size - 这对MyISAM表来说非常重要。如果只是使用MyISAM表，可以把它设置为可用内存的 30-40%。合理的值取决于索引大小、数据量以及负载 -- 记住，MyISAM表会使用操作系统的缓存来缓存数据，因此需要留出部分内存给它们，很多情况下数据比索引大多了。尽管如此，需要总是检查是否所有的 key_buffer 都被利用了 -- .MYI 文件只有 1GB，而 key_buffer 却设置为 4GB 的情况是非常少的。这么做太浪费了。如果你很少使用MyISAM表，那么也保留低于 16-32MB 的key_buffer_size 以适应给予磁盘的临时表索引所需。

innodb_buffer_pool_size - 这对Innodb表来说非常重要。Innodb相比MyISAM表对缓冲更为敏感。MyISAM可以在默认的 key_buffer_size 设置下运行的可以，然而Innodb在默认的innodb_buffer_pool_size 设置下却跟蜗牛似的。由于Innodb把数据和索引都缓存起来，无需留给操作系统太多的内存，因此如果只需要用Innodb的话则可以设置它高达 70-80% 的可用内存。一些应用于 key_buffer 的规则有 -- 如果你的数据量不大，并且不会暴增，那么无需把innodb_buffer_pool_size 设置的太大了。

innodb_additional_pool_size - 这个选项对性能影响并不太多，至少在有差不多足够内存可分配的操作系统上是这样。不过如果你仍然想设置为 20MB(或者更大)，因此就需要看一下Innodb其他需要分配的内存有多少。

innodb_log_file_size 在高写入负载尤其是大数据集的情况下很重要。这个值越大则性能相对越高，但是要注意到可能会增加恢复时间。我经常设置为64-512MB，根据服务器大小而异。

innodb_log_buffer_size 默认的设置在中等强度写入负载以及较短事务的情况下，服务器性能还可以。如果存在更新操作峰值或者负载较大，就应该考虑加大它的值了。如果它的值设置太高了，可能会浪费内存 -- 它每秒都会刷新一次，因此无需设置超过1秒所需的内存空间。通常8-16MB就足够了。越小的系统它的值越小。

innodb_flush_logs_at_trx_commit 是否为Innodb比MyISAM慢1000倍而头大?看来也许你忘了修改这个参数了。默认值是 1，这意味着每次提交的更新事务(或者每个事务之外的语句)都会刷新到磁盘中，而这相当耗费资源，尤其是没有电池备用缓存时。很多应用程序，尤其是从 MyISAM转变过来的那些，把它的值设置为 2 就可以了，也就是不把日志刷新到磁盘上，而只刷新到操作系统的缓存上。日志仍然会每秒刷新到磁盘中去，因此通常不会丢失每秒1-2次更新的消耗。如果设置为0就快很多了，不过也相对不安全了 -- MySQL服务器崩溃时就会丢失一些事务。设置为2指挥丢失刷新到操作系统缓存的那部分事务。

table_cache -- 打开一个表的开销可能很大。例如MyISAM把MYI文件头标志该表正在使用中。你肯定不希望这种操作太频繁，所以通常要加大缓存数量，使得足以最大限度地缓存打开的表。它需要用到操作系统的资源以及内存，对当前的硬件配置来说当然不是什么问题了。如果你有200多个表的话，那么设置为 1024 也许比较合适(每个线程都需要打开表)，如果连接数比较大那么就加大它的值。我曾经见过设置为100,000的情况。

thread_cache -- 线程的创建和销毁的开销可能很大，因为每个线程的连接/断开都需要。我通常至少设置为 16。如果应用程序中有大量的跳跃并发连接并且 Threads_Created 的值也比较大，那么我就会加大它的值。它的目的是在通常的操作中无需创建新线程。

query cache -- 如果你的应用程序有大量读，而且没有应用程序级别的缓存，那么这很有用。不要把它设置太大了，因为想要维护它也需要不少开销，这会导致MySQL变慢。通常设置为 32-512Mb。设置完之后最好是跟踪一段时间，查看是否运行良好。在一定的负载压力下，如果缓存命中率太低了，就启用它。

注意：就像你看到的上面这些全局表量，它们都是依据硬件配置以及不同的存储引擎而不同，但是会话变量通常是根据不同的负载来设定的。如果你只有一些简单的查询，那么就无需增加 sort_buffer_size 的值了，尽管你有 64GB 的内存。搞不好也许会降低性能。

我通常在分析系统负载后才来设置会话变量。

MySQL的发行版已经包含了各种 my.cnf 范例文件了，可以作为配置模板使用。

Ⅹ MySQL报错Lock wait timeout exceeded怎么办

临时解决办法：

执行MySQL命令:show full processlist;

然后找出插入语句的系统id

执行mysql命令:kill id

在网络上找了想相关资料,这里摘录如下:

首先,查看数据库的进程信息:

show full processlist;

/*结果略,主要看id列的值*/

再查看事物表:

SELECT * FROM information_schema.INNODB_TRX\G;
/*结果略,注意结果中的trx_mysql_thread_id部分的值*/

查找对应的id,然后kill id的值即可;

mysql默认是自动提交的,可以用以下命令查看:

select @@autocommit;
值为1就是自动提交,如果你的不是1,但你又想要自动提交,那么设置的命令是:

set global autocommit=1;

表数据量也不大，按照普通的情况来说，简单的update应该不会造成阻塞的，mysql都是autocommit，不会出现update卡住的情况，去查看下autocommit的值。
mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
| 0 |
+--------------+
1 row in set (0.00 sec)

mysql>

看到亮闪闪的0，这个设置导致原来的update语句如果没有commit的话，你再重新执行update语句，就会等待锁定，当等待时间过长的时候，就会报ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction的错误。
所以赶紧commit刚才执行的update语句，之后 set global autocommit=1;

2、最终解决方案：

出现该问题大多数是因为出现死锁或者connection/session没有关闭造成的，去检查执行该sql的语句，检查是否有finally{}中关闭连接。