FiveM MySQL Lock Wait Timeout Exceeded Error 1205 แก้อย่างไร? หา Query ที่ล็อก Database และแก้ Transaction ค้างให้ถูกจุด

August 17, 2026

ปัญหา FiveM MySQL/MariaDB Error 1205: Lock wait timeout exceeded; try restarting transaction เกิดเมื่อ Query หรือ Transaction ต้องการ Lock บนข้อมูล แต่มี Transaction อื่นถือ Lock นั้นอยู่นานเกินเวลาที่ Database กำหนด จึงยกเลิก Statement ที่กำลังรอและคืน Error 1205 ออกมา.

ตัวอย่าง:


ERROR 1205 (HY000):
Lock wait timeout exceeded;
try restarting transaction

หรือใน FiveM Console อาจเห็น:


ER_LOCK_WAIT_TIMEOUT


Lock wait timeout exceeded


Transaction failed

ปัญหานี้มักเกี่ยวข้องกับระบบที่เขียนข้อมูลพร้อมกัน เช่น:

Banking
Inventory
Garage
Vehicle Ownership
Business
Billing
Housing
Character Save
Society Money
Transactions
Auto Save
Resource Migration

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

หา Query ที่กำลังรอ → หา Transaction ที่ถือ Lock → ตรวจว่าทำไม Transaction นั้นค้างนาน → ลดเวลา Transaction → เพิ่ม Index/ปรับ Queryเมื่อจำเป็น → Retry อย่างปลอดภัย

① Error 1205 คืออะไร

MariaDB ระบุ Error 1205 ว่า:


Lock wait timeout exceeded;
try restarting transaction

โดยตรง.

② Error นี้ต่างจาก Deadlock 1213

หัวข้อก่อนหน้า:

Error 1213

Transactions รอ Lock ของกันและกันเป็นวงจร

Error 1205

Transaction หนึ่งกำลังรอ Lock แต่รอนานเกิน Timeout ที่กำหนด

MariaDB แยก Error 1205 และ 1213 เป็นคนละ Error Code.

③ ตัวอย่างง่ายที่สุด

Session A:


START TRANSACTION;

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

แต่ยังไม่:


COMMIT;

④ Session B พยายามแก้ Row เดียวกัน


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

Session B ต้องรอ Lock จาก Session A

⑤ ถ้ารอนานเกินกำหนด

MariaDB สามารถคืน:


ERROR 1205 (HY000)
Lock wait timeout exceeded

โดย innodb_lock_wait_timeout ใช้กำหนดเวลาที่ InnoDB Transaction รอ Record Lock หรือ Table Lock ก่อนยอมแพ้.

⑥ `innodb_lock_wait_timeout` คืออะไร

เป็น System Variable ของ InnoDB ที่กำหนดจำนวนวินาทีที่ Transaction จะรอ Lock ก่อนเกิด Error 1205.

⑦ ควรเพิ่ม Timeout ทันทีไหม

ไม่ควรเป็นวิธีแรก

เพราะถ้า Transaction หนึ่งถือ Lock นานผิดปกติ การเพิ่ม Timeout เพียงทำให้ Query อื่น:

รอนานกว่าเดิม

ไม่ได้แก้ต้นเหตุ

⑧ ตัวอย่าง

ปัจจุบัน Query รอจน Error

คุณเพิ่ม Timeout หลายเท่า

ผลอาจกลายเป็น:


Player กดซื้อรถ
↓
Database รอ
↓
FiveM Callback ค้างนานกว่าเดิม
↓
Player กดซ้ำ

ซึ่งอาจเพิ่ม Load และความซับซ้อน

⑨ Error 1205 เป็น Connection Error ไหม

ไม่ใช่

Query เชื่อมถึง MariaDB แล้วและกำลังแข่งขันเพื่อ Lock ภายใน Database.

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

ไม่

⑪ เปลี่ยน Port ช่วยไหม

ไม่

⑫ Clear FiveM Cache ช่วยไหม

โดยทั่วไปไม่ใช่ Fix เพราะปัญหาเกิดจาก Server-side Database Lock

⑬ Restart MariaDB ช่วยไหม

อาจทำให้ Connections/Transactions ปัจจุบันถูกตัดและ Lock หาย

แต่เป็นเพียงการแก้ชั่วคราว

ถ้า Resource ยังสร้าง Transaction ค้างแบบเดิม:

Error จะกลับมา

⑭ Restart FiveM ช่วยไหม

คล้ายกัน

อาจทำให้ Database Connections ถูกปิด

แต่ไม่ได้แก้ Query Design

⑮ FiveM Banking เจอ 1205 ได้อย่างไร

สมมติ Transaction หนึ่งกำลัง Update:


player account

และถือ Row Lock อยู่

Transaction อื่นพยายาม Update Account เดียวกัน

จึงต้องรอ

⑯ Society Account เป็น Hot Row

ถ้า Players จำนวนมากซื้อของจาก Business เดียวกัน:

ทุก Transaction อาจ Update:


society balance

Record เดียว

⑰ Result

Transactions จำนวนมากอาจต่อคิวรอ Row เดียว

⑱ Inventory ก็เกิดได้

เช่น Player สอง Operations พยายามแก้:

Stash เดียวกัน
Inventory เดียวกัน
Item Row เดียวกัน

พร้อมกัน

⑲ Garage

เช่น:

Store Vehicle
Transfer Vehicle
Impound Vehicle

กำลัง Update Vehicle Record เดียวกัน

⑳ Character Save

Framework อาจ Save:

Job
Money
Position
Metadata

ขณะ Resource อื่น Update Player Row เดียวกัน

㉑ Error1205เฉพาะช่วง Auto Save

เป็นเบาะแสสำคัญ

Core Auto Saveอาจกำลัง Lock Player Recordsจำนวนมาก

㉒ Errorเฉพาะ Payday

Paydayอาจ Update:

Players
Jobs
Society Accounts

พร้อมกับ Transactionsปกติ

㉓ Errorช่วง Server Restart

Resourcesหลายตัวอาจ Saveพร้อมกันตอน:

Stop
Restart
Shutdown

ทำให้ Write Burstเกิดขึ้น

㉔ Lock Waitไม่ได้หมายถึง Queryที่ Errorเป็นตัวร้าย

Queryที่ขึ้น Errorอาจเป็นเพียง:

ผู้ที่กำลังรอ

ต้นเหตุจริงอาจเป็น Transactionอีกชุดที่ถือ Lockอยู่

㉕ นี่คือจุดสำคัญที่สุด

อย่าดูแค่:


Query that failed

ต้องหา:


blocking transaction

ด้วย

㉖ จะดูว่าใครกำลังทำงานอยู่ได้อย่างไร

MariaDB มี:


SHOW PROCESSLIST;

เพื่อแสดง Threads/Connections ที่กำลังทำงานอยู่.

㉗ ดูอะไรใน PROCESSLIST

สนใจ:

Id
User
Time
State
Info

โดยเฉพาะ Query ที่ทำงานนานผิดปกติ

㉘ `SHOW FULL PROCESSLIST`

สามารถช่วยให้เห็น Query Text ได้ละเอียดขึ้นตามสิทธิ์ของ User

㉙ State ที่เกี่ยวกับ Lock

MariaDB มี Thread States ที่สามารถแสดงการรอ Lock เช่นสถานะประเภท Waiting for ... lock.

㉚ แต่ Processlist อย่างเดียวอาจไม่พอ

สำหรับ InnoDB Transactions ใช้:


INFORMATION_SCHEMA.INNODB_TRX

ช่วยดู Transaction ที่กำลังทำงานอยู่ได้

㉛ `INNODB_TRX` คืออะไร

MariaDB ระบุว่า Table นี้เก็บข้อมูลของ InnoDB Transactions ที่กำลังทำงาน รวมถึง:

Transaction state
Start time
Lock information

และ State อาจเป็น:


RUNNING
LOCK WAIT
ROLLING BACK
COMMITTING

㉜ ถ้าเห็น `LOCK WAIT`

นั่นคือ Transaction กำลังรอ Lock อยู่

㉝ ดู Transaction Start Time

Transaction ที่เริ่มมานานผิดปกติควรถูกตรวจ

เพราะอาจกำลังถือ Locks นาน

㉞ `INNODB_LOCKS`

MariaDB ยังมี Information Schema INNODB_LOCKS สำหรับดู Locks ที่ Transaction ขอแต่ยังไม่ได้ หรือ Locks ที่กำลัง Block Transaction อื่น.

㉟ ใช้ร่วมกันได้

แนวคิดคือ:


INNODB_TRX
↓
Transaction ไหนรอ
↓
INNODB_LOCKS
↓
Lock ไหนเกี่ยว
↓
PROCESSLIST
↓
Query/Connection ไหน

㊱ `SHOW ENGINE INNODB STATUS`

ก็ยังมีประโยชน์


SHOW ENGINE INNODB STATUS;

MariaDB ระบุว่าคำสั่งนี้แสดงข้อมูลสถานะ InnoDB รวมถึง Deadlocks, Buffer Pool และ I/O.

㊲ สำหรับ 1205 ใช้อะไรดีที่สุด

เริ่มจาก:


SHOW PROCESSLIST
INNODB_TRX
INNODB_LOCKS

เพื่อหา Blocking Transaction

แล้วใช้ InnoDB Statusประกอบ

㊳ Transaction ค้างนานเกิดจากอะไร

ตัวอย่าง:

Code ลืม COMMIT
Code ลืม ROLLBACK
Query ช้า
Transaction ใหญ่
Resource รอ External API
Connection ถูกปล่อย Idle ขณะ Transactionยังเปิด

㊴ ลืม COMMIT เป็น Case สำคัญ

ตัวอย่าง:


START TRANSACTION;

UPDATE players
SET money = money - 1000
WHERE id = 10;

แต่ไม่มี:


COMMIT;

Transactionอาจถือ Lockต่อ

㊵ หรือไม่มี ROLLBACK เมื่อเกิด Error

Application Flow:


BEGIN
↓
UPDATE
↓
เกิด Lua/JS Error
↓
Functionหยุด
↓
ไม่มี COMMIT/ROLLBACK

นี่เป็น Bugที่ต้องแก้ใน Resource

㊶ Transaction ควรสั้น

อย่าถือ Database Locksขณะรอ:

HTTP Request
Discord Webhook
Player Input
External API

โดยไม่จำเป็น

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


START TRANSACTION
↓
UPDATE balance
↓
ส่ง Discord webhook
↓
รอ response
↓
UPDATE transaction
↓
COMMIT

㊸ ทำไมไม่ดี

Network Responseอาจใช้เวลานาน

แต่ Database Lockยังถูกถืออยู่

㊹ หลักที่ดีกว่า

ทำ Critical Database Workให้เสร็จใน Transactionสั้นที่สุดเท่าที่ Business Logicอนุญาต

㊺ Query ช้าทำ 1205 ได้ไหม

ทางอ้อมได้

Queryที่ช้าสามารถถือ Locksนานขึ้น

ทำให้ Queryอื่นมีโอกาสรอเกิน Timeout

㊻ Index มีผลอย่างไร

Queryที่มี Indexเหมาะสมสามารถค้นหา Rowsเป้าหมายได้มีประสิทธิภาพกว่า Queryที่ต้อง Scanข้อมูลจำนวนมาก

แต่ไม่ควรเพิ่ม Indexแบบสุ่ม

㊼ ตัวอย่าง UPDATE


UPDATE players
SET money = ?
WHERE id = ?;

ถ้า idเป็น Keyที่เหมาะสม:

Scopeชัดกว่าการ Updateด้วย Conditionกว้าง

㊽ UPDATE จำนวนมาก

ตัวอย่าง:


UPDATE players
SET some_state = 0;

โดยไม่มี WHERE

อาจแตะ Rowsจำนวนมาก

㊾ นอกจาก Data Risk

ยังสามารถถือ Locksจำนวนมาก

㊿ อย่าทำ Bulk Updateช่วง Peak

หากสามารถทำ Maintenanceได้

51. FiveM Database Migration

Migrationที่ใช้:

UPDATEหลายล้าน Rows
ALTER TABLE

สามารถ Block Operationsอื่นได้

52. Metadata Locks คืออีกเรื่องหนึ่งที่ต้องรู้

MariaDBมี Metadata Locking สำหรับป้องกัน Object Definitionจากถูกเปลี่ยนขณะ Transactionยังใช้งาน Tableอยู่ และกรณีรอ Metadata Lockนานเกินก็สามารถคืน Error1205ได้เช่นกัน.

53. ดังนั้น 1205 ไม่ได้หมายถึง Row Lock เสมอไป

อาจเป็น:

InnoDB Record Lock
Table Lock
Metadata Lock

ขึ้นกับ Operation.

54. ตัวอย่าง Metadata Lock

Transactionหนึ่งใช้งาน Tableอยู่

Adminพยายาม:


ALTER TABLE players ...

ALTERอาจต้องรอ Metadata Lock

55. ถ้ารอนานเกิน

สามารถเกิด Error1205ได้ตาม Metadata Lock Timeout.

56. อย่าทำ ALTER Core Tableช่วงคนเล่น

โดยเฉพาะ:

players
inventory
vehicles
transactions

57. Maintenance Windowดีกว่า

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

58. `lock_wait_timeout`

Metadata Locksมี lock_wait_timeout ที่เกี่ยวข้อง และ MariaDBระบุ Defaultที่ยาวมากสำหรับ Variableนี้.

59. อย่าสับสนกับ `innodb_lock_wait_timeout`

`innodb_lock_wait_timeout`

เกี่ยวกับ InnoDB Record/Table Locks.

`lock_wait_timeout`

เกี่ยวกับ Metadata Lock Waitingในบริบทที่เกี่ยวข้อง.

60. Error Codeเหมือนกันได้

จึงต้องดู Operationและ Transactionจริง

61. ถ้า Errorเกิดตอน ALTER TABLE

สงสัย Metadata Lockก่อน

62. ถ้า Errorเกิดตอน UPDATE Banking

สงสัย Row/Record Lockมากกว่า

63. Errorตอน Import SQL

อาจมี Transactions/DDLชนกับ Live Server

64. หยุด Resourceก่อน Migrationดีไหม

สำหรับ Core Schema Migration มักควรวาง Maintenanceให้ไม่มี Resourceกำลังเขียน Tableนั้น

แต่ให้ทำตาม Migration Instructionsของ Resourceจริง

65. Error1205กับPlayer Save

สมมติ Inventory Resourceเปิด Transaction

แล้ว Update:


players
inventory

ขณะ Core Save Update:


players

Queryหนึ่งอาจรออีก Query

66. ถ้า Inventory Transactionทำงานนาน

Core Saveอาจ Timeout

67. Error1205อาจทำ Player Dataไม่ Save

ขึ้นกับ Queryที่ล้ม

68. ต้องตรวจ Gameplay Impact

เช่น:

เงิน
Inventory
Vehicle State

ว่า Commitหรือไม่

69. MariaDB ระบุอะไรเมื่อ Timeout เกิด

สำหรับ innodb_lock_wait_timeout MariaDB ระบุว่าเมื่อ Timeout เกิด โดย Default Statement ที่รอถูก Rollback ไม่จำเป็นต้อง Rollback Transaction ทั้งหมด; สามารถเปลี่ยนพฤติกรรมด้วย innodb_rollback_on_timeout.

70. จุดนี้สำคัญมาก

อย่าคิดว่า Error1205ทำให้:


Transactionทั้งหมดถูกยกเลิกแน่นอน

เสมอไป

71. Resourceต้อง Handle Errorอย่างถูกต้อง

ถ้ามีหลาย Statementsใน Transaction:

ควรรู้ว่าเมื่อ Statementหนึ่ง Timeout:

Transaction Stateเป็นอย่างไร
ต้อง ROLLBACKเองหรือไม่

ตาม Database/Wrapperที่ใช้

72. ไม่เช่นนั้นเกิด Partial Logicได้

ตัวอย่าง:


Updateเงิน
↓
Updateรถ Timeout
↓
Codeไม่ Rollback

อาจสร้าง Stateที่ไม่ตรงตามที่ Resourceตั้งใจ

73. Third-party Resourceต้องตรวจ Transaction API

อย่าเขียน Raw Handlingจาก Guess

74. Error Message บอก `try restarting transaction`

แต่ Retryควรทำอย่างระวัง

75. ทำไม

ถ้า Transactionเดิมบางส่วน Commitไปแล้วเพราะ Resourceไม่ได้จัด Transactionจริง:

Retryอาจสร้างผลซ้ำ

76. ตัวอย่าง

Playerซื้อ Item

ครั้งแรก:


money deducted

แต่ Item Insert Timeout

Playerกดใหม่:

เงินอาจถูกหักอีก

ขึ้นกับ Resource Design

77. Operationสำคัญควร Atomic

Banking/Inventory Purchaseควรถูกออกแบบให้ข้อมูลที่ต้องสำเร็จร่วมกันอยู่ใน Transactionที่เหมาะสม

78. Retryต้องรู้ว่า Failureเกิดก่อนหรือหลัง Commit

79. Double-submitยิ่งทำปัญหาแย่

Playerกดปุ่มหลายครั้งตอน UIค้าง

สร้าง Requestsหลายชุด

80. UIควรป้องกัน

เช่น Disable Buttonระหว่าง Request

81. แต่ Serverต้องป้องกันด้วย

เพราะ Client-side Preventionไม่ใช่ Security Boundary

82. Server-side Request Validation

สามารถจำกัด:

Duplicate Transaction
Concurrent Action

ตาม Resource Design

83. Error1205เฉพาะ Playerหนึ่ง

อาจ Playerนั้นมี:

Transactionsหลายชุด
Resourceหลายตัว Saveพร้อมกัน

84. Errorทุก Player

น่าสงสัย:

Auto Save
Payday
Migration
Global Resource

85. Errorเฉพาะ Businessเดียว

Business Balance Rowอาจเป็น Hot Row

86. Errorเฉพาะ Stashหนึ่ง

Container Row/Itemsอาจถูก Updateพร้อมกันสูง

87. Errorเฉพาะ Garageหนึ่ง

Garage Cleanup/Vehicle State Updateอาจชนกัน

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

ตรวจว่ากระบวนการ Backup/Administrative Operationถือ MetadataหรือTable Locksหรือไม่

ไม่ควรสรุปว่า Backupเป็นสาเหตุจนเห็น Lockจริง

89. Errorหลังติด Resourceใหม่

Resourceใหม่อาจเปิด Transactionยาว

หรือ Update Core Tablesเดียวกับ Framework

90. Errorหลัง Framework Update

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

Third-party Resourcesเก่าอาจเริ่ม Contendกับ Coreมากขึ้น

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

ตรวจ:

Async/Await
Transactions
Connections
Error Handling

ตาม Documentationของ Library Versionนั้น

92. Connection Pool เกี่ยวไหม

ถ้า Transactionถูกผูกกับ Connectionหนึ่ง ต้องใช้ Transaction APIให้ถูก

ไม่ควรเปิด Transactionบน Connectionหนึ่งแล้ว Commitอีก Connectionโดยผิดวิธี

93. Closed-source Resource

ถ้าไม่เห็น SQL:

ส่ง Errorพร้อม:

Resource name
Version
Timing
Featureที่ Trigger

ให้ Official Developer

94. อย่าส่ง Database Password

ไม่จำเป็น

95. Processlist มี Sensitive Dataได้

Query Textอาจมี Player Identifiers

Maskก่อนโพสต์ Public

96. วิธีหา Blocking Session

เริ่ม:


SHOW FULL PROCESSLIST;

แล้วดู Connectionsที่:

Timeสูง
Stateเกี่ยวกับ Lock
Queryผิดปกติ

MariaDBระบุว่า Processlistใช้ดู Threadsที่กำลังทำงานและ Threadสามารถถูกจัดการด้วย KILLได้เมื่อจำเป็น.

97. ควร KILL Queryไหม

ใช้เฉพาะเมื่อทราบว่า Connection/Queryนั้นเป็น Blockerและเข้าใจผลกระทบ

98. MariaDB รองรับ


KILL thread_id;

หรือ Variantsตาม Documentationเพื่อยุติ Connection/Query.

99. แต่ไม่ควร KILLสุ่ม

เพราะ Transactionที่ถูกยุติอาจเป็น:

Banking
Character Save
Migration

100. KILL เป็น Emergency Tool

ไม่ใช่ Root Fix

101. ถ้าต้อง KILLตัวเดิมทุกวัน

Resource/Queryต้องถูกแก้

102. Idle Transaction อันตราย

Connectionอาจดูเหมือนไม่ทำอะไร

แต่ Transactionยังเปิดและถือ Lockอยู่

103. Resourceควร Commit/Rollbackทุก Path

ทั้ง:

Success
Error
Exception

104. JavaScript `finally`

Custom Developerอาจใช้โครงสร้าง Error Handlingให้ Cleanupเกิดแน่นอน

105. Lua Resourceก็ต้อง Handle Error Paths

ไม่ปล่อย Transactionเปิดค้าง

106. Transactionไม่ควรครอบ Gameplay Delay

ตัวอย่าง:


BEGIN
↓
Playerเลือกเมนู
↓
30วินาทีผ่าน
↓
Playerกดยืนยัน
↓
COMMIT

ไม่ควรถือ DB Transactionรอ Playerแบบนั้น

107. เก็บ Stateใน Applicationก่อน

เปิด Transactionเฉพาะตอน Commit Operationจริง

108. External APIก็เหมือนกัน

อย่าถือ Lockรอ:

Discord
Payment API
Webhook

ถ้าไม่จำเป็น

109. Query Orderสำคัญไหม

สำหรับ 1205ก็สำคัญ

แม้ Lock Orderสวนกันรุนแรงอาจกลายเป็น1213

แต่ Consistent Orderingยังช่วยลด Contention

110. Error1205สามารถเกิดก่อน Deadlockไหม

สถานการณ์ Lockingต่างกันได้

อย่าพยายามตีความ Errorหนึ่งเป็นอีก Error

ดู Database Diagnosisจริง

111. `INNODB_TRX.TRX_STATE`

ถ้าเห็น:


LOCK WAIT

คือ Transactionกำลังรอ Lockตาม MariaDB.

112. `TRX_STARTED`

ช่วยดูว่า Transactionเริ่มเมื่อใด.

113. Transactionที่เริ่มนานมาก

ควรตรวจว่า:

ทำอะไรอยู่
ใครเปิด
ทำไมยังไม่ Commit

114. `INNODB_LOCKS`

ช่วยดูว่า Transactionกำลังขอ Lockอะไรหรือ Lockใดกำลัง Block Transactionอื่น.

115. Metadata Lock Debug

สำหรับ MariaDBปัจจุบันมี METADATA_LOCK_INFO Plugin/Tableเพื่อดู Active Metadata Locksเมื่อ Pluginติดตั้งอยู่.

116. ต้องติด Pluginทุก Serverไหม

ไม่

สำหรับ Error1205ทั่วไปอย่าเพิ่ม Componentsก่อนจำเป็น

เริ่มจาก Processlist/InnoDB Transaction Dataก่อน

117. Errorเกิดเฉพาะ ALTER TABLE

Metadata Lock Toolsจึงมีประโยชน์มากขึ้น

118. Errorเกิดเฉพาะ Gameplay UPDATE

เน้น InnoDB Transaction/Record Locksก่อน

119. Query Optimizationช่วยยังไง

เป้าหมายคือ:

หา Rowเร็ว
Lock Rowsเท่าที่จำเป็น
Commitเร็ว

120. Missing Index

UPDATEที่ค้นด้วย Columnไม่มี Indexอาจต้องตรวจ Recordsจำนวนมาก

121. แต่ Indexไม่ใช่ Magic Fix

ถ้า Transactionเปิด 30วินาทีเพราะรอ HTTP:

Indexไม่ได้แก้ต้นเหตุ

122. ใช้ Evidence

ดู:

Query Duration
Explain Plan
Transaction Timeline

ก่อนปรับ

123. Error1205หลัง Databaseโต

เป็น Patternที่เป็นไปได้

Queryเดิมเมื่อ Tableมี1,000 Rowsเร็ว

เมื่อมีหลายล้าน Rowsอาจช้าขึ้นมากหาก Indexไม่เหมาะ

124. Logs Tableเป็นตัวอย่าง

ถ้า Cleanup Query:


DELETE old logs

แตะข้อมูลจำนวนมหาศาล

อาจถือ Locksนาน

125. Cleanupควรออกแบบเป็น Batchเมื่อเหมาะสม

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

126. ไม่ควร Batch Banking Transaction

ถ้า Operationต้อง Atomic

127. Maintenance Tasksต่างจาก Gameplay Transactions

ต้องออกแบบต่างกัน

128. Error1205ตอน Payday

แทน Updateทุก Playerใน Transactionยักษ์โดยไม่จำเป็น:

Resource Developerควรประเมิน Architecture

129. แต่ Server Ownerอย่า Rewrite Coreทันที

ตรวจ Official Updateก่อน

130. MariaDB Versionสำคัญไหม

มีผลกับ Features/Observabilityและบาง System Variables

ดังนั้นเวลาขอ Supportควรระบุ Versionจริง

131. `SHOW PROCESSLIST` บน MariaDBรุ่นปัจจุบัน

เอกสาร MariaDBระบุด้วยว่า Processlist Queryเองมี Locking Considerations และถ้า Performance Schemaเปิด อาจพิจารณาดู Threads Tableในบางสถานการณ์.

132. Server Ownerทั่วไปต้องเปลี่ยนไป Performance Schemaไหม

ไม่จำเป็นสำหรับ Errorครั้งเดียว

ใช้ Toolที่มีอยู่ก่อน

133. Error1205หลัง SQL Import

ถ้าคุณ Importขณะ Serverกำลังเล่น:

อาจ Import QueryและGameplay Queriesแข่งขันกัน

134. ทางที่ปลอดภัยกว่า

ทำ Core Migrationช่วง Maintenance

135. Database Schema Changes

เช่น:


ALTER TABLE players ...

อาจเกี่ยวกับ Metadata Lock.

136. อย่าทำ ALTERหลาย Tablesพร้อมกันแบบสุ่ม

โดยเฉพาะ Production

137. Error1205กับ `LOCK TABLES`

Table Locksเองก็สามารถเกี่ยวกับ Lock Waitingได้ตาม MariaDB Locking Mechanics.

138. FiveM Resourcesทั่วไปควรใช้ LOCK TABLESเองไหม

ไม่จำเป็นในหลาย Cases

หาก Third-party Resourceทำ ให้ตรวจเหตุผลและ Documentation

139. InnoDB Row-level Transactionsมักเพียงพอกับ Applicationทั่วไป

แต่ Resource Designเป็นตัวตัดสิน

140. Error1205 FAQ

FiveM `Lock wait timeout exceeded` คืออะไร

MariaDB Error1205หมายถึง Queryรอ InnoDB Lockเกินเวลาที่กำหนดและ Databaseยกเลิกการรอ.

ต่างจาก Deadlock1213อย่างไร

1205คือรอ Lockเกิน Timeout ส่วน1213คือ Databaseตรวจพบวงจร Deadlock.

`innodb_lock_wait_timeout` คืออะไร

เป็นระยะเวลาที่ InnoDB Transactionรอ Record/Table Lockก่อนเกิด Error1205.

เพิ่ม `innodb_lock_wait_timeout` ดีไหม

ไม่ควรเป็น First Fix เพราะอาจเพียงทำให้ Queryรอนานขึ้นโดยไม่ได้แก้ Blocking Transaction

ลด Timeoutดีไหม

ก็ไม่ได้แก้ Root Cause

เพียงทำให้ Waiting Statementล้มเร็วขึ้น

Error1205ทำ Rollbackทั้ง Transactionไหม

MariaDBระบุว่าสำหรับ InnoDB Lock Wait Timeout โดย Default Statementที่ Timeoutถูก Rollback ไม่ใช่ทั้ง Transaction และ innodb_rollback_on_timeout สามารถเปลี่ยนพฤติกรรมนี้ได้.

ทำไมเรื่องนี้สำคัญกับ FiveM

เพราะ Banking/Inventory Operationsหลาย Queryต้อง Handle FailureและRollbackให้ถูก ไม่ควรสมมติว่าทุกอย่างย้อนกลับโดยอัตโนมัติ

ดู Queryที่ Blockได้อย่างไร

เริ่มจาก:


SHOW FULL PROCESSLIST;

แล้วตรวจ InnoDB Transactions/Locksเพิ่มเติม.

`INNODB_TRX` ใช้ทำอะไร

แสดง InnoDB Transactionsที่กำลังทำงาน รวมถึง State, Start Timeและ Lock-related information.

`INNODB_LOCKS` ใช้ทำอะไร

แสดง Locksที่ Transactionsขอแต่ยังไม่ได้หรือ Locksที่กำลัง Block Transactionอื่น.

`SHOW ENGINE INNODB STATUS` ใช้ได้ไหม

ได้ ใช้ดูสถานะ InnoDBและรายละเอียด Deadlock/Engine Information.

Error1205เกิดจาก Metadata Lockได้ไหม

ได้ MariaDB Documentationระบุว่า Metadata Lock Waitที่เกิน lock_wait_timeout สามารถคืน Error1205ได้.

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

ตรวจ Active Transactionsและ Metadata Locksก่อน โดยเฉพาะถ้า Serverยังมี Playersใช้งาน Tableนั้น

Restart MariaDBแก้ไหม

อาจเคลียร์ Locksปัจจุบันแต่ไม่แก้ Resourceที่สร้าง Transactionค้าง

Restart FiveMแก้ไหม

อาจเคลียร์ Connectionsชั่วคราว แต่ไม่แก้ Transaction Design

Clear FiveM Cacheช่วยไหม

โดยทั่วไปไม่

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

ตรวจ Account Rows, Long-running Transactions, Duplicate Requestsและ Resourcesอื่นที่ Update Accountเดียวกัน

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

ตรวจ Stash/Player Inventoryที่ถูก Updateพร้อมกันและ Transaction Length

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

ตรวจ Vehicle Row, Ownershipและ Garage State Updates

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

ตรวจ Core Saveกับ Third-party Resourcesที่ Update Player Dataพร้อมกัน

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

ตรวจ Mass Saveและ Resourceอื่นที่เขียน Tableเดียวกันในช่วงเวลาเดียว

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

ตรวจ Bulk Updatesและ Shared Society/Business Rows

Errorเกิดช่วง Restartทำอย่างไร

ตรวจ Resource Stop/Save Orderและ Mass Save

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

ดูว่า Playerนั้นมี Operationsหลายชุดพร้อมกันหรือมี Rowใดเป็น Hot Row

Errorเกิดทุกคน

ตรวจ Processส่วนกลาง เช่น Auto Save, Payday, MigrationหรือCore Resource

ควร KILL Processไหม

MariaDBรองรับ KILL แต่ควรใช้เฉพาะเมื่อระบุ Blocking Threadได้และเข้าใจผลของการยุติ Connection/Transactionนั้น.

KILL Queryเป็น Fixถาวรไหม

ไม่

ถ้า Resourceสร้าง Transactionค้างซ้ำ Errorจะกลับมา

ต้อง Backupไหม

ถ้าจะแก้:

Schema
Indexes
Bulk Data
Migration

บน Production ควร Backupก่อน

สรุป FiveM MySQL Lock Wait Timeout Exceeded Error 1205

FiveM MySQL/MariaDB Error 1205 Lock wait timeout exceeded; try restarting transaction เกิดเมื่อ Query ต้องการ Lock แต่ Transaction อื่นถือ Lock นั้นไว้นานเกิน Timeout ที่ Databaseกำหนด โดย innodb_lock_wait_timeout ใช้ควบคุมเวลารอ InnoDB Record/Table Locks.

จำความแตกต่างนี้ไว้:


1205 = รอ Lock นานเกินไป
1213 = Deadlock เป็นวงจร

วิธีตรวจที่ควรเริ่มก่อนคือ:


Error 1205
↓
SHOW FULL PROCESSLIST
↓
INNODB_TRX
↓
INNODB_LOCKS
↓
หา Blocking Transaction
↓
หา FiveM Resource
↓
ตรวจ Transaction Length
↓
ปรับ Query / Index / Transaction Flow

MariaDBมีทั้ง SHOW PROCESSLIST, INNODB_TRX และ INNODB_LOCKS สำหรับช่วยตรวจ Connections, Transactions และ Locksที่เกี่ยวข้อง.

สิ่งที่ comsiam แนะนำคืออย่าเริ่มแก้ Error1205ด้วยการเพิ่ม innodb_lock_wait_timeout จำนวนมากหรือ Restart MariaDBทุกครั้ง เพราะ Queryที่ Errorอาจเป็นเพียงผู้รอ ส่วนต้นเหตุจริงคือ Transactionอีกตัวที่เปิดค้าง, ทำงานช้า หรือถือ Lockระหว่างทำงานที่ไม่ควรอยู่ใน Transaction ให้หา Blocking Transactionก่อนแล้วแก้ Resourceต้นทาง

อีกหลักที่ comsiam แนะนำคือให้ระวัง Banking, Inventory, Garageและ Character Saveเป็นพิเศษ เพราะถ้า Statementหนึ่ง Timeout MariaDBระบุว่าโดย Defaultอาจ Rollbackเฉพาะ Statement ไม่ใช่ Transactionทั้งหมด ดังนั้น Resourceต้อง Handle Failure/ROLLBACKอย่างถูกต้องและ Retryแบบไม่ทำให้เงิน Itemsหรือ Assetsซ้ำ.