mysql死锁几种情况的测试_MySQL
sessionA:
test>begin
-> ;
Query OK, 0 rows affected (0.00 sec)
test>select * from tt where id_test=1234 lock in share mode;
+—-+———+
| id | id_test |
+—-+———+
| 4 | 1234 |
+—-+———+
1 row in set (0.01 sec)
sessionB:
test>delete from tt where id_test=1234;
卡住
sessionA:
test>delete from tt where id_test=1234;
Query OK, 1 row affected (0.00 sec)
sessionb被杀掉,a执行
查看锁信息
(none)>show engine innodb status\G
***************** 1. row *****************
Type: InnoDB
Name:
Status:
2016-05-09 16:26:27 7f8ee2123700 INNODB MONITOR OUTPUT
Per second averages calculated from the last 18 seconds
BACKGROUND THREAD
srv_master_thread loops: 9 srv_active, 0 srv_shutdown, 191469 srv_idle
srv_master_thread log flush and writes: 191478
SEMAPHORES
OS WAIT ARRAY INFO: reservation count 23
OS WAIT ARRAY INFO: signal count 23
Mutex spin waits 16, rounds 210, OS waits 7
RW-shared spins 16, rounds 480, OS waits 16
RW-excl spins 0, rounds 0, OS waits 0
Spin rounds per wait: 13.12 mutex, 30.00 RW-shared, 0.00 RW-excl
LATEST DETECTED DEADLOCK
2016-05-09 15:56:30 7f8ee2154700
* (1) TRANSACTION:
TRANSACTION 4396, ACTIVE 11 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)
MySQL thread id 4, OS thread handle 0x7f8ee2123700, query id 52 192.168.90.109 myadmin updating
delete from tt where id_test=1234
* (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 36 page no 3 n bits 88 index PRIMARY of table test.tt trx id 4396 lock_mode X waiting
Record lock, heap no 10 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 8; hex 8000000000000001; asc ;;
1: len 6; hex 000000001117; asc ;;
2: len 7; hex 13000001460476; asc F v;;
3: len 4; hex 800003e8; asc ;;
* (2) TRANSACTION:
TRANSACTION 4395, ACTIVE 30 sec starting index read, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1184, 7 row lock(s)
MySQL thread id 3, OS thread handle 0x7f8ee2154700, query id 53 192.168.90.109 myadmin updating
delete from tt where id_test=1234
* (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 36 page no 3 n bits 88 index PRIMARY of table test.tt trx id 4395 lock mode S
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 10 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 8; hex 8000000000000001; asc ;;
1: len 6; hex 000000001117; asc ;;
2: len 7; hex 13000001460476; asc F v;;
3: len 4; hex 800003e8; asc ;;
Record lock, heap no 11 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 8; hex 8000000000000002; asc ;;
1: len 6; hex 000000001117; asc ;;
2: len 7; hex 1300000146049b; asc F ;;
3: len 4; hex 800003e8; asc ;;
Record lock, heap no 12 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 8; hex 8000000000000003; asc ;;
1: len 6; hex 000000001117; asc ;;
2: len 7; hex 130000014604c0; asc F ;;
3: len 4; hex 800003e8; asc ;;
Record lock, heap no 13 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 8; hex 8000000000000004; asc ;;
1: len 6; hex 000000001129; asc );;
2: len 7; hex 1d000001d202df; asc ;;
3: len 4; hex 800004d2; asc ;;
Record lock, heap no 15 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 8; hex 8000000000000006; asc ;;
1: len 6; hex 000000001117; asc ;;
2: len 7; hex 1300000146052f; asc F /;;
3: len 4; hex 800003e8; asc ;;
* (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 36 page no 3 n bits 88 index PRIMARY of table test.tt trx id 4395 lock_mode X waiting
Record lock, heap no 10 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 8; hex 8000000000000001; asc ;;
1: len 6; hex 000000001117; asc ;;
2: len 7; hex 13000001460476; asc F v;;
3: len 4; hex 800003e8; asc ;;
* WE ROLL BACK TRANSACTION (1)
a持有s锁,b执行删除操作请求x,但sx互斥,b进入请求队列等待,a在请求x锁,这个时候队列中b在排队,还轮不上a,a就等待,这种循环等待出现,死锁就出现了。
下面是oracle中经常出现的场景
sessionA
test>select * from tt;
+—-+———+
| id | id_test |
+—-+———+
| 1 | 1000 |
| 3 | 1000 |
| 4 | 1234 |
| 6 | 1000 |
+—-+———+
4 rows in set (0.00 sec)
select * from t7;
+—-+——+
| id | name |
+—-+——+
| 1 | aa |
+—-+——+
1 row in set (0.01 sec)
.test>begin;
Query OK, 0 rows affected (0.00 sec)
先删除7中的id=1,sessionb中删除ttid=1
delete from t7 where id=1;
Query OK, 1 row affected (0.01 sec)
session B
delete from tt where id=1;
Query OK, 1 row affected (0.00 sec)
sessionA:
delete from tt where id=1;
等待卡住
sessionB;
delete from t7 where id=1;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
产生死锁
LATEST DETECTED DEADLOCK
2016-05-09 16:47:14 7f8ee2154700
* (1) TRANSACTION:
TRANSACTION 4443, ACTIVE 36 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 1
MySQL thread id 10, OS thread handle 0x7f8ee20f2700, query id 133 192.168.90.109 myadmin updating
delete from tt where id=1
* (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 36 page no 3 n bits 88 index PRIMARY of table test.tt trx id 4443 lock_mode X locks rec but not gap waiting
Record lock, heap no 10 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
0: len 8; hex 8000000000000001; asc ;;
1: len 6; hex 00000000115a; asc Z;;
2: len 7; hex 3800000151037d; asc 8 Q };;
3: len 4; hex 800003e8; asc ;;
* (2) TRANSACTION:
TRANSACTION 4442, ACTIVE 52 sec starting index read, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 1
MySQL thread id 12, OS thread handle 0x7f8ee2154700, query id 134 192.168.90.109 myadmin updating
delete from t7 where id=1
* (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 36 page no 3 n bits 88 index PRIMARY of table test.tt trx id 4442 lock_mode X locks rec but not gap
Record lock, heap no 10 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
0: len 8; hex 8000000000000001; asc ;;
1: len 6; hex 00000000115a; asc Z;;
2: len 7; hex 3800000151037d; asc 8 Q };;
3: len 4; hex 800003e8; asc ;;
* (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 29 page no 3 n bits 72 index PRIMARY of table test.t7 trx id 4442 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
0: len 4; hex 80000001; asc ;;
1: len 6; hex 00000000115b; asc [;;
2: len 7; hex 39000001e00827; asc 9 ‘;;
3: len 2; hex 6161; asc aa;;
* WE ROLL BACK TRANSACTION (2)
看到这种也是因为互相请求对方不释放的资源导致的死锁
以上就是mysql死锁几种情况的测试_MySQL的内容,更多相关内容请关注PHP中文网(www.php.cn)!

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











Root로 MySQL에 로그인 할 수없는 주된 이유는 권한 문제, 구성 파일 오류, 암호 일관성이 없음, 소켓 파일 문제 또는 방화벽 차단입니다. 솔루션에는 다음이 포함됩니다. 구성 파일의 BAND-ADDRESS 매개 변수가 올바르게 구성되어 있는지 확인하십시오. 루트 사용자 권한이 수정 또는 삭제되어 재설정되었는지 확인하십시오. 케이스 및 특수 문자를 포함하여 비밀번호가 정확한지 확인하십시오. 소켓 파일 권한 설정 및 경로를 확인하십시오. 방화벽이 MySQL 서버에 연결되는지 확인하십시오.

MySQL이 테이블 구조를 수정하면 메타 데이터 잠금 장치가 일반적으로 사용되므로 테이블을 잠글 수 있습니다. 자물쇠의 영향을 줄이려면 다음과 같은 조치를 취할 수 있습니다. 1. 온라인 DDL과 함께 테이블을 사용할 수 있습니다. 2. 배치에서 복잡한 수정을 수행합니다. 3. 소형 또는 피크 기간 동안 운영됩니다. 4. PT-OSC 도구를 사용하여 더 미세한 제어를 달성하십시오.

데이터 통합 단순화 : AmazonRdsMysQL 및 Redshift의 Zero ETL 통합 효율적인 데이터 통합은 데이터 중심 구성의 핵심입니다. 전통적인 ETL (추출, 변환,로드) 프로세스는 특히 데이터베이스 (예 : AmazonRDSMySQL)를 데이터웨어 하우스 (예 : Redshift)와 통합 할 때 복잡하고 시간이 많이 걸립니다. 그러나 AWS는 이러한 상황을 완전히 변경 한 Zero ETL 통합 솔루션을 제공하여 RDSMYSQL에서 Redshift로 데이터 마이그레이션을위한 단순화 된 거의 실시간 솔루션을 제공합니다. 이 기사는 RDSMYSQL ZERL ETL 통합으로 Redshift와 함께 작동하여 데이터 엔지니어 및 개발자에게 제공하는 장점과 장점을 설명합니다.

MySQL 데이터베이스에서 사용자와 데이터베이스 간의 관계는 권한과 테이블로 정의됩니다. 사용자는 데이터베이스에 액세스 할 수있는 사용자 이름과 비밀번호가 있습니다. 권한은 보조금 명령을 통해 부여되며 테이블은 Create Table 명령에 의해 생성됩니다. 사용자와 데이터베이스 간의 관계를 설정하려면 데이터베이스를 작성하고 사용자를 생성 한 다음 권한을 부여해야합니다.

MySQL에는 무료 커뮤니티 버전과 유료 엔터프라이즈 버전이 있습니다. 커뮤니티 버전은 무료로 사용 및 수정할 수 있지만 지원은 제한되어 있으며 안정성이 낮은 응용 프로그램에 적합하며 기술 기능이 강합니다. Enterprise Edition은 안정적이고 신뢰할 수있는 고성능 데이터베이스가 필요하고 지원 비용을 기꺼이 지불하는 응용 프로그램에 대한 포괄적 인 상업적 지원을 제공합니다. 버전을 선택할 때 고려 된 요소에는 응용 프로그램 중요도, 예산 책정 및 기술 기술이 포함됩니다. 완벽한 옵션은없고 가장 적합한 옵션 만 있으므로 특정 상황에 따라 신중하게 선택해야합니다.

1. 올바른 색인을 사용하여 스캔 한 데이터의 양을 줄임으로써 데이터 검색 속도를 높이십시오. 테이블 열을 여러 번 찾으면 해당 열에 대한 인덱스를 만듭니다. 귀하 또는 귀하의 앱이 기준에 따라 여러 열에서 데이터가 필요한 경우 복합 인덱스 2를 만듭니다. 2. 선택을 피하십시오 * 필요한 열만 선택하면 모든 원치 않는 열을 선택하면 더 많은 서버 메모리를 선택하면 서버가 높은 부하 또는 주파수 시간으로 서버가 속도가 느려지며, 예를 들어 Creation_at 및 Updated_at 및 Timestamps와 같은 열이 포함되어 있지 않기 때문에 쿼리가 필요하지 않기 때문에 테이블은 선택을 피할 수 없습니다.

MySQL 데이터베이스 성능 최적화 안내서 리소스 집약적 응용 프로그램에서 MySQL 데이터베이스는 중요한 역할을 수행하며 대규모 트랜잭션 관리를 담당합니다. 그러나 응용 프로그램 규모가 확장됨에 따라 데이터베이스 성능 병목 현상은 종종 제약이됩니다. 이 기사는 일련의 효과적인 MySQL 성능 최적화 전략을 탐색하여 응용 프로그램이 고 부하에서 효율적이고 반응이 유지되도록합니다. 실제 사례를 결합하여 인덱싱, 쿼리 최적화, 데이터베이스 설계 및 캐싱과 같은 심층적 인 주요 기술을 설명합니다. 1. 데이터베이스 아키텍처 설계 및 최적화 된 데이터베이스 아키텍처는 MySQL 성능 최적화의 초석입니다. 몇 가지 핵심 원칙은 다음과 같습니다. 올바른 데이터 유형을 선택하고 요구 사항을 충족하는 가장 작은 데이터 유형을 선택하면 저장 공간을 절약 할 수있을뿐만 아니라 데이터 처리 속도를 향상시킬 수 있습니다.

MySQL은 Android에서 직접 실행할 수는 없지만 다음 방법을 사용하여 간접적으로 구현할 수 있습니다. Android 시스템에 구축 된 Lightweight Database SQLite를 사용하여 별도의 서버가 필요하지 않으며 모바일 장치 애플리케이션에 매우 적합한 작은 리소스 사용량이 있습니다. MySQL 서버에 원격으로 연결하고 데이터 읽기 및 쓰기를 위해 네트워크를 통해 원격 서버의 MySQL 데이터베이스에 연결하지만 강력한 네트워크 종속성, 보안 문제 및 서버 비용과 같은 단점이 있습니다.
