- 浏览: 514575 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (563)
- 工作经验 (12)
- 数据库 (13)
- Servlet (10)
- Struts2 (1)
- Spring (25)
- Eclipse (5)
- Hibernate (5)
- Eclips (8)
- HTTP (7)
- J2EE (21)
- EHcache (1)
- HTML (11)
- 工具插件使用 (20)
- JPA (2)
- 杂谈 (17)
- 数据结构与算法 (3)
- Cloud Foundry (1)
- 安全 (10)
- J2SE (57)
- SQL (9)
- DB2 (6)
- 操作系统 (2)
- 设计模式 (1)
- 版本代码管理工具 (13)
- 面试 (10)
- 代码规范 (3)
- Tomcat (12)
- Ajax (5)
- 异常总结 (11)
- REST (2)
- 云 (2)
- RMI (3)
- SOA (1)
- Oracle (12)
- Javascript (20)
- jquery (7)
- JSP自定义标签 (2)
- 电脑知识 (5)
- 浏览器 (3)
- 正则表达式 (3)
- 建站解决问题 (38)
- 数据库设计 (3)
- git (16)
- log4j (1)
- 每天100行代码 (1)
- socket (0)
- java设计模式 耿祥义著 (0)
- Maven (14)
- ibatis (7)
- bug整理 (2)
- 邮件服务器 (8)
- Linux (32)
- TCP/IP协议 (5)
- java多线程并发 (7)
- IO (1)
- 网页小工具 (2)
- Flash (2)
- 爬虫 (1)
- CSS (6)
- JSON (1)
- 触发器 (1)
- java并发 (12)
- ajaxfileupload (1)
- js验证 (1)
- discuz (2)
- Mysql (14)
- jvm (2)
- MyBatis (10)
- POI (1)
- 金融 (1)
- VMWare (0)
- Redis (4)
- 性能测试 (2)
- PostgreSQL (1)
- 分布式 (2)
- Easy UI (1)
- C (1)
- 加密 (6)
- Node.js (1)
- 事务 (2)
- zookeeper (3)
- Spring MVC (2)
- 动态代理 (3)
- 日志 (2)
- 微信公众号 (2)
- IDEA (1)
- 保存他人遇到的问题 (1)
- webservice (11)
- memcached (3)
- nginx (6)
- 抓包 (1)
- java规范 (1)
- dubbo (3)
- xwiki (1)
- quartz (2)
- 数字证书 (1)
- spi (1)
- 学习编程 (6)
- dom4j (1)
- 计算机系统知识 (2)
- JAVA系统知识 (1)
- rpcf (1)
- 单元测试 (2)
- php (1)
- 内存泄漏cpu100%outofmemery (5)
- zero_copy (2)
- mac (3)
- hive (3)
- 分享资料整理 (0)
- 计算机网络 (1)
- 编写操作系统 (1)
- springboot (1)
最新评论
-
masuweng:
亦论一次OutOfMemoryError的定位与解错 -
变脸小伙:
引用[color=red][/color]百度推广中运用的技术 ...
Spring 3 mvc中返回pdf,json,xml等不同的view -
Vanillva:
不同之处是什么??
Mybatis中的like查询 -
thrillerzw:
转了。做个有理想的程序员
有理想的程序员必须知道的15件事 -
liujunhui1988:
觉得很有概括力
15 个必须知道的 Java 面试问题(2年工作经验)
源:http://my.oschina.net/jiaoya/blog/92194
http://www.cnblogs.com/freeliver54/archive/2010/09/30/1839042.html
评:
mysql : Lock wait timeout exceeded; try restarting transaction
原因是你使用的InnoDB 表类型的时候,
默认参数:innodb_lock_wait_timeout设置锁等待的时间是50s,
因为有的锁等待超过了这个时间,所以抱错.
你可以把这个时间加长,或者优化存储过程,事务避免过长时间的等待.
my.ini文件:
#innodb_lock_wait_timeout = 50
-》
innodb_lock_wait_timeout = 500
重启mysql服务。
-----------------------------------------
SHOW INNODB STATUS and, probably, SHOW PROCESSLIST can give you
some additional information about what's going on. Use:
show variables like 'tx_isolation';
to find out the transaction isolation level. See:
http://dev.mysql.com/doc/mysql/en/InnoDB_Monitor.html
http://dev.mysql.com/doc/mysql/en/show-processlist.html
-------------查找 持有锁的 线程 -----------------------------------
java.lang.Exception:
### Error updating database. Cause: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
### The error may involve defaultParameterMap
### The error occurred while setting parameters
### Cause: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
; SQL []; Lock wait timeout exceeded; try restarting transaction; nested exception is java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
select * from information_schema.innodb_trx 之后找到了一个一直没有提交的只读事务,
kill 到了对应的线程后ok 了。
==============================================
转载:http://blog.sina.com.cn/s/blog_6bb63c9e0100s7cb.html
MySQL 5.5 -- innodb_lock_wait 锁 等待
记得以前,当出现:ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction,
要解决是一件麻烦的事情 ;
特别是当一个SQL执行完了,但未COMMIT,后面的SQL想要执行就是被锁,超时结束;
DBA光从数据库无法着手找出源头是哪个SQL锁住了;
有时候看看show engine innodb status , 并结合 show full processlist; 能暂时解决问题;但一直不能精确定位;
在5.5中,information_schema 库中增加了三个关于锁的表(MEMORY引擎);
innodb_trx ## 当前运行的所有事务
innodb_locks ## 当前出现的锁
innodb_lock_waits ## 锁等待的对应关系
看到这个就非常激动 ; 这可是解决了一个大麻烦,先来看一下表结构
root@127.0.0.1 : information_schema 13:28:38> desc innodb_locks;
+-------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+
| lock_id | varchar(81) | NO | | | |#锁ID
| lock_trx_id | varchar(18) | NO | | | |#拥有锁的事务ID
| lock_mode | varchar(32) | NO | | | |#锁模式
| lock_type | varchar(32) | NO | | | |#锁类型
| lock_table | varchar(1024) | NO | | | |#被锁的表
| lock_index | varchar(1024) | YES | | NULL | |#被锁的索引
| lock_space | bigint(21) unsigned | YES | | NULL | |#被锁的表空间号
| lock_page | bigint(21) unsigned | YES | | NULL | |#被锁的页号
| lock_rec | bigint(21) unsigned | YES | | NULL | |#被锁的记录号
| lock_data | varchar(8192) | YES | | NULL | |#被锁的数据
+-------------+---------------------+------+-----+---------+-------+
10 rows in set (0.00 sec)
root@127.0.0.1 : information_schema 13:28:56> desc innodb_lock_waits;
+-------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-------------+------+-----+---------+-------+
| requesting_trx_id | varchar(18) | NO | | | |#请求锁的事务ID
| requested_lock_id | varchar(81) | NO | | | |#请求锁的锁ID
| blocking_trx_id | varchar(18) | NO | | | |#当前拥有锁的事务ID
| blocking_lock_id | varchar(81) | NO | | | |#当前拥有锁的锁ID
+-------------------+-------------+------+-----+---------+-------+
4 rows in set (0.00 sec)
root@127.0.0.1 : information_schema 13:29:05> desc innodb_trx ;
+----------------------------+---------------------+------+-----+---------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+---------------------+------+-----+---------------------+-------+
| trx_id | varchar(18) | NO | | | |#事务ID
| trx_state | varchar(13) | NO | | | |#事务状态:
| trx_started | datetime | NO | | 0000-00-00 00:00:00 | |#事务开始时间;
| trx_requested_lock_id | varchar(81) | YES | | NULL | |#innodb_locks.lock_id
| trx_wait_started | datetime | YES | | NULL | |#事务开始等待的时间
| trx_weight | bigint(21) unsigned | NO | | 0 | |#
| trx_mysql_thread_id | bigint(21) unsigned | NO | | 0 | |#事务线程ID
| trx_query | varchar(1024) | YES | | NULL | |#具体SQL语句
| trx_operation_state | varchar(64) | YES | | NULL | |#事务当前操作状态
| trx_tables_in_use | bigint(21) unsigned | NO | | 0 | |#事务中有多少个表被使用
| trx_tables_locked | bigint(21) unsigned | NO | | 0 | |#事务拥有多少个锁
| trx_lock_structs | bigint(21) unsigned | NO | | 0 | |#
| trx_lock_memory_bytes | bigint(21) unsigned | NO | | 0 | |#事务锁住的内存大小(B)
| trx_rows_locked | bigint(21) unsigned | NO | | 0 | |#事务锁住的行数
| trx_rows_modified | bigint(21) unsigned | NO | | 0 | |#事务更改的行数
| trx_concurrency_tickets | bigint(21) unsigned | NO | | 0 | |#事务并发票数
| trx_isolation_level | varchar(16) | NO | | | |#事务隔离级别
| trx_unique_checks | int(1) | NO | | 0 | |#是否唯一性检查
| trx_foreign_key_checks | int(1) | NO | | 0 | |#是否外键检查
| trx_last_foreign_key_error | varchar(256) | YES | | NULL | |#最后的外键错误
| trx_adaptive_hash_latched | int(1) | NO | | 0 | |#
| trx_adaptive_hash_timeout | bigint(21) unsigned | NO | | 0 | |#
+----------------------------+---------------------+------+-----+---------------------+-------+
22 rows in set (0.01 sec)
下面我们来动手看看数据吧:
##建立测试数据:
use test;
create table tx1
(id int primary key ,
c1 varchar(20),
c2 varchar(30))
engine=innodb default charset = utf8 ;
insert into tx1 values
(1,'aaaa','aaaaa2'),
(2,'bbbb','bbbbb2'),
(3,'cccc','ccccc2');
commit;
###产生事务;
### Session1
start transaction;
update tx1 set c1='heyf',c2='heyf' where id =3 ;
## 产生事务,在innodb_trx就有数据 ;
root@127.0.0.1 : information_schema 13:38:21> select * from innodb_trx G
*************************** 1. row ***************************
trx_id: 3669D82
trx_state: RUNNING
trx_started: 2010-12-24 13:38:06
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 2344
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: 1
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
1 row in set (0.00 sec)
### 由于没有产生锁等待,下面两个表没有数据 ;
root@127.0.0.1 : information_schema 13:38:31> select * from innodb_lock_waits G
Empty set (0.00 sec)
root@127.0.0.1 : information_schema 13:38:57> select * from innodb_locks G
Empty set (0.00 sec)
#### 产生锁等待
#### session 2
start transaction;
update tx1 set c1='heyfffff',c2='heyffffff' where id =3 ;
root@127.0.0.1 : information_schema 13:39:01> select * from innodb_trx G
*************************** 1. row ***************************
trx_id: 3669D83 ##第2个事务
trx_state: LOCK WAIT ## 处于等待状态
trx_started: 2010-12-24 13:40:07
trx_requested_lock_id: 3669D83:49:3:4 ##请求的锁ID
trx_wait_started: 2010-12-24 13:40:07
trx_weight: 2
trx_mysql_thread_id: 2346 ##线程 ID
trx_query: update tx1 set c1='heyfffff',c2='heyffffff' where id =3
trx_operation_state: starting index read
trx_tables_in_use: 1 ##需要用到1个表
trx_tables_locked: 1 ##有1个表被锁
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 1
trx_rows_modified: 0
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
*************************** 2. row ***************************
trx_id: 3669D82 ##第1个事务
trx_state: RUNNING
trx_started: 2010-12-24 13:38:06
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 2344
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: 1
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
2 rows in set (0.00 sec)
root@127.0.0.1 : information_schema 13:40:12> select * from innodb_locks G
*************************** 1. row ***************************
lock_id: 3669D83:49:3:4 ## 第2个事务需要的锁
lock_trx_id: 3669D83
lock_mode: X
lock_type: RECORD
lock_table: `test`.`tx1`
lock_index: `PRIMARY`
lock_space: 49
lock_page: 3
lock_rec: 4
lock_data: 3
*************************** 2. row ***************************
lock_id: 3669D82:49:3:4 ## 第1个事务需要的锁
lock_trx_id: 3669D82
lock_mode: X
lock_type: RECORD
lock_table: `test`.`tx1`
lock_index: `PRIMARY`
lock_space: 49
lock_page: 3
lock_rec: 4
lock_data: 3
2 rows in set (0.00 sec)
root@127.0.0.1 : information_schema 13:40:15> select * from innodb_lock_waits G
*************************** 1. row ***************************
requesting_trx_id: 3669D83 ## 请求锁的事务
requested_lock_id: 3669D83:49:3:4 ## 请求锁的锁ID
blocking_trx_id: 3669D82 ## 拥有锁的事务
blocking_lock_id: 3669D82:49:3:4 ## 拥有锁的锁ID
1 row in set (0.00 sec)
http://www.cnblogs.com/freeliver54/archive/2010/09/30/1839042.html
评:
mysql : Lock wait timeout exceeded; try restarting transaction
原因是你使用的InnoDB 表类型的时候,
默认参数:innodb_lock_wait_timeout设置锁等待的时间是50s,
因为有的锁等待超过了这个时间,所以抱错.
你可以把这个时间加长,或者优化存储过程,事务避免过长时间的等待.
my.ini文件:
#innodb_lock_wait_timeout = 50
-》
innodb_lock_wait_timeout = 500
重启mysql服务。
-----------------------------------------
SHOW INNODB STATUS and, probably, SHOW PROCESSLIST can give you
some additional information about what's going on. Use:
show variables like 'tx_isolation';
to find out the transaction isolation level. See:
http://dev.mysql.com/doc/mysql/en/InnoDB_Monitor.html
http://dev.mysql.com/doc/mysql/en/show-processlist.html
-------------查找 持有锁的 线程 -----------------------------------
java.lang.Exception:
### Error updating database. Cause: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
### The error may involve defaultParameterMap
### The error occurred while setting parameters
### Cause: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
; SQL []; Lock wait timeout exceeded; try restarting transaction; nested exception is java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
select * from information_schema.innodb_trx 之后找到了一个一直没有提交的只读事务,
kill 到了对应的线程后ok 了。
==============================================
转载:http://blog.sina.com.cn/s/blog_6bb63c9e0100s7cb.html
MySQL 5.5 -- innodb_lock_wait 锁 等待
记得以前,当出现:ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction,
要解决是一件麻烦的事情 ;
特别是当一个SQL执行完了,但未COMMIT,后面的SQL想要执行就是被锁,超时结束;
DBA光从数据库无法着手找出源头是哪个SQL锁住了;
有时候看看show engine innodb status , 并结合 show full processlist; 能暂时解决问题;但一直不能精确定位;
在5.5中,information_schema 库中增加了三个关于锁的表(MEMORY引擎);
innodb_trx ## 当前运行的所有事务
innodb_locks ## 当前出现的锁
innodb_lock_waits ## 锁等待的对应关系
看到这个就非常激动 ; 这可是解决了一个大麻烦,先来看一下表结构
root@127.0.0.1 : information_schema 13:28:38> desc innodb_locks;
+-------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+
| lock_id | varchar(81) | NO | | | |#锁ID
| lock_trx_id | varchar(18) | NO | | | |#拥有锁的事务ID
| lock_mode | varchar(32) | NO | | | |#锁模式
| lock_type | varchar(32) | NO | | | |#锁类型
| lock_table | varchar(1024) | NO | | | |#被锁的表
| lock_index | varchar(1024) | YES | | NULL | |#被锁的索引
| lock_space | bigint(21) unsigned | YES | | NULL | |#被锁的表空间号
| lock_page | bigint(21) unsigned | YES | | NULL | |#被锁的页号
| lock_rec | bigint(21) unsigned | YES | | NULL | |#被锁的记录号
| lock_data | varchar(8192) | YES | | NULL | |#被锁的数据
+-------------+---------------------+------+-----+---------+-------+
10 rows in set (0.00 sec)
root@127.0.0.1 : information_schema 13:28:56> desc innodb_lock_waits;
+-------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-------------+------+-----+---------+-------+
| requesting_trx_id | varchar(18) | NO | | | |#请求锁的事务ID
| requested_lock_id | varchar(81) | NO | | | |#请求锁的锁ID
| blocking_trx_id | varchar(18) | NO | | | |#当前拥有锁的事务ID
| blocking_lock_id | varchar(81) | NO | | | |#当前拥有锁的锁ID
+-------------------+-------------+------+-----+---------+-------+
4 rows in set (0.00 sec)
root@127.0.0.1 : information_schema 13:29:05> desc innodb_trx ;
+----------------------------+---------------------+------+-----+---------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+---------------------+------+-----+---------------------+-------+
| trx_id | varchar(18) | NO | | | |#事务ID
| trx_state | varchar(13) | NO | | | |#事务状态:
| trx_started | datetime | NO | | 0000-00-00 00:00:00 | |#事务开始时间;
| trx_requested_lock_id | varchar(81) | YES | | NULL | |#innodb_locks.lock_id
| trx_wait_started | datetime | YES | | NULL | |#事务开始等待的时间
| trx_weight | bigint(21) unsigned | NO | | 0 | |#
| trx_mysql_thread_id | bigint(21) unsigned | NO | | 0 | |#事务线程ID
| trx_query | varchar(1024) | YES | | NULL | |#具体SQL语句
| trx_operation_state | varchar(64) | YES | | NULL | |#事务当前操作状态
| trx_tables_in_use | bigint(21) unsigned | NO | | 0 | |#事务中有多少个表被使用
| trx_tables_locked | bigint(21) unsigned | NO | | 0 | |#事务拥有多少个锁
| trx_lock_structs | bigint(21) unsigned | NO | | 0 | |#
| trx_lock_memory_bytes | bigint(21) unsigned | NO | | 0 | |#事务锁住的内存大小(B)
| trx_rows_locked | bigint(21) unsigned | NO | | 0 | |#事务锁住的行数
| trx_rows_modified | bigint(21) unsigned | NO | | 0 | |#事务更改的行数
| trx_concurrency_tickets | bigint(21) unsigned | NO | | 0 | |#事务并发票数
| trx_isolation_level | varchar(16) | NO | | | |#事务隔离级别
| trx_unique_checks | int(1) | NO | | 0 | |#是否唯一性检查
| trx_foreign_key_checks | int(1) | NO | | 0 | |#是否外键检查
| trx_last_foreign_key_error | varchar(256) | YES | | NULL | |#最后的外键错误
| trx_adaptive_hash_latched | int(1) | NO | | 0 | |#
| trx_adaptive_hash_timeout | bigint(21) unsigned | NO | | 0 | |#
+----------------------------+---------------------+------+-----+---------------------+-------+
22 rows in set (0.01 sec)
下面我们来动手看看数据吧:
##建立测试数据:
use test;
create table tx1
(id int primary key ,
c1 varchar(20),
c2 varchar(30))
engine=innodb default charset = utf8 ;
insert into tx1 values
(1,'aaaa','aaaaa2'),
(2,'bbbb','bbbbb2'),
(3,'cccc','ccccc2');
commit;
###产生事务;
### Session1
start transaction;
update tx1 set c1='heyf',c2='heyf' where id =3 ;
## 产生事务,在innodb_trx就有数据 ;
root@127.0.0.1 : information_schema 13:38:21> select * from innodb_trx G
*************************** 1. row ***************************
trx_id: 3669D82
trx_state: RUNNING
trx_started: 2010-12-24 13:38:06
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 2344
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: 1
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
1 row in set (0.00 sec)
### 由于没有产生锁等待,下面两个表没有数据 ;
root@127.0.0.1 : information_schema 13:38:31> select * from innodb_lock_waits G
Empty set (0.00 sec)
root@127.0.0.1 : information_schema 13:38:57> select * from innodb_locks G
Empty set (0.00 sec)
#### 产生锁等待
#### session 2
start transaction;
update tx1 set c1='heyfffff',c2='heyffffff' where id =3 ;
root@127.0.0.1 : information_schema 13:39:01> select * from innodb_trx G
*************************** 1. row ***************************
trx_id: 3669D83 ##第2个事务
trx_state: LOCK WAIT ## 处于等待状态
trx_started: 2010-12-24 13:40:07
trx_requested_lock_id: 3669D83:49:3:4 ##请求的锁ID
trx_wait_started: 2010-12-24 13:40:07
trx_weight: 2
trx_mysql_thread_id: 2346 ##线程 ID
trx_query: update tx1 set c1='heyfffff',c2='heyffffff' where id =3
trx_operation_state: starting index read
trx_tables_in_use: 1 ##需要用到1个表
trx_tables_locked: 1 ##有1个表被锁
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 1
trx_rows_modified: 0
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
*************************** 2. row ***************************
trx_id: 3669D82 ##第1个事务
trx_state: RUNNING
trx_started: 2010-12-24 13:38:06
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 2344
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: 1
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
2 rows in set (0.00 sec)
root@127.0.0.1 : information_schema 13:40:12> select * from innodb_locks G
*************************** 1. row ***************************
lock_id: 3669D83:49:3:4 ## 第2个事务需要的锁
lock_trx_id: 3669D83
lock_mode: X
lock_type: RECORD
lock_table: `test`.`tx1`
lock_index: `PRIMARY`
lock_space: 49
lock_page: 3
lock_rec: 4
lock_data: 3
*************************** 2. row ***************************
lock_id: 3669D82:49:3:4 ## 第1个事务需要的锁
lock_trx_id: 3669D82
lock_mode: X
lock_type: RECORD
lock_table: `test`.`tx1`
lock_index: `PRIMARY`
lock_space: 49
lock_page: 3
lock_rec: 4
lock_data: 3
2 rows in set (0.00 sec)
root@127.0.0.1 : information_schema 13:40:15> select * from innodb_lock_waits G
*************************** 1. row ***************************
requesting_trx_id: 3669D83 ## 请求锁的事务
requested_lock_id: 3669D83:49:3:4 ## 请求锁的锁ID
blocking_trx_id: 3669D82 ## 拥有锁的事务
blocking_lock_id: 3669D82:49:3:4 ## 拥有锁的锁ID
1 row in set (0.00 sec)
发表评论
-
主从延迟
2019-06-17 16:08 290主从复制原理 主从延 ... -
python脚本连接mysql
2018-02-24 12:18 528文件db #!/usr/bin/python #codi ... -
Shell脚本中执行sql语句操作mysql的5种方法
2018-01-22 21:41 1448源:http://www.jb51.net/article/5 ... -
MySQL Explain详解
2018-01-02 16:42 409源:https://www.cnblogs.com/x ... -
mysql repeatable-read 一次利用间隙锁解决幻读案例
2017-09-18 19:21 549源:http://fucheng.blog.51cto.com ... -
Mysql经mysql连接的空闲时间超过8小时后 MySQL自动断开该连接解决方案
2016-07-06 17:16 2174源:http://www.jb51.net/artic ... -
新安装mysql 第三方工具连接不上问题
2015-08-24 00:25 816源:http://blog.csdn.net/dongdong ... -
CentOS源码编译安装MySQL 5.5.15
2014-11-17 01:38 680源:https://www.centos.bz/2011/09 ... -
Mysql中limit的用法详解
2014-07-17 16:58 822源:http://blog.csdn.net/zhqingyu ... -
mysql重连,连接丢失:The Last Packet Successfully Received From the Server
2014-07-15 18:48 2017源:http://nkcoder.github.io/ 评: ... -
Fedora 8下的MySQL源码安装手记
2014-03-18 15:00 423源:http://blog.sina.com.cn/s/blo ... -
MySQL数据库添加一个字段
2014-03-14 11:14 656源:http://hi.baidu.com/pianxicun ... -
mysql查询 分组后前 N条数据
2014-01-17 16:04 1528源:http://www.jb51.net/article/3 ...
相关推荐
在MySQL数据库操作中,"SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded" 是一个常见的错误,它意味着在执行事务时,系统等待锁定资源的时间超过了预设的限制。这个错误通常发生在并发环境中,当...
- **innodb_lock_wait_timeout**:设置在等待锁时的超时时间,单位为秒。如果超过了这个时间还没有获取到锁,那么会抛出错误并提示用户重启事务。 ##### 3. 锁相关字典表查询和命令 MySQL提供了几个系统视图来查看...
python pymysql 无法登陆,报错pymysql.err.InternalError: (1698, "Access denied for user 'root'@'localhost'")或pymysql.err.InternalError: (1045, "Access denied for user 'root'@'localhost'"),详细报错...
此外,两种环境都存在等待问题,导致Lock wait timeout exceeded错误。 **3. 自定义SQL测试** 针对特定用户场景,进行了复杂查询SQL的自定义测试。在200个线程的高并发下,Mycat的CPU占用率为400%,而9个MySQL...
一个问题纠结很久,反复确认语法问题。但是后来网上搜了一下,茅塞顿开。特此总结一下。 mysql> grant select,insert,update,delete on *.* to 'root'@'%'; ERROR 1290 (HY000): The MySQL server is running with ...
在实际操作中,为了防止因事务隔离级别导致的问题,如"Lock wait timeout exceeded"错误,可能需要将MySQL的事务级别设置为`READ COMMITTED`。 一旦主服务器配置完成,就可以在备用服务器上重复类似步骤,但要使用...
12. **Lock wait timeout exceeded try restarting transaction**:在MySQL中,如果事务等待锁的时间超过设定的超时时间,会出现此错误。分析事务逻辑,优化事务粒度,或者提高锁等待超时时间(innodb_lock_wait_...
5. Lock wait timeout exceeded 当事务中的操作无法立即获得锁定时,会等待一段时间,超时后抛出错误。这可能是死锁的信号,应检查事务的执行顺序,避免循环等待。 6. InnoDB与MyISAM的区别 InnoDB支持事务和行级...
死锁(Deadlocking)是数据库管理系统中常见的一个问题,特别是在并发操作环境下。在SQL Server 2008中,死锁是指两个或多个并发事务互相等待对方释放资源,从而导致它们都无法继续执行的情况。当出现死锁时,SQL ...
#### ORA-00051: Lock wait timeout exceeded - **解释**: 锁等待超时。 - **解决方案**: 优化锁管理或增加等待时间。 #### ORA-00052: Lock timeout exceeded - **解释**: 锁超时。 - **解决方案**: 优化锁管理...
- 分析常见错误代码及含义,例如:Table lock wait timeout exceeded;Too many connections等。 **2. 查询日志** - **定义与作用**:查询日志记录了客户端执行的所有SQL语句。主要用于审计、故障排查以及性能...
`Error: ER_LOCK_WAIT_TIMEOUT: Lock wait timeout exceeded; try restarting transaction`表明某个事务在等待其他事务释放锁资源时超过了预设的超时时间。事务是数据库操作的重要组成部分,它确保了数据的一致性和...
如果Session 1长时间未提交,Session 2会收到`Lock wait timeout exceeded`错误。可以通过`innodb_lock_wait_timeout`配置参数调整超时时间。 **乐观锁(Optimistic Lock)** 乐观锁则相反,它在读取数据时不加锁...
当发生死锁时,数据库会检测到这种情况并抛出错误,如错误1205(HY000):“Lock wait timeout exceeded; try restarting transaction”。为了解决这个问题,我们需要找出导致死锁的具体线程并结束它。本文将详细...
As such, non-paged pool can be accessed at any time without incurring a page fault. Because device drivers operate at DPC/dispatch level (covered in lesson 2), and page faults are not allowed at this...