Lock_wait_timeout trong mysql là gì?

Nhóm kết nối cũng có thể được tăng lên. Vui lòng mở tệp

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

<property name="hibernate.c3p0.max_size">...</property>

Vui lòng tăng giá trị và khởi động lại phiên bản Bamboo của bạn

Mô tảMySQL - Đã quá thời gian chờ khóa - thử khởi động lại lỗi giao dịch xuất hiện trong nhật ký Tre

Nếu bạn vừa giết một truy vấn lớn, sẽ mất thời gian để

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Thông tin chi tiết

Tôi đã đưa ra truy vấn XÓA để xóa khoảng 900.000 trong số khoảng 1 triệu hàng

Tôi đã chạy nhầm (chỉ xóa 10% số hàng).

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Thay vì điều này (loại bỏ 90% số hàng).

CREATE DATABASE example_db;
USE example_db;
CREATE TABLE zipcode ( 
    code varchar(100) not null, 
    city varchar(100) not null, 
    country varchar(3) not null,
    PRIMARY KEY (code) 
);
INSERT INTO zipcode(code, city, country) 
VALUES ('08025', 'Barcelona', 'ESP'), 
       ('10583', 'New York', 'USA'), 
       ('11075-430', 'Santos', 'BRA'), 
       ('SW6', 'London', 'GBR');

Tôi muốn xóa 90% số hàng chứ không phải 10%. Vì vậy, tôi đã giết quá trình trong dòng lệnh MySQL, biết rằng nó sẽ khôi phục tất cả các hàng mà nó đã xóa cho đến nay

Sau đó, tôi chạy đúng lệnh ngay lập tức và gặp lỗi

CREATE DATABASE example_db;
USE example_db;
CREATE TABLE zipcode ( 
    code varchar(100) not null, 
    city varchar(100) not null, 
    country varchar(3) not null,
    PRIMARY KEY (code) 
);
INSERT INTO zipcode(code, city, country) 
VALUES ('08025', 'Barcelona', 'ESP'), 
       ('10583', 'New York', 'USA'), 
       ('11075-430', 'Santos', 'BRA'), 
       ('SW6', 'London', 'GBR');

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Trong hướng dẫn này, chúng ta sẽ nói về lỗi “Lock wait timeout stopped” trong MySQL. Chúng tôi sẽ thảo luận về nguyên nhân gây ra lỗi này và một số sắc thái liên quan đến khóa MySQL

Để đơn giản, chúng tôi sẽ tập trung vào công cụ InnoDB của MySQL, vì đây là một trong những công cụ phổ biến nhất. Tuy nhiên, chúng ta có thể sử dụng các thử nghiệm tương tự được sử dụng ở đây để kiểm tra hoạt động của các động cơ khác

2. Khóa trong MySQL

Khóa là một đối tượng đặc biệt kiểm soát quyền truy cập vào tài nguyên. Trong trường hợp của MySQL, các tài nguyên này có thể là bảng, hàng hoặc cấu trúc dữ liệu nội bộ

Một khái niệm khác để làm quen là chế độ khóa. Chế độ khóa “S” (dùng chung) cho phép giao dịch đọc một hàng. Nhiều giao dịch có thể có được khóa của một hàng cụ thể cùng một lúc

Khóa “X” (độc quyền) cho phép một giao dịch duy nhất có được nó. Giao dịch có thể cập nhật hoặc xóa hàng, trong khi giao dịch kia phải đợi cho đến khi khóa được giải phóng để họ có thể lấy nó

MySQL cũng có khóa ý định. Chúng có liên quan đến các bảng và cho biết loại khóa mà một giao dịch dự định có được trên các hàng trong bảng

Khóa là rất quan trọng để đảm bảo tính nhất quán và độ tin cậy trong môi trường đồng thời cao. Tuy nhiên, khi tối ưu hóa hiệu suất, phải thực hiện một số đánh đổi và trong những trường hợp đó, điều cần thiết là chọn mức cách ly chính xác

3. Mức độ cô lập

MySQL InnoDB cung cấp bốn cấp độ cách ly giao dịch. Chúng cung cấp các mức cân bằng khác nhau giữa hiệu suất, tính nhất quán, độ tin cậy và khả năng tái tạo. Chúng lần lượt là từ ít nghiêm ngặt nhất đến nghiêm ngặt nhất

• ĐỌC BẤT NGỜ. nói tóm lại, tất cả các giao dịch có thể đọc tất cả các thay đổi do người khác thực hiện ngay cả khi chúng không được cam kết
• CAM KẾT ĐÃ ĐỌC. chỉ những thay đổi đã cam kết mới hiển thị đối với các giao dịch khác
• ĐỌC LẶP LẠI. truy vấn đầu tiên xác định ảnh chụp nhanh và nó trở thành đường cơ sở cho hàng đó. Ngay cả khi một giao dịch khác thay đổi hàng ngay sau khi đọc, đường cơ sở sẽ luôn được trả về nếu không có thay đổi nào sau truy vấn đầu tiên
• CÓ THỂ XÁC NHẬN. hoạt động chính xác như phần trước ngoại trừ nếu tự động cam kết bị tắt, nó sẽ khóa hàng trong bất kỳ cập nhật hoặc xóa nào và chỉ được phép đọc sau khi cam kết

Bây giờ chúng ta đã hiểu cách thức hoạt động của các mức cô lập khác nhau, hãy chạy một số thử nghiệm để kiểm tra các tình huống khóa. Đầu tiên, để ngắn gọn, chúng tôi sẽ chạy tất cả thử nghiệm ở mức cô lập mặc định ĐỌC LẶP LẠI. Tuy nhiên, sau này chúng ta có thể chạy thử nghiệm cho tất cả các cấp độ khác

4. Giám sát

Các công cụ chúng ta sẽ thấy ở đây không nhất thiết phải áp dụng cho mục đích sản xuất. Thay vào đó, họ sẽ cho phép chúng tôi hiểu những gì đang xảy ra bên dưới mui xe

Các lệnh sẽ mô tả cách MySQL xử lý giao dịch và khóa nào liên quan đến giao dịch nào hoặc cách thu thập thêm dữ liệu từ các giao dịch đó. Vì vậy, một lần nữa, những công cụ này sẽ giúp chúng tôi trong quá trình thử nghiệm nhưng có thể không áp dụng được trong môi trường sản xuất hoặc ít nhất là không áp dụng được khi lỗi đã xảy ra

4. 1. Trạng thái InnoDB

Lệnh SHOW ENGINE INNODB STATUS hiển thị cho chúng ta rất nhiều thông tin về cấu trúc bên trong, đối tượng và số liệu. Đầu ra có thể bị cắt bớt tùy thuộc vào số lượng kết nối khả dụng và đang hoạt động. Tuy nhiên, chúng tôi chỉ cần xem phần giao dịch cho trường hợp sử dụng của chúng tôi

Trong phần giao dịch, chúng ta sẽ tìm thấy những thứ như

• số lượng giao dịch hoạt động
• trạng thái của từng giao dịch
• số lượng bảng tham gia vào mỗi giao dịch
• số lượng khóa thu được từ giao dịch
• có thể câu lệnh được thực hiện có thể đang giữ giao dịch
• thông tin về khóa chờ

Còn nhiều điều nữa để xem ở đó, nhưng điều này sẽ là đủ cho chúng ta bây giờ

4. 2. Danh sách quy trình

Lệnh SHOW PROCESSLIST hiển thị một bảng có phiên hiện đang được mở và bảng hiển thị các thông tin sau

• id phiên
• tên tài khoản
• máy chủ được kết nối
• cơ sở dữ liệu
• lệnh/loại câu lệnh hoạt động hiện tại
• thời gian chạy
• trạng thái kết nối
• mô tả phiên

Lệnh này cho phép chúng tôi có cái nhìn tổng quan về các phiên hoạt động khác nhau, trạng thái và hoạt động của chúng

4. 3. Chọn Tuyên bố

MySQL hiển thị một số thông tin hữu ích thông qua một số bảng và chúng ta có thể sử dụng chúng để hiểu các loại chiến lược khóa được áp dụng trong một tình huống nhất định. Họ cũng giữ những thứ như id của giao dịch hiện tại

Với mục đích của bài viết này, chúng tôi sẽ sử dụng bảng information_schema. innodb_trx và performance_schema. data_locks

5. Thiết lập thử nghiệm

Để chạy thử nghiệm, chúng tôi sẽ sử dụng hình ảnh docker của MySQL để tạo cơ sở dữ liệu và điền vào lược đồ thử nghiệm để chúng tôi có thể thực hiện một số tình huống giao dịch

# Create MySQL container 
docker run --network host --name example_db -e MYSQL_ROOT_PASSWORD=root -d mysql

Khi chúng tôi có máy chủ cơ sở dữ liệu của mình, chúng tôi có thể tạo lược đồ bằng cách kết nối với nó và thực thi các tập lệnh

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Sau đó, sau khi nhập mật khẩu, hãy tạo cơ sở dữ liệu và chèn một số dữ liệu

CREATE DATABASE example_db;
USE example_db;
CREATE TABLE zipcode ( 
    code varchar(100) not null, 
    city varchar(100) not null, 
    country varchar(3) not null,
    PRIMARY KEY (code) 
);
INSERT INTO zipcode(code, city, country) 
VALUES ('08025', 'Barcelona', 'ESP'), 
       ('10583', 'New York', 'USA'), 
       ('11075-430', 'Santos', 'BRA'), 
       ('SW6', 'London', 'GBR');

6. Kịch bản thử nghiệm

Điều quan trọng nhất cần nhớ là lỗi "Đã quá thời gian chờ khóa" xảy ra khi một giao dịch đang chờ một khóa khác có được

Lượng thời gian mà giao dịch sẽ đợi tùy thuộc vào giá trị trong thuộc tính innodb_lock_wait_timeout được xác định ở cấp độ phiên hoặc toàn cầu

Khả năng đối mặt với lỗi này phụ thuộc vào độ phức tạp và số lượng giao dịch mỗi giây. Tuy nhiên, chúng tôi sẽ cố gắng tái tạo một số tình huống phổ biến

Một điểm khác có thể đáng nói là chiến lược thử lại đơn giản có thể giải quyết vấn đề do lỗi này gây ra

Để giúp chúng tôi trong quá trình thử nghiệm, chúng tôi sẽ chạy lệnh sau cho tất cả các phiên chúng tôi mở

USE example_db;
-- Set our timeout to 10 seconds
SET @@SESSION.innodb_lock_wait_timeout = 10;

Điều này xác định thời gian chờ khóa là 10 giây, giúp chúng tôi không phải đợi quá lâu để xem lỗi

6. 1. Khóa hàng

Vì các khóa hàng có được trong các tình huống khác nhau, hãy thử tạo lại một mẫu

Trước tiên, chúng tôi sẽ kết nối với máy chủ từ hai phiên khác nhau bằng cách sử dụng tập lệnh MySQL đăng nhập mà chúng tôi đã thấy trước đó. Sau đó, hãy chạy câu lệnh bên dưới trong cả hai phiên

SET autocommit=0;
UPDATE zipcode SET code = 'SW6 1AA' WHERE code = 'SW6';

Sau 10 giây, phiên thứ hai sẽ thất bại

mysql>  UPDATE zipcode SET code = 'SW6 1AA' WHERE code = 'SW6';
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Lỗi xảy ra do phiên đầu tiên bắt đầu giao dịch do tắt tự động cam kết. Tiếp theo, khi câu lệnh CẬP NHẬT chạy trong giao dịch, khóa độc quyền của hàng đó sẽ được lấy. Tuy nhiên, không có cam kết nào được thực hiện, khiến giao dịch mở và khiến giao dịch khác tiếp tục chờ đợi. Vì cam kết không bao giờ xảy ra, thời gian chờ khóa đạt đến giới hạn. Điều này cũng áp dụng cho câu lệnh DELETE

6. 2. Kiểm tra Row Lock trong Data Locks Table

Bây giờ, hãy khôi phục cả hai phiên và chạy tập lệnh như trước trong phiên đầu tiên, nhưng lần này, trong phiên thứ hai, hãy chạy các câu lệnh sau

SET autocommit=0;
UPDATE zipcode SET code = 'Test' WHERE code = '08025';

Như chúng ta có thể quan sát, cả hai câu lệnh đều thực thi thành công vì chúng không còn yêu cầu khóa của cùng một hàng

Để xác nhận điều đó, chúng tôi sẽ chạy câu lệnh sau trong bất kỳ phiên nào hoặc trong phiên mới

Câu lệnh trên trả về bốn hàng, hai trong số đó là khóa mục đích của bảng xác định rằng một giao dịch có thể có ý định khóa một hàng trong bảng và hai hàng còn lại là khóa bản ghi. Nhìn vào các cột LOCK_TYPE, LOCK_MODE và LOCK_DATA, chúng tôi có thể xác nhận các ổ khóa mà chúng tôi vừa mô tả

Chạy rollback trong cả hai phiên và truy vấn lại, kết quả là một tập dữ liệu trống

6. 3. Khóa hàng và chỉ mục

Lần này, hãy sử dụng một cột khác trong mệnh đề WHERE của chúng ta. Đối với phiên đầu tiên, chúng tôi sẽ chạy

SET autocommit=0;
UPDATE zipcode SET city = 'SW6 1AA' WHERE country = 'USA';

Trong phần thứ hai, hãy chạy các câu lệnh này

# Create MySQL container 
docker run --network host --name example_db -e MYSQL_ROOT_PASSWORD=root -d mysql

Một điều bất ngờ vừa xảy ra. Mặc dù các câu lệnh nhắm mục tiêu đến hai hàng khác nhau, chúng tôi đã gặp lỗi hết thời gian khóa. Ok, nếu chúng ta lặp lại bài kiểm tra này ngay sau khi chạy câu lệnh SELECT trên bảng performance_schema. data_locks, chúng ta sẽ thấy rằng trên thực tế, phiên đầu tiên đã khóa tất cả các hàng và phiên thứ hai đang chờ

Sự cố liên quan đến cách MySQL thực hiện truy vấn để tìm ứng viên cho bản cập nhật vì cột được sử dụng trong mệnh đề WHERE không có chỉ mục. MySQL phải quét tất cả các hàng để tìm những hàng khớp với điều kiện WHERE, điều này cũng khiến các hàng này bị khóa

Điều quan trọng là đảm bảo rằng các tuyên bố của chúng tôi là tối ưu

6. 4. Khóa hàng và cập nhật/xóa với nhiều bảng

Các trường hợp phổ biến khác đối với lỗi hết thời gian khóa là các câu lệnh XÓA và CẬP NHẬT liên quan đến nhiều bảng. Số lượng hàng bị khóa tùy thuộc vào kế hoạch thực hiện câu lệnh, nhưng chúng ta nên nhớ rằng tất cả các bảng liên quan có thể có một số hàng bị khóa

Ví dụ, hãy quay lui tất cả các giao dịch khác và thực hiện các câu lệnh này

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Tại đây, chúng tôi đã tạo một bảng và bắt đầu một giao dịch đọc từ bảng zipcode và ghi vào bảng zipcode_backup trong một câu lệnh

Bước tiếp theo là chạy câu lệnh sau trong phiên thứ hai

SET autocommit=0;
UPDATE zipcode SET code = 'SW6 1AA' WHERE code = 'SW6';

Một lần nữa, giao dịch thứ hai đã hết thời gian vì giao dịch đầu tiên đã có được khóa của các hàng trong bảng. Hãy chạy câu lệnh SELECT trong bảng data_lock để chứng minh điều gì đã xảy ra. Sau đó, hãy khôi phục cả hai phiên

6. 5. Khóa hàng khi điền bảng tạm thời

Trong ví dụ này, hãy kết hợp thực thi DDL và DML trong phiên đầu tiên của tập lệnh mới

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Sau đó, nếu chúng tôi lặp lại câu lệnh mà chúng tôi đã sử dụng trước đó trong phiên thứ hai, chúng tôi sẽ có thể thấy lỗi khóa một lần nữa

6. 6. Khóa chia sẻ và độc quyền

Đừng quên khôi phục cả hai giao dịch phiên vào cuối mỗi bài kiểm tra

Chúng tôi đã thảo luận về các khóa được chia sẻ và độc quyền. Tuy nhiên, chúng tôi không thấy cách xác định chúng một cách rõ ràng bằng cách sử dụng các tùy chọn KHÓA TRONG CHẾ ĐỘ CHIA SẺ và ĐỂ CẬP NHẬT. Trước tiên, hãy sử dụng chế độ chia sẻ

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Bây giờ, chúng tôi sẽ chạy bản cập nhật giống như chúng tôi đã làm trước đây và kết quả lại là thời gian chờ. Bên cạnh đó, chúng ta nên nhớ rằng ở đây cho phép đọc

Trái ngược với CHẾ ĐỘ CHIA SẺ, FOR UPDATE không cho phép khóa đọc, như được hiển thị tiếp theo khi chúng tôi chạy một câu lệnh trong phiên đầu tiên

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Và sau đó, chúng tôi chạy cùng một câu lệnh CHỌN với tùy chọn CHẾ ĐỘ CHIA SẺ được sử dụng trước đây trong phiên đầu tiên, nhưng bây giờ trong phiên thứ hai và chúng tôi sẽ quan sát lại lỗi hết thời gian chờ một lần nữa. Tóm lại, khóa CHẾ ĐỘ CHIA SẺ có thể được sử dụng trong nhiều phiên và khóa ghi. Tùy chọn khóa độc quyền hoặc ĐỂ CẬP NHẬT cho phép đọc nhưng không khóa đọc hoặc ghi

6. 7. Khóa bàn

Khóa bảng không có thời gian chờ và không được khuyến nghị cho InnoDB

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Khi chúng tôi chạy cái này, chúng tôi có thể mở một phiên khác, thử chọn hoặc cập nhật và kiểm tra xem nó có bị khóa không, nhưng lần này, không có thời gian chờ nào xảy ra. Đi xa hơn một chút, chúng ta có thể mở phiên thứ ba và chạy

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Nó hiển thị các phiên đang hoạt động với trạng thái của chúng và chúng ta sẽ thấy phiên đầu tiên đang ngủ và phiên thứ hai đang chờ khóa siêu dữ liệu của bảng. Giải pháp trong trường hợp này là chạy lệnh tiếp theo

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Các tình huống khác mà chúng tôi có thể tìm thấy các phiên đang chờ để có được một số khóa siêu dữ liệu trong quá trình thực thi DDL, chẳng hạn như ALTER TABLEs

6. 8. Khóa khoảng cách

Khóa khoảng cách xảy ra khi một khoảng thời gian cụ thể của các bản ghi được lập chỉ mục bị khóa và một phiên khác cố gắng thực hiện một số thao tác trong khoảng thời gian này. Trong trường hợp này, thậm chí chèn có thể bị ảnh hưởng

Hãy xem xét câu lệnh sau được thực thi trong phiên đầu tiên

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Trong phiên thứ hai, chúng tôi sẽ chạy câu lệnh sau

# Logging in MySQL 
docker exec -it example_db mysql -uroot -p

Sau khi chạy khóa dữ liệu, chúng tôi chọn câu lệnh trong phiên thứ ba để có thể kiểm tra giá trị LOCK MODE mới, GAP. Điều này cũng có thể được áp dụng cho các câu lệnh CẬP NHẬT và XÓA

6. 9. Bế tắc

Theo mặc định, MySQL cố gắng xác định các bế tắc và trong trường hợp nó quản lý để giải quyết biểu đồ phụ thuộc giữa các giao dịch, nó sẽ tự động hủy một trong các tác vụ để cho phép các tác vụ khác thực hiện. Mặt khác, chúng tôi gặp lỗi hết thời gian khóa, như chúng tôi đã thấy trước đây

Hãy mô phỏng một kịch bản bế tắc đơn giản. Đối với phiên đầu tiên, chúng tôi thực hiện

CREATE DATABASE example_db;
USE example_db;
CREATE TABLE zipcode ( 
    code varchar(100) not null, 
    city varchar(100) not null, 
    country varchar(3) not null,
    PRIMARY KEY (code) 
);
INSERT INTO zipcode(code, city, country) 
VALUES ('08025', 'Barcelona', 'ESP'), 
       ('10583', 'New York', 'USA'), 
       ('11075-430', 'Santos', 'BRA'), 
       ('SW6', 'London', 'GBR');

Câu lệnh SELECT cuối cùng sẽ cung cấp cho chúng ta ID giao dịch hiện tại. Chúng tôi sẽ cần nó để kiểm tra nhật ký sau này. Sau đó, đối với phiên thứ hai, hãy chạy

CREATE DATABASE example_db;
USE example_db;
CREATE TABLE zipcode ( 
    code varchar(100) not null, 
    city varchar(100) not null, 
    country varchar(3) not null,
    PRIMARY KEY (code) 
);
INSERT INTO zipcode(code, city, country) 
VALUES ('08025', 'Barcelona', 'ESP'), 
       ('10583', 'New York', 'USA'), 
       ('11075-430', 'Santos', 'BRA'), 
       ('SW6', 'London', 'GBR');

Theo trình tự, chúng tôi quay lại phiên một và chạy

CREATE DATABASE example_db;
USE example_db;
CREATE TABLE zipcode ( 
    code varchar(100) not null, 
    city varchar(100) not null, 
    country varchar(3) not null,
    PRIMARY KEY (code) 
);
INSERT INTO zipcode(code, city, country) 
VALUES ('08025', 'Barcelona', 'ESP'), 
       ('10583', 'New York', 'USA'), 
       ('11075-430', 'Santos', 'BRA'), 
       ('SW6', 'London', 'GBR');

Ngay lập tức, chúng tôi sẽ nhận được một lỗi

CREATE DATABASE example_db;
USE example_db;
CREATE TABLE zipcode ( 
    code varchar(100) not null, 
    city varchar(100) not null, 
    country varchar(3) not null,
    PRIMARY KEY (code) 
);
INSERT INTO zipcode(code, city, country) 
VALUES ('08025', 'Barcelona', 'ESP'), 
       ('10583', 'New York', 'USA'), 
       ('11075-430', 'Santos', 'BRA'), 
       ('SW6', 'London', 'GBR');

Và cuối cùng, chúng tôi chuyển sang phiên thứ ba, và chúng tôi chạy

CREATE DATABASE example_db;
USE example_db;
CREATE TABLE zipcode ( 
    code varchar(100) not null, 
    city varchar(100) not null, 
    country varchar(3) not null,
    PRIMARY KEY (code) 
);
INSERT INTO zipcode(code, city, country) 
VALUES ('08025', 'Barcelona', 'ESP'), 
       ('10583', 'New York', 'USA'), 
       ('11075-430', 'Santos', 'BRA'), 
       ('SW6', 'London', 'GBR');

Đầu ra của lệnh phải tương tự như thế này

CREATE DATABASE example_db;
USE example_db;
CREATE TABLE zipcode ( 
    code varchar(100) not null, 
    city varchar(100) not null, 
    country varchar(3) not null,
    PRIMARY KEY (code) 
);
INSERT INTO zipcode(code, city, country) 
VALUES ('08025', 'Barcelona', 'ESP'), 
       ('10583', 'New York', 'USA'), 
       ('11075-430', 'Santos', 'BRA'), 
       ('SW6', 'London', 'GBR');

Sử dụng các id giao dịch mà chúng tôi có trước đây, chúng tôi có thể tìm thấy rất nhiều thông tin hữu ích, chẳng hạn như trạng thái của kết nối tại thời điểm xảy ra lỗi, số lần khóa hàng, lệnh cuối cùng được thực thi, mô tả về các khóa đang giữ và . Sau đó, nó lặp lại tương tự cho các giao dịch khác liên quan đến bế tắc. Ngoài ra, cuối cùng, chúng tôi tìm thấy thông tin về giao dịch nào đã được khôi phục

7. Sự kết luận

Trong bài viết này, chúng tôi đã xem xét các khóa trong MySQL, cách chúng hoạt động và thời điểm chúng gây ra lỗi “Vượt quá thời gian chờ khóa”

Chúng tôi đã xác định các kịch bản thử nghiệm cho phép chúng tôi tái tạo lỗi này và kiểm tra các sắc thái bên trong của máy chủ cơ sở dữ liệu khi xử lý các giao dịch

Lock_wait_timeout là gì?

Điều gì gây ra thời gian chờ khóa vượt quá thời gian chờ?

Connect_timeout trong MySQL là gì?

Net_read_timeout trong MySQL là gì?