FiveM MySQL Deadlock Error 1213 แก้อย่างไร? วิธีแก้ Deadlock Found When Trying to Get Lock และป้องกัน Database Transaction ชนกัน

August 17, 2026

ปัญหา FiveM MySQL/MariaDB ขึ้น Error 1213: Deadlock found when trying to get lock; try restarting transaction เกิดเมื่อ Transaction ตั้งแต่สองชุดขึ้นไปรอ Lock ของกันและกันจนไม่มีฝ่ายใดเดินหน้าต่อได้ Database จึงต้องยุติ Transaction หนึ่งเพื่อทำลายวงจร Deadlock โดย MariaDB กำหนด Error 1213, SQLSTATE 40001 เป็น ER_LOCK_DEADLOCK.

ตัวอย่าง Error:


ERROR 1213 (40001):
Deadlock found when trying to get lock;
try restarting transaction

หรือ FiveM Console อาจขึ้นลักษณะ:


ER_LOCK_DEADLOCK


Deadlock found when trying to get lock


Transaction failed: deadlock detected

ปัญหานี้สามารถเกิดกับระบบ FiveM ที่มีการเขียน Database พร้อมกันจำนวนมาก เช่น:

Banking
Inventory
Vehicle Garage
Billing
Business
Society Money
Player Save
Housing
Item Transactions
Character Save
Logs
Economy
Crafting

หลักการแก้คือ:

หา Transaction ที่ชนกัน → ดู Tables/Rows ที่ Lock → ลดเวลาถือ Lock → จัดลำดับการ Update ให้เหมือนกัน → Retry Transaction อย่างปลอดภัย → ลด Query ที่ไม่จำเป็นใน Transaction

① FiveM MySQL Error 1213 คืออะไร

MariaDB ระบุ Error 1213 ว่า:


1213
40001
ER_LOCK_DEADLOCK
Deadlock found when trying to get lock; try restarting transaction

โดยตรง.

② Deadlock คืออะไรแบบง่าย

ลองนึกว่ามี Transaction A และ Transaction B

A ล็อก Record 1

B ล็อก Record 2

จากนั้น A ต้องการ Record 2

แต่ B ถืออยู่

ขณะเดียวกัน B ต้องการ Record 1

แต่ A ถืออยู่

จึงเกิด:


A รอ B
B รอ A

ไม่มีใครเดินต่อได้

③ นี่เรียกว่า Circular Dependency

MariaDB อธิบาย Deadlock ว่าเกิดเมื่อ Transaction อย่างน้อยสองชุดรอให้อีกฝ่ายเสร็จ จนกลายเป็นวงจรการรอกัน.

④ Database จัดการอย่างไร

InnoDB โดยปกติมี Deadlock Detector เปิดใช้งาน และสามารถตรวจพบวงจรดังกล่าว จากนั้น Transaction หนึ่งจะถูกยุติเพื่อให้ Transaction อื่นเดินหน้าต่อได้.

⑤ Error 1213 จึงไม่ได้แปลว่า Database พัง

ตรงกันข้าม Database กำลังแก้สถานการณ์ที่ Transactions รอกันแบบไม่มีวันจบ

⑥ Deadlock เกิดเฉพาะ Server คนเยอะไหม

ไม่

แม้มี Players ไม่มากก็เกิดได้ ถ้ามี Transaction สองชุด Lock Resources ในลำดับที่สวนกัน

⑦ แต่ Server คนเยอะมีโอกาสมากขึ้นไหม

เมื่อมี Concurrent Transactions จำนวนมาก โอกาสที่ Operations จะชนกันย่อมเพิ่มขึ้นในเชิงระบบ

แต่ต้องดู Query จริง ไม่ควรสรุปจากจำนวน Players อย่างเดียว

⑧ Error 1213 เป็น Connection Error ไหม

ไม่

Database Connection ทำงานจนถึงระดับ Transaction/Lock แล้วจึงตรวจ Deadlock ได้

⑨ เปลี่ยน MySQL Password ช่วยไหม

ไม่เกี่ยวกับ Deadlock

⑩ Clear FiveM Cache ช่วยไหม

โดยทั่วไปไม่ใช่ Fix เพราะ Lock เกิดใน Database Transaction ฝั่ง Server

⑪ Restart MariaDB ช่วยไหม

อาจทำให้ Locks ปัจจุบันหายเพราะ Connections ถูกตัด แต่ไม่ได้แก้ Query Pattern ที่สร้าง Deadlock

ถ้า Logic เดิมยังอยู่ Deadlock สามารถเกิดใหม่

⑫ Restart FiveM ช่วยไหม

เช่นเดียวกัน

อาจเคลียร์ Session ชั่วคราว แต่ไม่ได้แก้ Root Cause

⑬ ตัวอย่าง Deadlock แบบง่าย

Transaction A:


UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

จากนั้น:


UPDATE accounts
SET balance = balance + 100
WHERE id = 2;

⑭ Transaction B ทำกลับกัน


UPDATE accounts
SET balance = balance - 50
WHERE id = 2;

แล้ว:


UPDATE accounts
SET balance = balance + 50
WHERE id = 1;

⑮ ลำดับ Lock กลายเป็นสวนกัน


1 → 2


2 → 1

นี่คือ Pattern คลาสสิกที่สามารถนำไปสู่ Deadlock

⑯ FiveM Banking เจอได้ง่าย

เช่นผู้เล่นสองคนโอนเงินหากันพร้อมกัน

Transaction หนึ่ง Lock Account A ก่อน B

อีก Transaction Lock B ก่อน A

⑰ วิธีลดคือ Lock ตามลำดับเดียวกัน

เช่นกำหนดให้ทุก Transaction Process Account ID ที่น้อยกว่าก่อนเสมอ

แนวคิด:


min(accountA, accountB)
↓
max(accountA, accountB)

⑱ ทำไมช่วยได้

เพราะ Transactions ไม่วิ่งสวนลำดับกันง่าย ๆ

⑲ ไม่ใช่แค่ Banking

หลักนี้ใช้กับ:

Inventory Transfer
Vehicle Transfer
Business Transfer
Property Transfer

ได้เช่นกัน

⑳ Inventory Deadlock

ตัวอย่าง:

Player A ย้าย Item จาก Stash 1 → Stash 2

พร้อมกับ Player B ย้าย:


Stash 2 → Stash 1

ถ้า Database Lock Containers คนละลำดับ:

Deadlock มีโอกาสเกิด

㉑ Society Money

Job Script หนึ่งหักเงิน Society

อีก Script เพิ่มเงิน Society พร้อมกัน

ถ้า Transaction แตะ Tables/Rows หลายจุดต่างลำดับกันก็อาจชน

㉒ Billing

Invoice Payment อาจทำพร้อมกัน:

Update Invoice
Update Player Balance
Update Society Balance
Insert Transaction Log

㉓ ถ้า Resource อื่นทำลำดับกลับกัน

เช่น:

Society
Player
Invoice

Lock Order อาจสวนกัน

㉔ Vehicle Purchase

Transaction อาจประกอบด้วย:

Money
Vehicle Ownership
Dealer Stock
Transaction History

㉕ Housing Purchase ก็คล้ายกัน

Buyer Money
Property
Business/Society
Ownership

㉖ ยิ่ง Transaction แตะหลาย Rows

ยิ่งควรออกแบบ Lock Order ให้ชัด

㉗ Deadlock ไม่ได้หมายถึง Query หนึ่งผิด Syntax

SQL ทุก Statement อาจถูกต้อง

แต่เกิดปัญหาที่ ลำดับและเวลา

㉘ นี่ทำให้ Debug ยากกว่า Error 1064

1064 มักเห็น Syntax ผิดตรง Query

1213 ต้องดู Transactions หลายชุดพร้อมกัน

㉙ เครื่องมือสำคัญคืออะไร

MariaDB มี:


SHOW ENGINE INNODB STATUS;

ซึ่งแสดงข้อมูลสถานะของ InnoDB รวมถึงรายละเอียดเกี่ยวกับ Deadlocks.

㉚ ใช้ทำอะไร

หลังเกิด Deadlock สามารถตรวจ Section ที่เกี่ยวกับ:


LATEST DETECTED DEADLOCK

เพื่อหา:

Transactions
Queries
Locks

ที่เกี่ยวข้อง

㉛ FiveM Server Owner ควรใช้ไหม

ถ้าคุณมีสิทธิ์ Database และกำลัง Debug Deadlock:

มีประโยชน์มาก

㉜ แต่ข้อมูลอาจยาว

ให้เน้น:

Transaction
Table
Index
Query

㉝ อย่าโพสต์ Output ทั้งหมด Public ทันที

อาจมี:

Database Names
Query Data
Identifiers

ควร Mask ข้อมูลที่ไม่จำเป็น

㉞ MariaDB มี Counter Deadlock ไหม

MariaDB มี Status Variable Innodb_deadlocks สำหรับนับจำนวน InnoDB Deadlocks ใน Versions ที่รองรับ Variable นี้.

㉟ ใช้ดูแนวโน้มได้

ถ้า Counter เพิ่มเร็ว:

Deadlock ไม่ได้เป็นเหตุการณ์ครั้งเดียว

ควร Debug Resource

㊱ Deadlock หนึ่งครั้งร้ายแรงไหม

ระบบ Transactional Database สามารถพบ Deadlock ได้เป็นครั้งคราว

สิ่งสำคัญคือ Application ต้อง Handle และ Deadlock ไม่ควรเกิดถี่ผิดปกติ

㊲ Error Message บอกให้ Retry Transaction

MariaDB Error 1213 เองใช้ข้อความ:


try restarting transaction

㊳ แปลว่ากด Query ซ้ำได้เลยหรือไม่

ไม่ควรหมายความว่า Retry ทุกอย่างแบบไม่คิด

㊴ Transaction Retry ต้องออกแบบ

เพราะ Operation อาจเกี่ยวกับ:

Money
Item
Vehicle

ซึ่งต้องป้องกันการทำซ้ำ

㊵ ตัวอย่างอันตราย

ผู้เล่นซื้อรถ

ระบบ:

หักเงินสำเร็จ
Vehicle Insert Deadlock
Client Retry Purchase ทั้ง Flow

อาจมีผลแตกต่างกันตาม Transaction Design

㊶ ถ้า Operationทั้งหมดอยู่ใน Transactionเดียวอย่างถูกต้อง

Rollback สามารถช่วยให้ Stateกลับตาม Transaction Semantics

แต่ต้องตรวจ Resource Implementation

㊷ อย่าคิดว่า FiveM Resource ทุกตัวใช้ Transactionถูกต้อง

Third-party Scriptsต่างกันมาก

㊸ Retry ต้องเป็น Idempotent เมื่อทำได้

หมายถึง Retry Operationแล้วไม่ควรสร้างผลซ้ำโดยไม่ตั้งใจ

㊹ ตัวอย่าง

Transaction ID หรือ Purchase Referenceอาจช่วยระบุว่า Requestนี้เคยสำเร็จหรือยัง

ขึ้นกับ Architecture

㊺ อย่าสั่ง Player กดซื้อซ้ำทันที

ก่อนรู้ว่าครั้งแรก:

Commit
Rollback
Partial operation

อย่างไร

㊻ Deadlock Detection เปิดโดย Default

MariaDB ระบุ innodb_deadlock_detect ค่า Default เป็น 1; ถ้าปิด InnoDB จะอาศัย innodb_lock_wait_timeout แทนสำหรับ Waits ที่ไม่ถูก Deadlock Detector จัดการแบบเดิม.

㊼ ควรปิด Deadlock Detector ไหม

ไม่ควรทำเป็น First Fix สำหรับ FiveM Serverทั่วไป

㊽ เพราะอะไร

คุณยังไม่ได้แก้:

Query
Lock Order
Transaction Length

㊾ การปิด Detector เป็น Tuning ระดับ Database

เหมาะเมื่อเข้าใจ Workload และ Contention จริง

㊿ ไม่ใช่คำสั่งแก้ Console Errorแบบเร็ว ๆ

โดยเฉพาะ Production

51. Error 1213 กับ Error 1205 ต่างกันอย่างไร

MariaDB Error 1205 คือ:


Lock wait timeout exceeded;
try restarting transaction

ส่วน Error 1213 คือ Deadlock Detector พบวงจรการรอ.

52. จำง่าย ๆ


1213 = Deadlock
1205 = Wait นานเกิน Timeout

53. Deadlock อาจเกิดเร็ว

เพราะ Database ตรวจพบวงจร

ไม่จำเป็นต้องรอ Timeout หมดก่อน

54. Lock Wait Timeout อาจเกิดโดยไม่มี Deadlock

เช่น Transaction A ถือ Row Lockเป็นเวลานาน

Transaction B รอ A

แต่ Aไม่ได้รอ B

นี่ไม่ใช่วงจร

55. B จึงเพียงรอนานเกิน Timeout

แล้วอาจได้ 1205

56. Errorสองตัวนี้ควร Debugต่างกันเล็กน้อย

1213:

Lock Order
Circular Transactions

1205:

Long Transaction
Blocker
Timeout

57. แต่มีจุดร่วม

ทั้งสองเกี่ยวกับ:

Locks
Transactions
Concurrency

58. FiveM Player Save อาจ Deadlock

ตัวอย่าง Framework Saveพร้อมกันกับ Resourceอื่นที่ Update Player Row

59. Core Save

Update:

Money
Job
Metadata

60. Phone Resourceพร้อมกัน

Update:

Phone Account
Player Record

61. Garage Resourceพร้อมกัน

Update:

Player
Vehicle

ถ้าลำดับต่างกัน:

Deadlockอาจเกิด

62. Resource Ecosystemสำคัญ

ปัญหาอาจไม่ได้อยู่ Resourceเดียว

Resource AและBแต่ละตัวดูถูกเมื่อแยกกัน

แต่รวมกันแล้ว Lock Orderสวน

63. นี่คือเหตุผลที่ Deadlockเริ่มหลังติด Scriptใหม่ได้

แม้ Scriptเดิมทำงานมานาน

64. Errorหลังติด Bankingใหม่

ตรวจ Transactionที่แตะ Player Balanceร่วมกับ Core

65. Errorหลังติด Inventoryใหม่

ตรวจ:

Item Rows
Stashes
Player Rows

66. Errorหลังติด Garageใหม่

ตรวจ:

Vehicle
Player
Garage state

67. Errorหลังติด Business

ตรวจ Society/Employee/Player Balance

68. Errorหลังติด Housing

ตรวจ:

Property
Owner
Bank

69. Errorหลัง Update Framework

Core Save Orderอาจเปลี่ยน

ทำให้ Custom Resourcesเริ่มชนกัน

70. Errorหลังเปลี่ยน Database Wrapper

Transaction/Async Flowอาจเปลี่ยนได้

ต้องตรวจวิธีใช้ APIตาม Versionจริง

71. Await สำคัญ

ถ้า Resourceไม่รอ Queryที่ควรรอก่อนเริ่ม Operationถัดไป:

Concurrencyอาจเพิ่ม

72. แต่ Awaitทุกอย่างไม่ได้แก้ Deadlockอัตโนมัติ

ถ้ามีหลาย Connections/Transactionsลำดับสวนกันยังเกิดได้

73. Transaction ควรสั้น

ยิ่งถือ Locksนาน:

โอกาสที่ Transactionอื่นจะชนยิ่งมาก

74. สิ่งที่ไม่ควรอยู่ใน Transactionนาน ๆ

เช่นรอ:

External API
Discord Webhook
Player Input
Long computation

ในขณะที่ถือ Database Locks

75. ตัวอย่างไม่ดี


BEGIN
↓
UPDATE player
↓
รอ HTTP API
↓
UPDATE business
↓
COMMIT

Transactionถือ Lockระหว่างรอ Network

76. Better Concept

เตรียมข้อมูลที่ไม่ต้อง Lockก่อน

แล้วเปิด Transactionเฉพาะช่วง Database Changesที่จำเป็น

77. External Webhookควรอยู่หลัง Commitไหม

หลายระบบสามารถแยกออกจาก Critical Transactionได้

แต่ขึ้นกับ Business Requirement

78. Discord Logไม่ควรทำให้ Banking Lockนานโดยไม่จำเป็น

ในหลาย Architecture

79. Slow Queriesทำให้ Deadlockไหม

ไม่ได้เป็นสาเหตุเดียว

แต่ Queryช้าสามารถทำให้ Locksถูกถือไว้นานขึ้น

เพิ่มช่วงเวลาที่ Transactionsจะชนกัน

80. Index สำคัญ

UPDATE/DELETEที่หา Rowsไม่มี Indexที่เหมาะสมอาจแตะ Rowsมากเกินจำเป็น

จึงควรตรวจ Query Plan/Indexesเมื่อมี Lock Contention

81. อย่าเพิ่ม Indexทุก Columnแบบสุ่ม

Indexesมี Costด้าน:

Write
Storage

ต้องดู Queryจริง

82. WHERE Clauseควร Specific

ตัวอย่าง:


UPDATE accounts
SET balance = ...
WHERE id = ?;

โดย idเป็น Keyที่เหมาะสม

ดีกว่าการ Scanข้อมูลกว้างโดยไม่จำเป็น

83. UPDATEไม่มี WHEREอันตรายมากกว่า Deadlock

เพราะอาจ Lock/เปลี่ยน Rowsจำนวนมาก

84. อย่ารัน Bulk UPDATEกลาง Server Peak

โดยเฉพาะ Core Tables

85. Migrationสามารถสร้าง Lock Contentionได้

ALTER/UPDATEจำนวนมากระหว่าง Playersกำลัง Saveอาจรบกวน Production

86. Maintenance Windowเหมาะกว่า

สำหรับ Schema/Data Migrationใหญ่

87. Backupก่อน Migration

ยังคงเป็นกฎสำคัญ

88. Error Deadlockเฉพาะช่วง Restart

หลาย Resourcesอาจ:

Seed
Save
Cleanup

พร้อมกันตอน Start/Stop

89. Resource Stopอาจ Saveทุก Player

พร้อมกันกับ Framework Shutdown

เกิด Write Burstได้

90. Errorตอน Scheduled Restart

ควรดู Timestampของ Errorsว่าเกิดช่วง:

Player Save
Resource Stop
Backup

หรือไม่

91. Database Backupเองทำ Deadlockไหม

Backup Methodแต่ละแบบต่างกัน

ไม่ควรสรุปจาก Backupอย่างเดียว

ดู Locksจริง

92. Errorช่วง Server Peak

อาจเป็น Concurrencyเพิ่มขึ้น

แต่ต้องหา Queryคู่ที่ชน

93. Errorเฉพาะ Playerหนึ่ง

อาจ Operationsจำนวนมากพุ่งเข้า Rowเดียว

เช่น Account/Inventoryของ Playerนั้นถูก Updateจากหลาย Resources

94. Hot Row คืออะไร

Rowที่ Transactionsจำนวนมากพยายามอ่าน/เขียนพร้อมกัน

95. Society Accountเป็นตัวอย่าง Hot Row

Playersหลายคนทำ Transactionsกับ Societyเดียวกัน

96. Business Balanceก็เช่นกัน

ทุก Sale Update:


business balance

Rowเดียว

97. High Contentionไม่จำเป็นต้อง Deadlock

อาจเพียง Queueรอ Lock

แต่เมื่อแตะหลาย Locksสวนลำดับกัน Deadlockเกิดง่ายขึ้น

98. Counter/Balance Updateควร Atomic

เช่นแนวคิด:


UPDATE accounts
SET balance = balance + ?
WHERE id = ?;

แทน:

SELECT balance
คำนวณใน Client
UPDATE value

ในหลายสถานการณ์

99. แต่ Banking Logicซับซ้อนกว่านั้น

ต้องตรวจ:

Balance sufficient
Transaction integrity

อย่า Copy Queryง่าย ๆไปแทน Framework

100. `SELECT ... FOR UPDATE`

Resourceที่ทำ Transactionอาจใช้ Row Locksแบบ Explicit

มีประโยชน์เมื่อออกแบบถูก

แต่สามารถเพิ่ม Lock Contentionหากใช้กว้างเกินไป

101. อย่าเพิ่ม FOR UPDATEทุก SELECT

ไม่ใช่ Deadlock Fixสากล

102. Lockเฉพาะ Rowsที่จำเป็น

ช่วยลด Contention

103. ล็อกตามลำดับเดียวกัน

เป็นหนึ่งในหลักออกแบบสำคัญที่สุดสำหรับลด Deadlock

104. Banking Example

ถ้าต้อง Lockสอง Accounts:

จัด IDsก่อน


10
20

ทุก Transaction Lock:


10 → 20

ไม่ว่าโอนทิศไหน

105. Inventory Example

ถ้าต้อง Lockสอง Containers:

เลือก Orderที่ Deterministic

เช่น Container ID

106. Vehicle Transfer

Lock:

Seller
Buyer
Vehicle

ตาม Sequenceมาตรฐานเดียวกันทุก Path

107. Business Purchase

อย่าให้:

Operation A:


player → business

แต่ Operation B:


business → player

ถ้าทั้งคู่ใช้ Locksเดียวกันใน Transaction

108. Deadlockหลังเพิ่ม Refund Flow

Purchase FlowกับRefund Flowอาจใช้ Tablesเดียวกันแต่ลำดับกลับกัน

109. เป็น Patternที่ควรค้น

หา Operationsที่เป็นคู่ตรงข้าม:

Deposit / Withdraw
Buy / Refund
Give / Take
Add / Remove

110. Deposit/Withdraw

Deposit:


player → bank

Withdraw:


bank → player

ถ้า Lock Orderตาม Direction:

เกิด Deadlock Patternได้

111. Solution Concept

กำหนด Lock Orderจาก Record Identity

ไม่ใช่จาก Directionของ Transaction

112. Errorหลัง Player Spamปุ่ม

Double-submitสามารถสร้าง Concurrent Operationsของ Playerเดียวกัน

113. UIควร Disableปุ่มหลัง Submitไหม

ช่วยด้าน UX

แต่ Serverต้องป้องกัน Duplicate/Concurrent Requestsเองด้วย

114. Client Protectionอย่างเดียวไม่พอ

เพราะ Requestอาจมาจาก:

Lag retry
Resource callbacks
Malicious client

115. Server-side Mutexใช้ได้ไหม

Application-level lockingอาจช่วยบาง Flow

แต่เพิ่ม Complexityและอาจสร้าง Deadlockอีกชั้นหากออกแบบไม่ดี

116. อย่าเพิ่ม Locksสองระบบแบบสุ่ม

เช่น:

Lua Mutex
Database Locks

โดยไม่มี Order Policy

117. GET_LOCK()มีไหม

MariaDBมี Advisory Lock Function GET_LOCK() และเอกสารแสดงว่าการใช้ Named Locksเองก็สามารถเกิด Error1213จาก Deadlockได้.

118. จึงไม่ใช่ Magic Fix

เพิ่ม Advisory Lockผิดวิธีสามารถสร้าง Deadlockเพิ่มเติม

119. ใช้เฉพาะเมื่อเข้าใจ Semantics

สำหรับ Custom Developer

120. Server Ownerทั่วไปควรเริ่มจาก Queryก่อน

ไม่ใช่ GET_LOCK

121. SHOW ENGINE INNODB STATUSสำคัญอีกครั้ง

ใช้:


SHOW ENGINE INNODB STATUS;

MariaDBระบุว่าคำสั่งนี้แสดงรายละเอียด Deadlocksและสถานะ InnoDBอื่น ๆ.

122. ดู Queryสองฝั่ง

Deadlock Reportมักช่วยให้รู้ว่า:

Transactionหนึ่งถืออะไร
กำลังรออะไร
อีก Transactionถืออะไร

123. จากนั้นหา Resource

Search Queryหรือ Tableใน FiveM Resources

124. Queryบางครั้งมาจาก Core

อีก Queryจาก Third-party Script

125. แก้ Resourceไหน

อาจต้องแก้ทั้งสองให้ใช้ Lock Orderเดียวกัน

126. อย่าโทษ Queryที่ถูก Rollbackอย่างเดียว

Databaseเลือก Victim Transactionหนึ่ง

ไม่ได้แปลว่า Transactionนั้นเป็นผู้สร้างปัญหาเพียงฝ่ายเดียว

127. Deadlockเป็น Interaction

ต้องดูทั้งวงจร

128. Transaction Victimคืออะไร

หนึ่ง Transactionถูกยกเลิกเพื่อคลายวงจร

อีก Transactionสามารถเดินต่อ

129. ดังนั้น Errorอาจขึ้น Resource A

แต่ Resource Bก็เป็นส่วนหนึ่งของ Deadlock

130. นี่เป็นข้อผิดพลาดที่คน Debugพลาดบ่อย

เห็น Stackของ Aแล้วแก้ Aอย่างเดียว

131. ตรวจ Deadlock Report

จะเห็นอีก Transactionที่เกี่ยว

132. Error1213เกิดสุ่มทำไม

เพราะ Timingของ Concurrent Requestsเปลี่ยนตลอด

133. Resourceเหมือนเดิม

แต่เฉพาะบางจังหวะ Transactionsเข้าพร้อมกันพอดี

134. Reproduceยาก

ใช้ Load Test/Test Serverช่วยได้สำหรับ Developer

135. ไม่ควร Load Test Production

โดยเฉพาะ Banking/Inventory

136. Staging Databaseควร Schemaเหมือน Production

เพราะ:

Indexes
Constraints

มีผลกับ Locking

137. Data Volumeก็มีผล

Queryที่เร็วใน Empty Databaseอาจช้าใน Production

138. Testด้วยข้อมูลที่ใกล้ Production

แต่ต้องปกป้อง Player Data

139. Error1213หลัง Databaseโต

Resourceเดิมไม่เคย Deadlockตอน Tableเล็ก

เมื่อ Dataโต Queryใช้เวลานานขึ้น

Locksอาจอยู่นานขึ้น

140. Optimize Queryจึงอาจช่วย

แต่ต้องวัดก่อน

141. Slow Query Logมีประโยชน์ไหม

สำหรับ Query Performanceสามารถมีประโยชน์

แต่ Deadlock Debugควรเริ่มจาก InnoDB Deadlock Reportด้วย

142. Indexขาดอาจเป็นต้นเหตุทางอ้อม

ถ้า UPDATEค้น Rowช้า

143. ตรวจ EXPLAINอย่างระวัง

SELECTสามารถ Explainได้ง่ายกว่า Mutation

MariaDBมี Toolsด้าน Query Planแต่บทความนี้เน้น Deadlock

144. อย่าเพิ่ม Indexจาก Guess

ใช้ Query/Schemaจริง

145. Transactionsใหญ่เป็นปัญหา

ตัวอย่าง Save Player Transactionหนึ่งทำ:

Inventory 200 rows
Metadata
Banking
Vehicles

ทั้งหมดใน Transactionเดียว

146. แยก Transactionได้ไหม

ขึ้นกับ Atomicity Requirement

147. ถ้าข้อมูลต้อง Commitพร้อมกัน

แยกผิดอาจทำ Dataไม่สอดคล้องกัน

148. ต้อง Balance

Transactionสั้น
Atomicityครบ

149. Developerต้องออกแบบ

ไม่ใช่ Server Ownerแก้ด้วย Configสุ่ม

150. Batch Updates

Update Rowsจำนวนมากใน Transactionเดียวสามารถถือ Locksจำนวนมาก

151. Chunkingช่วยได้ไหม

บาง Background Operationsสามารถแบ่ง Batchได้

แต่ต้องไม่ทำลาย Consistency

152. ไม่ควร Chunk Banking Transaction

ถ้าต้อง Atomic

153. Data Cleanupต่างจาก Player Transaction

Batch Processingอาจแบ่งได้ง่ายกว่า

154. Errorตอน Cron/Cleanup Resource

เช่น Resourceลบ Logsพร้อม Gameplayกำลัง Insert/Update Tablesเดียวกัน

155. Cleanup Queryควรรัน Off-peak

ถ้าแตะ Dataจำนวนมาก

156. Logsควรมี Retention Plan

ไม่ใช่ DELETEหลายล้าน Rowsกลาง Peak

157. Archivingอาจช่วยในระบบใหญ่

แต่เป็น Database Architecture Topicที่ต้องวางแผน

158. Error1205อาจตามมา

หาก Lock Contentionสูงแต่ไม่ได้形成วงจร

Transactionอื่นอาจรอนานจน Timeout.

159. DeadlockกับLock Waitจึงควรดูร่วมกัน

ถ้าเห็นทั้ง:


1213
1205

บ่อย ๆ

Databaseมี Lock Contentionที่ควรตรวจจริงจัง

160. เพิ่ม `innodb_lock_wait_timeout` แก้ Deadlockไหม

ไม่

Deadlock1213ถูก Detectเป็นวงจร

เพิ่ม Timeoutไม่ได้แก้ Lock Order

161. เพิ่ม Timeoutอาจเพียงทำ Waitอื่นนานขึ้น

จึงไม่ใช่ First Fixของ1213

162. ลด Timeoutช่วยไหม

ก็ไม่ได้แก้ Deadlock Pattern

163. อย่าปรับ Global Database Variablesก่อนหา Query

เพราะอาจกระทบทุก Resource

164. Hosting Shared Database

หากไม่มีสิทธิ์ดู InnoDB Statusครบ:

ใช้:

FiveM Error Logs
Query/Resource Stack
Hosting Support

ช่วย

165. Pterodactyl/Panelไม่ใช่ Root Causeโดยตรง

Panelเป็นเพียง Environmentบริหาร Server

Deadlockเกิดใน Database Transactions

166. Error1213เกิดใน localhostได้ไหม

ได้

ไม่ต้องเป็น Remote Database

167. Network Latencyทำ Deadlockโดยตรงไหม

ไม่ใช่เงื่อนไขหลัก

Deadlockคือ Lock Dependencyใน Database

168. แต่ Applicationที่ถือ Transactionขณะรอ Networkภายนอก

สามารถทำให้ Transactionยาวขึ้นได้

นั่นเป็นคนละเรื่อง

169. Error1213กับForeign Keyเกี่ยวไหม

Foreign Key ChecksและRelated Updatesสามารถมี Locksได้

แต่เห็น1213ไม่ได้แปลว่า Foreign Keyคือ Root Causeเสมอไป

170. Errorหลังเพิ่ม Foreign Key

Workload/Locking Patternอาจเปลี่ยน

ควรดู Deadlock Reportจริง

171. Errorหลังเปลี่ยน Storage Engine

FiveM modern relational schemasมักพึ่ง InnoDBเพื่อ Transaction/Foreign Key Features; MariaDBระบุ InnoDBเป็น Default Storage Engineและรองรับ Transaction-safe capabilities.

172. อย่าเปลี่ยน InnoDB→MyISAMเพื่อหนี Deadlock

จะเสีย Transaction/Foreign Key capabilitiesที่ Resourceอาจพึ่ง

และไม่ใช่ Fixที่เหมาะสม

173. Deadlock Prevention Checklist

Transactionสั้น
Lock Rowsเท่าที่จำเป็น
ใช้ Lock Orderเดียวกัน
มี Indexเหมาะกับ Query
หลีกเลี่ยง External Waitใน Transaction
Retryอย่างปลอดภัย

174. FiveM Banking Checklist

Sender/Receiver Order
Balance Update
Transaction Log
Retry Protection
Double-submit

175. Inventory Checklist

Source Container
Destination Container
Item Row
Lock Order
Quantity Validation

176. Garage Checklist

Vehicle
Owner
Garage
Finance
State Update

177. Business Checklist

Player Account
Business Account
Invoice
Employee/Stock

178. Character Save Checklist

Player Row
Metadata
Inventory
Position
Concurrent resource writes

179. Error1213เฉพาะ Server Restart

ตรวจ:

Mass Save
Resource Stop
Cleanup
Startup migrations

180. Error1213เฉพาะ Payday

Payday Resourceอาจ Update Playersจำนวนมากและ Society Accountsพร้อมกัน

181. Error1213เฉพาะ Auto Save

Core Auto-saveอาจชน Inventory/Garage Save

182. Error1213เฉพาะซื้อขาย

ดู Transaction Flowของ Featureนั้น

183. Error1213เฉพาะบาง Business

Businessนั้นอาจเป็น Hot Rowเพราะมี Transactionsสูง

184. Error1213เฉพาะ Playerเดียว

Playerอาจ Triggerสอง Operationsพร้อมกัน

185. Double-click ซื้อของ

ควรป้องกันทั้ง:

UI
Server

186. Retry Limit

Applicationไม่ควร Retry Deadlockแบบ Infinite Loop

187. ทำไม

หาก Root Causeยังอยู่:

Retryไม่รู้จบสร้าง Loadเพิ่ม

188. แนวทางทั่วไป

Retryจำนวนจำกัดพร้อม Backoffสามารถเป็น Patternสำหรับ Transaction Deadlocks

แต่ค่าจริงควรออกแบบตาม Resource/Application

189. Backoffคืออะไร

รอช่วงสั้น ๆก่อน Retryเพื่อไม่ให้ Transactionsกลับมาชนจังหวะเดิมทันที

190. อย่ากำหนด Waitหลายวินาทีแบบสุ่ม

นี่คือ Application Design

191. Error1213 FAQ

FiveM `Deadlock found when trying to get lock` คืออะไร

MariaDB Error1213 / SQLSTATE40001 / ER_LOCK_DEADLOCK หมายถึง Databaseตรวจพบ Transactionsที่รอ Locksของกันเป็นวงจรและต้องยุติ Transactionหนึ่ง.

Deadlockแปลว่า Databaseพังไหม

ไม่ InnoDBสามารถตรวจ Deadlockและคืน Errorเพื่อคลายวงจรได้.

Restart MariaDBช่วยไหม

อาจเคลียร์สถานการณ์ปัจจุบัน แต่ไม่แก้ Query/Transaction Patternที่ทำ Deadlock

Restart FiveMช่วยไหม

เช่นเดียวกัน ไม่ใช่ Root Cause Fix

Clear FiveM Cacheช่วยไหม

โดยทั่วไปไม่เกี่ยวกับ Database Lock Order

Error1213กับ1205ต่างกันอย่างไร

1213คือ Deadlock ส่วน1205คือรอ Lockเกิน Timeout.

ดู Deadlockได้อย่างไร

MariaDBมี:


SHOW ENGINE INNODB STATUS;

ซึ่งแสดงรายละเอียด Deadlocksของ InnoDB.

ควร Retry Transactionไหม

Error Messageเองแนะนำให้ Restart Transaction แต่ Applicationควร Retryอย่างปลอดภัยและป้องกันผลซ้ำ.

Retryไม่จำกัดได้ไหม

ไม่ควร เพราะถ้า Contentionยังอยู่จะสร้าง Loadเพิ่ม

ปิด Deadlock Detectorดีไหม

ไม่ควรเป็น First Fix; MariaDBระบุ Detectorเปิดโดย Defaultและหากปิดจะอาศัย Lock Wait Timeoutแทน.

เพิ่ม `innodb_lock_wait_timeout` ช่วย1213ไหม

ไม่ใช่ Root Fixของ Deadlock เพราะ1213คือวงจร Lockที่ตรวจพบ ไม่ใช่เพียง Waitนาน

Bankingทำ Deadlockได้ไหม

ได้ถ้า Concurrent Transactionsแตะ Accountsหลาย Rowsในลำดับสวนกัน

Inventoryทำ Deadlockได้ไหม

ได้ โดยเฉพาะ Transfersระหว่าง Containersที่ Locksถูกจับต่างลำดับ

Garageทำ Deadlockได้ไหม

ได้หาก Operationsแตะ Vehicle, OwnerหรือRelated Tablesพร้อมกันใน Transactionsที่ Orderต่างกัน

Character Saveทำ Deadlockได้ไหม

ได้ถ้า CoreและThird-party Resources Updateข้อมูลเดียวกันพร้อมกันและเกิด Lock Dependency

Deadlockเกิดเฉพาะคนเยอะไหม

ไม่ แต่ High Concurrencyสามารถเพิ่มโอกาสให้ Transactionsชนกัน

Queryช้าทำ Deadlockไหม

ไม่ใช่สาเหตุเดียว แต่ Transactionที่ใช้เวลานานจะถือ Locksนานขึ้นและเพิ่มช่วงเวลา Contention

Indexช่วยไหม

Indexที่เหมาะสมสามารถช่วยให้ Queryแตะ Rowsที่จำเป็นได้มีประสิทธิภาพขึ้น แต่ต้องตรวจ Queryจริงก่อนเพิ่ม Index

ใช้ `GET_LOCK()`แก้ได้ไหม

ไม่ใช่ Fixทั่วไป และ MariaDB documentationมีตัวอย่างที่ Named Locksเองสามารถเกิด Error1213ได้.

เปลี่ยน InnoDBเป็น MyISAMช่วยไหม

ไม่ควร เพราะ InnoDBเป็น Transaction-safe Storage Engineและรองรับ Foreign Keys; Resourceอาจพึ่งความสามารถเหล่านี้.

Errorเกิดหลัง Update Resourceทำอย่างไร

ตรวจ:

Transaction Flow
Query Order
New Tables
Resource Compatibility

Errorเกิดหลัง Framework Updateทำอย่างไร

ตรวจ Core Save Flowและ Third-party Resourcesที่เขียน Rowsเดียวกัน

Errorเกิดหลังเปลี่ยน Database Wrapperทำอย่างไร

ตรวจ Transaction API, Await/Async Handlingและ Return Valuesตาม Versionที่ใช้

Errorเกิดตอน Paydayทำอย่างไร

ดูว่ามี Bulk Updatesและ Society/Player Accountsถูกแตะพร้อมกันหรือไม่

Errorเกิดตอน Auto Saveทำอย่างไร

ตรวจ Core Saveกับ Inventory/Garage/Phone Resourcesที่อาจ Saveพร้อมกัน

Errorเกิดเฉพาะ Playerเดียว

ตรวจว่ามี Requests/Resourcesหลายตัว Update Rowของ Playerนั้นพร้อมกันหรือไม่

Errorเกิดทุกคน

ตรวจ Global Save/Payday/Cleanup Processและ Core Queries

ต้อง Backupไหม

หากจะแก้ Schema, Indexesหรือ Transaction-related Data Migrationบน Production ควร Backupก่อน

Deadlock Reportบอก Resource Nameไหม

Database Reportเน้น Transactions/Queries/Tables ส่วน FiveM Console/Stackช่วย Map Queryกลับไปยัง Resource

Queryที่ Errorคือ Queryผิดแน่นอนไหม

ไม่ Deadlockเกิดจาก Interactionของอย่างน้อยสอง Transactions Queryที่ถูก Rollbackเป็นเพียง Transactionที่ Databaseเลือกยุติ

สรุป FiveM MySQL Deadlock Error 1213

FiveM MySQL/MariaDB Error 1213 Deadlock found when trying to get lock; try restarting transaction เกิดเมื่อ Transactions หลายชุดรอ Locks ของกันและกันจนเป็นวงจร InnoDB จึงต้องยุติ Transaction หนึ่งเพื่อคลาย Deadlock โดย MariaDBกำหนด Errorนี้เป็น ER_LOCK_DEADLOCK และ SQLSTATE 40001.

วิธีวิเคราะห์ที่ควรจำ:


1213
↓
SHOW ENGINE INNODB STATUS
↓
หา Transactions ที่ชน
↓
ดู Tables / Rows / Queries
↓
หา FiveM Resources ต้นทาง
↓
ตรวจ Lock Order
↓
ลด Transaction Length
↓
Retry อย่างปลอดภัย

สิ่งที่ comsiam แนะนำคืออย่าแก้ Deadlockด้วยการเพิ่ม Timeout, Restart Databaseหรือปิด Deadlock Detectorทันที เพราะปัญหาหลักมักอยู่ที่ Transactionsแตะข้อมูลเดียวกันในลำดับสวนกันหรือถือ Locksนานเกินจำเป็น ให้ใช้ SHOW ENGINE INNODB STATUS ตรวจ Deadlockจริงก่อน แล้วหา Resourceทั้งสองฝั่งที่เกี่ยวข้อง ไม่ใช่ดูเฉพาะ Queryที่ถูก Rollback.

อีกหลักที่ comsiam แนะนำคือสำหรับระบบสำคัญอย่าง Banking, Inventory, Garageและ Business ให้กำหนดลำดับการ Lock/Update Recordsให้เหมือนกันทุก Transaction ทำ Transactionให้สั้น และออกแบบ Retryให้ไม่สร้างเงิน Itemsหรือ Assetsซ้ำ เมื่อแก้ที่ Transaction Designแทนการซ่อน Error จะลดทั้ง Deadlockและความเสี่ยง Data Integrityในระยะยาว