FiveM MySQL Lost Connection to MySQL Server During Query Error 2013 แก้อย่างไร? ตรวจ Network, Query Timeout, Packet และ Database ที่หลุดกลางงาน

August 17, 2026

ปัญหา FiveM MySQL/MariaDB ขึ้น Lost connection to MySQL server during query หรือ Error 2013 หมายถึง Connection ระหว่าง FiveM กับ Database ขาดหาย ระหว่างที่กำลังประมวลผลหรือรับส่ง Query อยู่ ไม่ใช่แค่เปิด Connection ใหม่ไม่สำเร็จ

MariaDB มีการใช้ข้อความ:


ERROR 2013 (HY000):
Lost connection to MySQL server during query

สำหรับ Error 2013 ในเอกสารและ Release Notes ของระบบ.

ใน FiveM อาจพบข้อความ เช่น:


Lost connection to MySQL server during query


Error 2013


Connection lost during query


Database connection terminated


Query failed: connection closed

ปัญหานี้สามารถเกิดกับ:

Character Save
Inventory
Banking
Garage
Housing
Phone
Vehicle Properties
Business
Billing
Database Import
Query ขนาดใหญ่
Remote MariaDB
Database Restart
Network หลุด
net_read_timeout
net_write_timeout
max_allowed_packet

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

ดูว่า Connection หลุดตอน Query ไหน → Database Restart หรือไม่ → Query ใหญ่หรือช้าหรือไม่ → Network ปกติหรือไม่ → ตรวจ Read/Write Timeout → ตรวจ Packet → ตรวจ Resource/Pool

① Error 2013 คืออะไร

Error 2013 หมายถึง Client สูญเสีย Connection กับ MySQL/MariaDB Server ขณะที่กำลังดำเนิน Query อยู่ โดย MariaDB มีตัวอย่าง Error 2013 พร้อมข้อความ Lost connection to MySQL server during query.

② ต่างจาก Error 2006 อย่างไร

บทความก่อนหน้า:

Error 2006


MySQL server has gone away

มักเห็นเมื่อ Connection ที่ Client ต้องการใช้ไม่สามารถใช้ต่อได้แล้ว

Error 2013


Lost connection to MySQL server during query

มักชี้ให้ตรวจเหตุการณ์ที่ Connection หลุด ระหว่าง Operation

③ ทั้งสอง Error เกี่ยวกับ Connection

แต่ Context ต่างกัน

จึงไม่ควรใช้ Fix เดียวกันโดยอัตโนมัติ

④ Error 2013 เป็น SQL Syntax Error หรือไม่

ไม่

ถ้า SQL Syntax ผิดมักไปที่ Error เช่น 1064

2013 เน้น Connection Communication ระหว่าง Query

⑤ Error 2013 เป็น Too Many Connections หรือไม่

ไม่

1040


Too many connections

2013


Lost connection during query

เป็นคนละปัญหา

⑥ FiveM Cache ช่วยไหม

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

Database Connection ที่หลุดกลาง Query เป็นปัญหาฝั่ง:

Server
Database
Network
Database Client

มากกว่า Client FiveM Cache

⑦ Restart FiveM ช่วยไหม

อาจทำให้สร้าง Database Connections ใหม่และอาการหายชั่วคราว

แต่ถ้า Root Cause ยังอยู่:

Errorกลับมาได้

⑧ Restart MariaDB ช่วยไหม

ถ้า MariaDBผิดปกติอาจจำเป็นในบางเหตุการณ์

แต่ Restartเองจะตัด Connectionsทั้งหมด

จึงไม่ควรใช้เป็น Fixประจำ

⑨ สาเหตุแรกที่ต้องเช็ก — MariaDB Restart

ถ้า MariaDB Restartกลาง Query:


FiveM ส่ง Query
↓
MariaDB restart
↓
Connection หาย
↓
FiveM รอผลลัพธ์
↓
Error 2013

⑩ ถ้าทุก Resource Error พร้อมกัน

เช่น:


Inventory failed
Bank failed
Garage failed
Phone failed

พร้อมกันในเวลาใกล้เคียงกัน

ควรตรวจ Database/Infrastructure ก่อนแก้ Resource ทีละตัว

⑪ ถ้า Error Resource เดียว

กลับกัน ถ้า:

Bankingปกติ
Inventoryปกติ
Garageปกติ

แต่ Housingขึ้น2013

ให้ตรวจ Query/Payloadของ Housing Resourceก่อน

⑫ Error เฉพาะ Character คนเดียว

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

อาจมี:

Inventory JSON ใหญ่ผิดปกติ
Metadataผิด
Appearance Dataใหญ่
Data Corruption

⑬ Error เฉพาะ Vehicle คันเดียว

ตรวจ:

Vehicle Properties
Mods JSON
Damage Data

⑭ Errorเฉพาะ Houseหนึ่งหลัง

ตรวจ:

Furniture
Object Data
Storage Metadata

⑮ Errorเฉพาะ Phone Account

ตรวจ:

Messages
Contacts
Resource Query

ตาม Schemaจริง

⑯ `net_read_timeout` คืออะไร

MariaDB ระบุ net_read_timeout ว่าเป็นเวลาที่ Server จะรอให้ Client Connection ส่งข้อมูลเพิ่มเติมก่อนยกเลิกการ Read; ค่านี้เป็น Dynamic Global/Session Variable.

⑰ Default เท่าไร

MariaDB Documentation ปัจจุบันระบุ Default ของ net_read_timeout เป็น:


30 seconds

แต่ค่าจริงของ Serverคุณอาจถูกเปลี่ยนจาก Default จึงต้องตรวจจริง.

⑱ ตรวจอย่างไร


SHOW VARIABLES LIKE 'net_read_timeout';

⑲ `net_write_timeout` คืออะไร

เป็น Timeout ที่เกี่ยวกับเวลาที่ MariaDB รอเมื่อกำลังเขียนข้อมูลไปยัง Client โดย MariaDB Connector Documentation ระบุว่า Server Variable นี้ควบคุม Network Write Timeout.

⑳ ตรวจได้ด้วย


SHOW VARIABLES LIKE 'net_write_timeout';

㉑ `net_read_timeout` กับ `net_write_timeout` ต่างกันอย่างไร

จำง่าย ๆ:


net_read_timeout
= Server รออ่านข้อมูลจาก Client

net_write_timeout
= Server รอส่งข้อมูลไป Client

㉒ ควรเพิ่มทั้งคู่ทันทีไหม

ไม่

ต้องรู้ก่อนว่า Errorเกิดตอน:

ส่ง Queryขนาดใหญ่
รับ Resultขนาดใหญ่
Networkช้า
Database Restart

แบบไหน

㉓ ตัวอย่าง Query ส่งข้อมูลใหญ่

FiveM Resourceส่ง:


INSERT / UPDATE

พร้อม JSONขนาดใหญ่มาก

ถ้า Network/Clientส่งข้อมูลได้ช้าผิดปกติ:

ควรตรวจ Read-side Timeout และ Payload

㉔ ตัวอย่าง Result ใหญ่

Resourceทำ:


SELECT *
FROM huge_logs;

แล้ว Result Set ใหญ่มาก

Databaseต้องส่งข้อมูลจำนวนมากกลับ FiveM

㉕ อย่า SELECT ทุกอย่างโดยไม่จำเป็น

เช่น:


SELECT *
FROM phone_messages;

โดยไม่มี:

WHERE
LIMIT

บน Tableใหญ่

㉖ Query อาจคืนหลายแสน Rows

FiveM Resourceทั่วไปแทบไม่ควรต้องโหลดข้อมูลทั้งหมดแบบนั้นใน Gameplay Event

㉗ Pagination ช่วยได้

ถ้าต้องแสดงข้อมูลจำนวนมาก:

โหลดเป็นชุดตามที่ Resourceออกแบบ

แทนโหลด Databaseทั้ง Tableครั้งเดียว

㉘ Phone Messages เป็นตัวอย่าง

Playerเปิด Phoneไม่ควรจำเป็นต้องโหลด Messageทั้งหมดของผู้ใช้ทุกคน

ควร Scope Queryตาม Account/Conversationจริง

㉙ Logs ก็เช่นกัน

Admin Panelอาจใช้:


ล่าสุด 50–100 รายการ

แทนดึงหลายล้าน Rows

ตาม Use Case

㉚ Query ใหญ่ไม่ได้หมายถึง SQL ผิด

SQLอาจ Syntaxถูกทั้งหมด

แต่ Workloadไม่เหมาะ

㉛ `max_allowed_packet` เกี่ยวไหม

เกี่ยวเมื่อมี Packet หรือ Generated/Intermediate Stringขนาดใหญ่ MariaDBกำหนด max_allowed_packet เป็นขนาดสูงสุดของ Packetหรือ Generated/Intermediate Stringที่ Serverรองรับ.

㉜ Packet ใหญ่เกินมี Error เฉพาะไหม

MariaDB มี Error 1153:


Got a packet bigger than 'max_allowed_packet' bytes

จึงควรอ่านข้อความ Errorรอบ ๆ 2013ด้วย เพราะอาจมีเบาะแส Packet Sizeเพิ่มเติม.

㉝ ตรวจ max_allowed_packet


SHOW VARIABLES LIKE 'max_allowed_packet';

㉞ ไม่ควรเพิ่มเป็น 1GB ทันที

แม้ MariaDBรองรับการกำหนด Packetขนาดใหญ่ในบาง Configuration แต่ควรปรับตาม Payloadจริง ไม่ใช่เพิ่มสุดเพื่อปิด Error.

㉟ FiveM Data อะไรโตได้

Inventory JSON
Appearance
Vehicle Properties
Housing Furniture
Metadata
Logs

㊱ Inventory Metadata อาจโตผิดปกติ

ตัวอย่าง Itemหนึ่งมี Metadataซ้อนซ้ำ

จาก:


metadata

กลายเป็น:


metadata
→ metadata
→ metadata

จาก Bug

㊲ Payload จึงโตเรื่อย ๆ

แทนที่จะเพิ่ม Packet Limit:

ควรแก้ Serialization/Data Growth

㊳ Double JSON Encode

เป็นอีก Pattern

ข้อมูลเดิม:


{"plate":"ABC123"}

ถูก Encode แล้วถูก Encode Stringซ้ำอีก

㊴ Errorอาจไม่เกิดทันที

แต่ Database Rowอาจโตขึ้นตาม Updates

จนวันหนึ่ง Queryใหญ่ผิดปกติ

㊵ Compare Record

ถ้า Error Playerเดียว:

เปรียบเทียบขนาด Dataกับ Playerปกติ

㊶ อย่าลบ Data ก่อน Backup

โดยเฉพาะ:

Inventory
Vehicle
Housing

㊷ Remote Database เป็นอีกสาเหตุสำคัญ

ถ้า FiveMกับMariaDBอยู่คนละ Host:

Connectionต้องผ่าน Networkระหว่างสอง Server

㊸ Network Interruption

ถ้า TCP Connectionขาดระหว่าง Query:

FiveMอาจสูญเสีย Database Session

㊹ Ping ปกติไม่ได้พิสูจน์ว่า Database Session ไม่เคยหลุด

เพราะ Ping และ Database TCP Sessionเป็นคนละ Traffic/Connection Context

㊺ ควรดูอะไรเพิ่ม

Packet loss
Network route
Firewall
NAT
Hosting incidents

เมื่อเป็น Remote DB

㊻ อย่าเปลี่ยน DNSก่อน

ถ้า FiveMเชื่อม Databaseด้วย IPตรงอยู่แล้ว

DNSไม่ใช่สาเหตุในกรณีนั้น

㊼ Firewall Idle Session

Network Deviceบางระบบอาจตัด Connectionsที่ Idle

ทำให้ Poolเก็บ Connectionที่ปลายทางใช้ไม่ได้แล้ว

㊽ แต่ Errorหลัง Idleมักควรเทียบกับ 2006ด้วย

เพราะ 2006มักชัดกับ Stale/Expired Connectionมากกว่า

㊾ 2013 มักน่าสนใจเมื่อ Connectionกำลังมี Activity

เช่น:

Queryกำลังรัน
Resultกำลังส่ง
Bulk Dataกำลัง Upload

㊿ Query ช้าเกินไป

ถ้า Queryใช้เวลานานมาก:

อาจชน:

Network Timeout
Client Timeout
Infrastructure Timeout

ขึ้นกับ Stackที่ใช้

51. อย่าเพิ่ม Timeoutก่อน Optimize Query

ถ้า Queryหนึ่งใช้เวลา:


60 seconds

แต่จริง ๆควร:


50 milliseconds

การเพิ่ม Timeoutเป็น:


300 seconds

ไม่ใช่ Fixที่ดี

52. Query Performanceต้องตรวจ

ดูว่า Query:

มี WHEREไหม
มี Indexเหมาะไหม
ดึง Rowsมากไปไหม

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


SELECT *
FROM transactions
ORDER BY created_at DESC;

ถ้า Tableมี Recordsมหาศาลและไม่จำเป็นต้องโหลดทั้งหมด

54. Better Concept

ใช้:

Filter
Limit
Pagination

ตาม Featureจริง

55. ห้าม Copy LIMIT แบบสุ่ม

ถ้า Business Logicต้องการข้อมูลครบ

ต้องออกแบบ Applicationให้ถูก

56. Errorตอน Player Login

FiveM Loginสามารถโหลดหลายระบบ เช่น:


Character
Inventory
Vehicles
Phone
Housing
Business

57. ถ้าทุก Resourceยิง Heavy Queryพร้อมกัน

Database/Networkอาจรับ Workloadสูงมาก

58. Login Storm

หลัง Restart Playersหลายสิบคนเข้า Serverพร้อมกัน

ยิ่งเพิ่ม Concurrent Query Load

59. Errorเฉพาะ Restart

ตรวจ:

Startup Load
Login Burst
Database Readiness

60. MariaDBอาจยัง Recoverอยู่

ถ้า FiveMเปิดเร็วกว่าที่ Databaseพร้อมรองรับ Workloadเต็ม

61. Hardcoded Waitไม่ใช่ Fixที่ดีที่สุดเสมอ

Infrastructureที่ดีควรมี:

Health check
Reconnect handling

ตาม Environment

62. Errorช่วง Auto Save

Playersจำนวนมากอาจ Saveพร้อมกัน

63. Inventory JSONจำนวนมาก

ถูกส่งพร้อมกันหลาย Players

ทำให้ Traffic/DB Loadพุ่ง

64. ควร Stagger Auto Saveไหม

ขึ้นกับ Framework

ถ้า Frameworkมี Official Mechanismให้กระจาย Save:

ใช้ตามนั้น

อย่า Patch Coreแบบสุ่ม

65. Errorช่วง Payday

Transactionsจำนวนมากอาจรันพร้อมกัน

66. Errorช่วง Scheduled Restart

อาจมี:

Mass Save
Backup
Resource Stop

พร้อมกัน

67. ต้องดู Timeline

เช่น:


16:00 Payday
16:00 Auto Save
16:00 Backup

สามงานชนกัน

68. กระจาย Scheduleอาจช่วย

ถ้า Workloadไม่จำเป็นต้องเกิดวินาทีเดียวกัน

69. Error2013หลัง Database Backup

ไม่ควรโทษ Backupทันที

ตรวจว่า Backup:

Restart DBหรือไม่
Lockหนักหรือไม่
ใช้ I/Oสูงหรือไม่

70. Storage I/Oเต็ม

Database Queryอาจช้ามากเมื่อ Disk I/Oเป็น Bottleneck

71. โดยเฉพาะ VPS Storageช้า

แต่ต้องใช้ Metricsยืนยัน

72. CPUเต็มก็เช่นกัน

Queryอาจประมวลผลช้ามาก

73. RAMไม่พอ

อาจนำไป:

Swap
OOM
Database Restart

ตาม Environment

74. ถ้า MariaDB Process ถูก Kill

FiveM Connectionsทั้งหมดหาย

75. ตรวจ MariaDB Logs

สำคัญมากถ้า Error2013เกิดทุก Resourceพร้อมกัน

76. ตรวจ Uptime

หลังเกิด Error:


SHOW GLOBAL STATUS LIKE 'Uptime';

ถ้า Uptimeต่ำผิดปกติ:

Databaseน่าจะเพิ่ง Restart

77. ถ้า Uptimeปกติ

โฟกัส:

Query
Network
Timeout
Resource

มากขึ้น

78. Errorเฉพาะ Remote Database

เทียบกับ Local Testingได้

ถ้า Localไม่เกิด:

Network Pathควรถูกตรวจ

79. แต่อย่าย้าย Databaseมา Localทันที

หาสาเหตุจริงก่อน

Remote DBเป็น Architectureที่ใช้งานได้ถ้า Networkเหมาะสม

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

เกี่ยว

Database Wrapperมักใช้ Connection Poolเพื่อ Reuse Connections

81. Pool Connection ที่เสีย

ควรถูก Remove/Reconnectตาม Logicของ Library

82. Resourceไม่ควรเก็บ Raw Connectionเองตลอดไป

หาก Wrapperออกแบบให้ Resourceเรียก APIผ่าน Pool

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

ตรวจ:

Supported Resource Version
Connection options
Pool
Timeouts

84. Legacy Resourceอาจใช้ APIเก่า

หลัง Upgrade Wrapper:

Queryบางตัวอาจมี Behaviorไม่เหมือนเดิม

85. อย่าแก้ด้วย Wrapperหลายตัว

เช่น Startทั้ง:


old mysql resource
new mysql resource

เพียงเพื่อให้ Scriptsทั้งหมดทำงาน

โดยไม่เข้าใจ Compatibility

86. Database Connectionsอาจซ้ำซ้อน

และนำไปปัญหาอื่น เช่น1040

87. Error2013กับ1040เกิดร่วมได้

ตัวอย่าง:


DBกลับมา
↓
Resources reconnect
↓
Connection storm
↓
1040 Too many connections

88. ดังนั้นอย่าดู Errorแยกโดยไม่ดู Timeline

89. Query Timeoutฝั่ง Client

Database Wrapperบางตัวอาจมี Timeoutของตัวเอง

นอกเหนือจาก MariaDB Server Variables

90. จึงมีหลายชั้น


FiveM resource
↓
database wrapper
↓
network
↓
MariaDB

91. เพิ่ม MariaDB Timeoutอย่างเดียวอาจไม่ช่วย

ถ้า Wrapperเอง Timeoutก่อน

92. ตรวจ Documentationของ Wrapper Versionจริง

ไม่ควร Copy Configจาก Versionเก่า

93. `net_read_timeout` ไม่เท่ากับ `wait_timeout`

จำให้ชัด

wait_timeout

Connection idle

net_read_timeout

Serverกำลังรอ Clientส่งข้อมูลเพิ่ม

MariaDBกำหนด net_read_timeout เป็น Read Communication Timeoutโดยเฉพาะ.

94. `net_write_timeout` ก็ไม่เหมือน wait_timeout

เป็น Network Write Communication Timeout ไม่ใช่ Idle Session Timeout.

95. อย่าเพิ่มสามตัวพร้อมกัน

เพราะไม่รู้ว่า Root Causeคืออะไร

96. ตรวจค่าปัจจุบันก่อน


SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'net_read_timeout';
SHOW VARIABLES LIKE 'net_write_timeout';
SHOW VARIABLES LIKE 'max_allowed_packet';

97. จดค่าก่อนเปลี่ยน

เพื่อ Rollbackและเปรียบเทียบได้

98. Configuration Changeควรทำบน Stagingก่อนเมื่อเป็นไปได้

โดยเฉพาะ Serverใหญ่

99. Errorจาก Result Setใหญ่

เช่น Resource Adminเปิดหน้า Logsแล้ว Queryข้อมูลทั้งหมด

100. ถ้า Errorเกิดเฉพาะหน้า Adminนั้น

อย่าเพิ่ม Global Timeoutก่อน

Optimize Featureนั้น

101. Searchควรทำฝั่ง Database

เช่น:

WHERE
Index
LIMIT

แทนโหลดทุกอย่างแล้ว Filterใน Lua/JavaScript

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


โหลด transactions 1,000,000 rows
↓
Luaเลือก 50ล่าสุด

Databaseควร Queryเฉพาะข้อมูลที่ต้องการ

103. Errorจาก SELECT BLOB/TEXTใหญ่

MariaDB Documentation ระบุว่าค่า BLOB/TEXT ขนาดใหญ่อาจชนข้อจำกัด max_allowed_packet.

104. FiveM Resourcesชอบใช้ LONGTEXT

โดยเฉพาะ JSON

105. แต่ LONGTEXTรองรับใหญ่ไม่ได้หมายความว่า Queryขนาดเท่าไรก็เหมาะ

Packet Limitยังมีผลกับการส่งข้อมูล.

106. อย่าเปลี่ยนทุก JSONเป็น LONGTEXT

Error2013ไม่จำเป็นต้องเกิดเพราะ Column Type

107. Error1406ต่างกัน

ถ้า Columnสั้นเกิน:


Data too long for column

เป็นอีก Error

108. Error1153ต่างกัน

ถ้า Packetเกิน Limitชัด:


Got a packet bigger than max_allowed_packet

MariaDBมี Errorเฉพาะสำหรับเรื่องนี้.

109. ถ้าเห็น 1153 ก่อน2013

Packet Sizeเป็นเบาะแสที่แข็งแรงมาก

110. ถ้าไม่มี 1153

ยังไม่ควรสรุปว่า Packetไม่เกี่ยว

แต่ต้องดู Causesอื่นด้วย

111. Errorตอน Bulk INSERT

Resource Loggerอาจรวบรวม Logsจำนวนมากแล้วส่ง Queryเดียว

112. Batchใหญ่เกิน

อาจสร้าง:

Packetใหญ่
Queryยาว
Transactionยาว

113. Batchเล็กลงอาจเหมาะ

สำหรับ Background Logs

แต่ต้องออกแบบตาม Resource

114. ไม่ควร Batch Money Transactionsแบบสุ่ม

เพราะ Atomicity/Integrityต่างกัน

115. LogsกับBankingไม่เหมือนกัน

Database Strategyไม่ควร Copyกันทั้งหมด

116. Errorตอน SQL Import

Bulk INSERTจาก Dumpอาจใหญ่

MariaDB Documentationยังชี้ว่าการโหลดข้อมูลขนาดใหญ่บางสถานการณ์อาจต้องพิจารณา net_read_timeout และ net_write_timeout.

117. แต่ Import Errorไม่เท่ากับ Runtime Error

ถ้า FiveMเล่นปกติแต่ Import SQLขึ้น2013:

แก้ Import Pathเป็นหลัก

118. อย่าเปลี่ยน Gameplay Resourceเพราะ Dump Import Fail

119. SQL Importผ่าน Web UI

อาจมี Timeoutอีกชั้น เช่น:

Web server
PHP

นอกเหนือจาก MariaDB

120. ถ้าใช้ CLIแล้วผ่าน

อาจชี้ว่า Web Layerมีข้อจำกัด

121. FiveM Runtimeไม่มี PHP Web Layer

จึง Debugคนละแบบ

122. Error2013กับ SSL/TLS

Connectionที่ใช้ TLSยังสามารถเกิด Communication Lossได้

แต่ไม่ควรปิด SSLเป็น First Fix

123. Remote DBที่ต้องใช้ TLS

ควรรักษา Securityและแก้ Configuration/Networkจริง

124. Error after Certificate Change

ถ้า Connectionสร้างไม่ได้อาจเห็น TLS/Handshake Errorอื่นร่วม

อ่าน Errorทั้งหมด

125. Database Proxy

ถ้าใช้:

Proxy
MaxScale

ก็มี Timeout Layerเพิ่ม

126. MariaDB MaxScaleมี Network Timeout Settingsของตัวเองในบาง Config

จึงต้องรู้ Architectureก่อนแก้ Server Variables.

127. FiveMทั่วไปไม่ได้ใช้ MaxScaleเสมอไป

อย่าไปปรับ MaxScaleถ้า Serverคุณไม่มี

128. Error2013หลัง Queryใช้เวลานานทุกครั้ง

ต้อง Profile Query

ไม่ควรเพิ่ม timeoutแล้วปล่อย Queryช้าไปเรื่อย ๆ

129. Slow Query Tableโตขึ้น

วันนี้ใช้5วินาที

อีก6เดือนอาจใช้60วินาที

130. Indexที่ถูกต้องช่วย Scale

แต่ Indexต้องอิง Queryจริง

131. `SELECT *`ควรหลีกเลี่ยงไหม

ถ้า Resourceต้องใช้ทุก Columnจริง:

ใช้ได้

แต่ถ้าต้องการแค่:


id
name
status

ก็ไม่จำเป็นต้องดึง JSONใหญ่ทุก Column

132. Example Phone List

รายชื่อ Contactsอาจไม่ต้องโหลด:

Full message history

พร้อมกัน

133. Vertical Data Sizeมีผล

ไม่ใช่แค่จำนวน Rows

Rowเดียวที่มี LONGTEXTหลาย MBก็หนักได้

134. Errorเฉพาะ Playerที่เล่นมานาน

Legacy Accumulated Dataอาจโต

135. Example Metadata History

Resourceผิด Designเก็บ:


old state + new state

ทุก Updateใน JSONเดียว

Dataจึงโตไม่สิ้นสุด

136. Database Tableควร Normalizeไหม

ขึ้นกับ Resource Design

อย่า Rewrite Third-party Schemaเองถ้า Developerมี Migration/Update

137. Error2013หลัง Update Resource

ตรวจ Changelogก่อน

อาจ Developerแก้:

Payload Size
Query
Timeout

ใน Versionใหม่แล้ว

138. Error2013หลัง Resource Updateใหม่

ก็ตรวจ Regressionเช่นกัน

139. Rollback Resourceอย่างเดียวต้องระวัง

Database Schemaอาจถูก Migrationไป Versionใหม่แล้ว

Codeเก่าอาจไม่รองรับ

140. Backupก่อน Rollback/Migration

สำคัญ

141. FiveM Consoleควรเก็บ Queryไหม

ถ้า Database Wrapper Log Queryที่ล้ม:

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

142. แต่ Mask Sensitive Data

เช่น:

identifiers
tokens
phone messages

ก่อนแชร์ Public

143. Database Passwordไม่จำเป็นต่อการ Debug2013

อย่าส่งให้คนแปลกหน้า

144. ตรวจ MariaDB Logsช่วงเวลาเดียวกัน

เช่น Errorเกิด:


16:30:15

เปิด Database Logดูใกล้:


16:30

145. ถ้ามี Restart/Crashตรงกัน

Root Causeชัดขึ้นมาก

146. ถ้าไม่มี Server-side Errorเลย

กลับไปตรวจ:

Network
Wrapper
Client timeout
Query

147. Error2013ทุก10นาที

Patternเวลาสม่ำเสมอเป็นเบาะแส

ตรวจ Scheduled Task/Timeout

148. Errorสุ่มเฉพาะ Peak

น่าสงสัย Load/Network/Slow Queries

149. Errorเฉพาะเวลาไม่มี Playerนาน

น่าสงสัย Idle Connectionมากกว่า และควรเทียบกับ Error2006

150. Errorเฉพาะ Queryหนึ่ง

น่าสงสัย:

Query Size
Query Duration
Result Size

151. Errorทุก Query

น่าสงสัย Infrastructure/DB Service

152. ขั้นตอนตรวจแบบเร็ว


2013
↓
ทุก Resource หรือ Resourceเดียว?
↓
DB Restartไหม?
↓
Remote DBไหม?
↓
Queryใหญ่/ช้าไหม?
↓
net_read_timeout
↓
net_write_timeout
↓
max_allowed_packet
↓
Wrapper/Pool

153. ถ้าทุก Resourceพร้อมกัน

ตรวจ:

MariaDB Uptime
Database Logs
Network

ก่อน

154. ถ้า Resourceเดียว

ตรวจ:

Query
Payload
Resource Version

155. ถ้า Playerเดียว

ตรวจ:

Record Size
JSON
Legacy Data

156. ถ้าช่วง Peak

ตรวจ:

Slow Queries
CPU
I/O
Concurrent Queries

157. ถ้า Remote DB

ตรวจ:

Packet loss
Firewall/NAT
Network Stability

158. ถ้า Bulk Import

ตรวจ:

Statement size
Packet
Read/Write Timeout

159. สิ่งที่ไม่ควรทำ

เพิ่มทุก Timeoutพร้อมกัน
เพิ่ม max_allowed_packetสูงสุดทันที
Restart MariaDBทุกครั้ง
Clear FiveM Cache
ลบ Character
ลบ Database
Retry Write Queryไม่จำกัด

160. ทำไม Retry Write Queryอันตราย

สมมติ:


INSERT vehicle

ถูกส่งถึง Database

Databaseบันทึกสำเร็จ

แต่ Connectionขาดก่อน Clientได้รับ Response

161. Clientอาจคิดว่า Failed

แล้ว Retry:


INSERT vehicle

อีกครั้ง

162. อาจเกิด Duplicate Asset

ถ้าไม่มี Unique/Idempotency Protection

163. Bankingยิ่งต้องระวัง

Transferที่ถูก Retryอาจทำเงินเคลื่อนซ้ำ

164. Inventory Rewardก็เช่นกัน

อาจเกิด Itemซ้ำ

165. Read QueryกับWrite Queryต้องแยก

Retry:


SELECT ...

มักมี Side Effectน้อยกว่า:


INSERT
UPDATE
DELETE

166. Resourceควร Handle Write Failureอย่างรัดกุม

โดยเฉพาะ:

Money
Assets
Items

167. Transaction Referenceช่วยได้

สำหรับระบบที่ออกแบบมารองรับ Idempotency

แต่ไม่ควรเพิ่ม Custom IDเองใน Third-party Resourceโดยไม่เข้าใจ Schema

168. Error2013 FAQ

FiveM `Lost connection to MySQL server during query` คืออะไร

หมายถึง Connectionกับ Databaseหายระหว่าง Query โดย MariaDBมีการใช้ข้อความ Error2013 (HY000) Lost connection to MySQL server during query.

Error2013กับ2006ต่างกันอย่างไร

2006มักเกี่ยวกับ Connectionที่ใช้ไม่ได้แล้ว ส่วน2013ชี้ไปที่ Connectionที่หายระหว่างการดำเนิน Query

Restart MariaDBช่วยไหม

อาจทำให้ Serviceกลับมาหาก Databaseมีปัญหา แต่ Restartเองตัด Connectionsและไม่ควรใช้เป็น Fixประจำ

Restart FiveMช่วยไหม

สร้าง Connectionsใหม่ได้ แต่อาการจะกลับถ้า Root Causeยังอยู่

Clear FiveM Cacheช่วยไหม

โดยทั่วไปไม่เกี่ยว

`net_read_timeout` คืออะไร

เวลาที่ MariaDBรอให้ Clientส่งข้อมูลเพิ่มเติมก่อนยกเลิก Read; Documentationปัจจุบันระบุ Default30วินาที.

`net_write_timeout` คืออะไร

Timeoutของการเขียนข้อมูลจาก Serverไป Client.

เพิ่ม net_read_timeoutดีไหม

เฉพาะเมื่อพิสูจน์แล้วว่าการส่งข้อมูลช้าจริง ไม่ควรใช้แทนการแก้ Query/Payloadผิดปกติ

เพิ่ม net_write_timeoutดีไหม

หลักเดียวกัน ต้องรู้ว่า Serverกำลังติดตอนส่ง Resultจริง

max_allowed_packetเกี่ยวไหม

เกี่ยวเมื่อ Payload/Packetใหญ่ โดย MariaDBกำหนด Variableนี้เป็นขนาดสูงสุดของ Packetหรือ Generated/Intermediate String.

Packetใหญ่เกินมี Errorอะไร

MariaDBมี Error1153 Got a packet bigger than 'max_allowed_packet' bytes.

Inventory JSONใหญ่ทำ Errorได้ไหม

Payloadขนาดใหญ่มากควรตรวจ Packet Sizeและ Data Growth โดยเฉพาะถ้า Errorเกิด Characterเดียว

Housing Furnitureใหญ่ทำ Errorได้ไหม

ได้ในเชิง Payload หาก Resourceเก็บ Dataจำนวนมากใน Queryเดียว

Errorเฉพาะ Vehicleเดียวทำอย่างไร

ตรวจ Vehicle Properties/JSONเทียบกับ Vehicleปกติ

Errorทุก Playerทำอย่างไร

ตรวจ Database Service, Networkและ Resourceส่วนกลางก่อน

Errorเฉพาะหลัง Restartทำอย่างไร

ตรวจ Login Burst, Startup Orderและ Database Readiness

Errorเฉพาะ Auto Saveทำอย่างไร

ตรวจ Concurrent Savesและ Query/Payload Sizes

Errorเฉพาะ Paydayทำอย่างไร

ตรวจ Concurrent Database Workload

Errorเฉพาะตอน Import SQLทำอย่างไร

ตรวจ Bulk Statement Size, max_allowed_packet, net_read_timeout และ net_write_timeout; MariaDBเองระบุว่าการโหลดข้อมูลขนาดใหญ่อาจต้องพิจารณา Network Timeouts.

Errorเฉพาะ Remote Databaseทำอย่างไร

ตรวจ Network Path, Firewall/NATและ Database Logs

Pingปกติแปลว่า Networkไม่ใช่ปัญหาไหม

ไม่ เพราะ Database TCP Sessionไม่ใช่ ICMP Ping

Queryช้าทำ Error2013ได้ไหม

Long-running Queryสามารถเพิ่มโอกาสให้ชน Timeoutใน Layersต่าง ๆ จึงควร Optimize Queryก่อนเพิ่ม Timeoutโดยไม่จำเป็น

SELECTข้อมูลเยอะเกินเกี่ยวไหม

ได้ เพราะ Result Setใหญ่ทำให้ Databaseต้องส่งข้อมูลจำนวนมากและใช้เวลานานขึ้น

LONGTEXTแก้ได้ไหม

LONGTEXTเป็น Column Capacity ไม่ใช่ Connection Fix และข้อมูล BLOB/TEXTขนาดใหญ่ยังอยู่ภายใต้ Packet Constraints.

เปลี่ยนทุก Columnเป็นLONGTEXTดีไหม

ไม่

Error2013หลัง Update Database Wrapperทำอย่างไร

ตรวจ Wrapper Version, Pool, Timeoutและ Resource Compatibility

Errorหลัง Hosting Migrationทำอย่างไร

ตรวจ Database Host, Network, Firewall, Connection Stringและ Configurationของ MariaDBใหม่

Errorหลัง MariaDB Restartแล้ว1040ตามมาคืออะไร

อาจเกิด Reconnect Burstจน Connectionsเต็มได้ ต้องตรวจ TimelineและConnection Metrics

ต้อง Reinstall MariaDBไหม

โดยทั่วไปไม่ใช่ First Fix

ต้องลบ Databaseไหม

ไม่

ต้อง Backupไหม

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

สรุป FiveM MySQL Lost Connection During Query Error 2013

FiveM MySQL/MariaDB Error 2013 Lost connection to MySQL server during query คืออาการที่ Connection ระหว่าง Resource กับ Database หายขณะที่กำลังดำเนิน Query โดยการวิเคราะห์ควรแยกว่าเป็น Database Restart, Network, Queryที่ช้าหรือใหญ่, Network Read/Write Timeout, Packet Size หรือ Connection Pool/Wrapper.

จำ Flow นี้ไว้:


Error 2013
↓
Database ยังทำงานอยู่ไหม?
↓
ทุก Resource หรือ Resourceเดียว?
↓
Queryใหญ่หรือช้าหรือไม่?
↓
Remote Database หรือไม่?
↓
net_read_timeout
↓
net_write_timeout
↓
max_allowed_packet
↓
Database Wrapper / Pool
↓
แก้ Root Cause

สิ่งที่ comsiam แนะนำคืออย่าเริ่มแก้ Error2013ด้วยการเพิ่ม net_read_timeout, net_write_timeout และ max_allowed_packet พร้อมกัน เพราะถ้า Databaseเพิ่ง Restart การเพิ่ม Timeoutไม่ช่วย ถ้า Queryดึงข้อมูลหลายล้าน Rows การเพิ่ม Timeoutเพียงทำให้ Queryที่ออกแบบไม่ดีรันนานขึ้น และถ้า JSONโตจาก Bug การเพิ่ม Packet Limitก็เพียงเปิดทางให้ข้อมูลผิดโตต่อไป

อีกหลักที่ comsiam แนะนำคือให้แยก Scopeก่อนเสมอ: ถ้าทุก Resourceหลุดพร้อมกันให้ตรวจ MariaDB/Network แต่ถ้าเกิดเฉพาะ Character, Vehicle, Inventoryหรือ Houseหนึ่ง Recordให้ตรวจ Payloadของ Recordนั้น และถ้าเกิดเฉพาะ Queryหนึ่งให้ตรวจ Query Duration, Result Size และ Packetก่อนปรับ Global Database Configuration วิธีนี้จะหาต้นเหตุได้ตรงกว่า Restart Serverหรือเพิ่ม Limitsแบบสุ่ม