FiveM MySQL Got an Error Writing Communication Packets Error 1160 แก้อย่างไร? ตรวจ Network, net_write_timeout, Result Set และ Client ที่หยุดรับข้อมูล

August 17, 2026

ปัญหา FiveM MySQL/MariaDB ขึ้น Got an error writing communication packets หรือ Error 1160 หมายความว่า MariaDB กำลังพยายาม เขียนหรือส่งข้อมูลกลับไปยัง Client ผ่าน Database Connection แต่ Connection เกิดข้อผิดพลาด จนไม่สามารถส่งข้อมูลต่อได้

MariaDB กำหนด Error 1160, SQLSTATE 08S01 เป็น:


ER_NET_ERROR_ON_WRITE
Got an error writing communication packets

และเอกสาร MariaDB ระบุว่าสถานการณ์นี้บ่งบอกว่า Connection ระหว่าง Server กับ Client ถูก Abort โดยสาเหตุหนึ่งที่พบบ่อยคือ Client ยุติ Connection แบบผิดปกติ รวมถึงปัญหา Connection หรือ Packet สูญหาย/ผิดปกติ.

ใน FiveM ตัว Client ในที่นี้อาจเป็น:

Database Wrapper
FiveM Resource
Connection Pool
Database Connector
Service/API อื่นที่เชื่อม MariaDB
Admin Tool ที่ใช้ Database เดียวกัน

ตัวอย่าง Error:


ERROR 1160 (08S01):
Got an error writing communication packets

หรือ MariaDB Error Log อาจขึ้นข้อความในลักษณะ:


Aborted connection ...
(Got an error writing communication packets)

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

ดูว่า MariaDB กำลังส่งอะไร → Client ใดเป็นปลายทาง → Client ยังรับข้อมูลอยู่หรือไม่ → Result ใหญ่หรือไม่ → Network มีปัญหาหรือไม่ → ตรวจ net_write_timeout → ตรวจ Resource/Wrapper → แก้ Root Cause

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

MariaDB Error 1160 คือ:


1160
08S01
ER_NET_ERROR_ON_WRITE
Got an error writing communication packets

หมายถึง Server พบปัญหาระหว่างการ Write ข้อมูลออกไปยัง Connection ของ Client.

② คำว่า Writing หมายถึงใครเขียนให้ใคร

ในกรณีนี้:


MariaDB
↓
ส่ง Query Result
↓
Database Connection
↓
FiveM Database Client

คือ MariaDB กำลังส่งข้อมูลกลับไปยัง Client

③ ต่างจาก Error 1158 อย่างไร

Error 1158:


Got an error reading communication packets

คือ MariaDB มีปัญหาขณะ อ่านจาก Client

Error 1160:


Got an error writing communication packets

คือ MariaDB มีปัญหาขณะ ส่งกลับไปยัง Client.

④ ต่างจาก Error 1159 อย่างไร

Error 1159:


Got timeout reading communication packets

คือ Timeout ขณะ Server รออ่านข้อมูลจาก Client.

⑤ แล้ว Error 1161 คืออะไร

MariaDB กำหนด Error 1161 เป็น:


ER_NET_WRITE_INTERRUPTED
Got timeout writing communication packets

คือ Server ใช้เวลาส่งข้อมูลไปยัง Client นานเกิน Write Timeout.

⑥ จำชุดนี้ให้แม่น


1158 = Read Error
1159 = Read Timeout
1160 = Write Error
1161 = Write Timeout

MariaDB แยก Errors ทั้งสี่ออกจากกันชัดเจนใน Error Code Reference.

⑦ Error 1160 เป็น SQL Syntax Error หรือไม่

ไม่ใช่

SQL Syntax Error มักเป็น Error เช่น:


1064
1149

ส่วน 1160 เป็น Communication Error ระหว่าง MariaDB Server กับ Client.

⑧ Clear FiveM Cache ช่วยไหม

โดยทั่วไปไม่ใช่จุดแก้ เพราะปัญหาเกิดระหว่าง Database Server กับ Database Client ฝั่ง Server

⑨ Restart FiveM ช่วยไหม

อาจทำให้ Database Connections ถูกสร้างใหม่ จึงทำให้อาการหายชั่วคราว

แต่ถ้า:

Network ยังมีปัญหา
Resource ยังปิด Connection กลางงาน
Query Result ยังใหญ่มาก

Error สามารถกลับมาได้

⑩ Restart MariaDB ช่วยไหม

ไม่ควรเป็น First Fix

เพราะ Restart MariaDB เองจะตัด Connections ที่กำลังใช้งานทั้งหมด

⑪ MariaDB ระบุ Possible Cause อะไร

เอกสาร Error 1160 ระบุว่า Connection ระหว่าง Server กับ Client ถูก Abort และหนึ่งในสาเหตุทั่วไปคือ Client ยุติ Connection แบบ Hard Abort โดยไม่ได้ปิดอย่างเป็นระเบียบ รวมถึงปัญหาของ Connection เช่น Packet สูญหายหรือผิดปกติ.

⑫ FiveM ต้องเรียก `mysql_close()` เองไหม

ไม่ควรนำตัวอย่าง API ระดับ C จากเอกสาร MariaDB ไปใช้ตรง ๆ ใน Lua หรือ JavaScript

ถ้า FiveM ใช้ Database Wrapper ให้ Resource ใช้ Lifecycle ของ Wrapper นั้น

⑬ ตัวอย่างสถานการณ์ง่ายที่สุด

MariaDB กำลังส่ง Result:


MariaDB
↓
5000 rows
↓
FiveM database client

แต่ Client ถูกปิดก่อนรับข้อมูลครบ

MariaDB จึงเขียนต่อไม่ได้

⑭ Client ปิด Connection ทำไมได้บ้าง

ตัวอย่าง:

Resource Restart
FiveM Process Restart
Database Wrapper Restart
Application Crash
Network Connection Reset
Timeout ฝั่ง Client

⑮ Resource Restart เป็น Case สำคัญ

สมมติ Resource กำลัง Query:


SELECT *
FROM transactions
WHERE player_id = ?;

MariaDB เริ่มส่ง Rows กลับมา

แต่ Admin กด:


restart resource

ระหว่างนั้น

⑯ Client Side อาจหายทันที

MariaDB ยังพยายามส่ง Result

จึงอาจเกิด Write Communication Error ตาม Timing ของ Connection

⑰ Error ครั้งเดียวตอน Resource Restart ร้ายแรงไหม

บริบทต่างจาก Error ที่เกิดทุกไม่กี่นาทีขณะ Gameplay

ถ้าเกิดเฉพาะ:


resource restart
server shutdown
deployment

ให้ตรวจ Lifecycle ก่อน

⑱ Error เกิดตลอดระหว่าง Gameplay

ควรตรวจจริงจัง

เพราะอาจเป็น:

Connection instability
Network
Result Set ใหญ่
Client ไม่อ่าน Result ทัน
Wrapper problem

⑲ Resource Crash

ถ้า Lua/JS Resource หรือ Database Client Process ล้ม:

Connection อาจถูกปิดแบบไม่สมบูรณ์

⑳ ตรวจ FiveM Console ก่อนบรรทัด 1160

หา:


script error
resource stopped
exception
promise rejection
database wrapper error

㉑ อย่าดู MariaDB Log อย่างเดียว

Database อาจเป็นเพียงฝั่งที่รายงานว่า Client หาย

ต้นเหตุอาจเกิดใน FiveM ก่อนหน้านั้น

㉒ Remote Database เพิ่มความซับซ้อน

หาก FiveM และ MariaDB อยู่คนละ Host:


FiveM
↓
network
↓
MariaDB

Connection ต้องผ่าน Network จริง

㉓ Network Connection Reset

หาก Network ถูกตัด:

MariaDB อาจกำลังส่ง Result อยู่แต่ Client ไม่สามารถรับต่อ

㉔ Packet Loss เกี่ยวไหม

MariaDB ระบุ Connection/Packet ที่สูญหายหรือผิดปกติเป็น Possible Cause ของ Error 1160.

㉕ Ping ปกติไม่ได้พิสูจน์ว่า Database Connection สมบูรณ์

ICMP Ping กับ TCP Database Connection เป็นคนละ Connection Context

จึงควรดู:

DB Error Log
Network Metrics
FiveM Logs

ร่วมกัน

㉖ Localhost ก็เกิด 1160 ได้

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

Client Process ที่อยู่เครื่องเดียวกันก็สามารถปิด Connection ขณะ MariaDB กำลังเขียนได้

㉗ ดังนั้นคำว่า Communication Error ไม่ได้แปลว่า Internet เสียเสมอ

ถูกต้อง

Communication ในที่นี้หมายถึง MariaDB Client/Server Connection

㉘ `net_write_timeout` คืออะไร

MariaDB ใช้ net_write_timeout เป็นระยะเวลาที่ Server ยอมรอการเขียนข้อมูลไปยัง Client ก่อนถือว่า Write Operation ใช้เวลานานเกินไป

เอกสาร MariaDB Connector/J ระบุค่า Default ของ net_write_timeout ว่า 60 วินาที และอธิบายว่าหาก Client ไม่อ่าน Result Set ทั้งหมดภายในช่วงที่ Server คาดไว้ Connection อาจถูกยกเลิก.

㉙ ตรวจค่า `net_write_timeout`

ใช้:


SHOW VARIABLES LIKE 'net_write_timeout';

㉚ หรือ


SELECT @@net_write_timeout;

㉛ ถ้าได้ 60

เป็นค่าที่สอดคล้องกับ Default ที่ MariaDB Documentation ปัจจุบันอ้างถึงสำหรับ net_write_timeout.

㉜ ควรเพิ่ม 60 เป็น 600 ทันทีไหม

ไม่ควร

เพราะ Error 1160 คือ Write Error ไม่ใช่ Error 1161 ที่เป็น Write Timeout โดยตรง.

㉝ นี่เป็นจุดสำคัญมาก

ถ้า Error คือ:

อย่ารีบแก้:


net_write_timeout

เพียงเพราะคำว่า Writing

㉞ ถ้าเป็น 1161 ต่างหาก

จึงมีเบาะแสตรงมากขึ้นว่า Server รอ Write นานเกิน Timeout.

㉟ แต่ `net_write_timeout` ควรตรวจไหม

ควรตรวจประกอบถ้า:

Result Set ใหญ่มาก
Client อ่านช้า
Remote DB
มี Error 1161 ร่วมด้วย

㊱ Result Set ใหญ่เป็น Case สำคัญ

MariaDB Connector/J Documentation ระบุว่าการอ่าน Query ที่มี Result Set ใหญ่เป็นสถานการณ์ที่สามารถเกี่ยวข้องกับ net_write_timeout เพราะ Server คาดหวังให้ Client อ่าน Result ออกไปในเวลาที่เหมาะสม.

㊲ FiveM Query อะไรสร้าง Result ใหญ่ได้

ตัวอย่าง:

Logs
Phone Messages
Player Transactions
Inventory History
Business History
Vehicle History
Admin Search
Audit Logs

㊳ ตัวอย่าง Query ที่ควรระวัง


SELECT *
FROM logs;

ถ้า Table มีข้อมูลหลายล้าน Rows

㊴ FiveM Resource อาจไม่ต้องใช้ข้อมูลทั้งหมด

ถ้า UI แสดง:


50 logs ล่าสุด

ไม่จำเป็นต้องโหลด:


5,000,000 logs

㊵ ใช้ Query Scope ให้ถูก

เช่น:

WHERE
LIMIT
Pagination

ตาม Feature จริง

㊶ อย่าเพิ่ม LIMIT แบบสุ่ม

ถ้า Logic ต้องใช้ข้อมูลครบจริง

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

㊷ Phone Messages

สมมติ Resource เปิด Conversation หนึ่งอัน

ควร Queryข้อมูลที่เกี่ยวกับ Conversationนั้น

ไม่ใช่ Messages ทั้ง Server

㊸ Transaction History

หน้า Banking อาจแสดง:


20 รายการล่าสุด

ไม่จำเป็นต้องส่งประวัติหลายปีทั้งหมดทุกครั้ง

㊹ Admin Logs

เป็นหนึ่งใน Table ที่โตเร็วมากใน FiveM Server ที่เก็บ Events จำนวนมาก

㊺ `SELECT *` ไม่ผิดเสมอไป

ถ้า Feature ต้องใช้ทุก Column ก็ใช้ได้

แต่ถ้ามี LONGTEXT/JSON ใหญ่ที่ UI ไม่ใช้:

เลือกเฉพาะ Columns ที่ต้องการช่วยลด Result Size

㊻ ตัวอย่าง

แทน:


SELECT *
FROM characters;

ถ้าต้องการเพียง:


id
name
status

อาจ Queryเฉพาะ Columnsเหล่านั้น

㊼ Character Selection

หน้ารายการ Character อาจไม่ต้องโหลด Full Inventory/Metadata ทุกตัวพร้อมกัน

ขึ้นกับ Framework

㊽ Inventory JSON ใหญ่

ถ้า SELECT ส่ง Inventory JSON หลาย MB กลับ Client:

ทั้ง Network และ Clientต้องจัดการ Resultนั้น

㊾ Vehicle Properties

ถ้าดึงรถหลายพันคันพร้อม JSON Mods/Propertiesทั้งหมด:

Result Sizeสามารถเพิ่มมาก

㊿ Housing Furniture

Furniture JSONของหลาย Propertiesพร้อมกันอาจสร้าง Resultขนาดใหญ่

51. Phone Attachments

รูปภาพหรือ Base64 Dataยิ่งทำ Result Setโต

52. Base64 มีขนาดใหญ่กว่าข้อมูล Binary ต้นฉบับ

จึงควรระวัง Resource ที่ส่งรูป/Attachmentผ่าน Databaseเป็น Textขนาดใหญ่

53. ไม่ได้หมายความว่าต้องเปลี่ยน Phone Resourceทันที

ต้องดู Architectureจริง

54. Errorเฉพาะ Featureเดียว

ถ้า:


garage ปกติ
inventory ปกติ
bank ปกติ
admin logs error

ให้ตรวจ Admin Queryก่อน Global MariaDB Settings

55. Errorทุก Resourceพร้อมกัน

กลับกัน หากทุก Resource Errorพร้อมกัน:

สงสัย:

Wrapper
Network
MariaDB
Server restart

มากขึ้น

56. Database Wrapper

FiveM Resourcesจำนวนมากส่ง Queryผ่าน Wrapperกลาง

ถ้า Wrapperถูก Restart:

หลาย Resourcesอาจได้รับผลพร้อมกัน

57. Connection Pool

Poolรักษา Connectionsไว้สำหรับ Reuse

ถ้า Pool/Client Layerล้ม:

MariaDBอาจยังมี Connectionsที่กำลังส่งข้อมูลอยู่

58. อย่าสร้าง Poolใหม่ทุก Resourceโดยไม่มีเหตุผล

Database Connectionsทั้งหมดใช้ Capacityของ MariaDBร่วมกัน

59. Resourceหนึ่งเปิด Raw Connectionเอง

สามารถมี Lifecycleต่างจาก Wrapperหลัก

จึงอาจเกิด Errorเฉพาะ Resourceนั้น

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

ตรวจว่า Resource:

ใช้ Wrapperหลักไหม
เปิด Database Connectionเองไหม
Query Resultใหญ่มากไหม

61. Errorหลัง Update Resource

ตรวจ:

Changelog
Database Queries
Pagination
Connector Compatibility

62. Errorหลัง Update Database Wrapper

ตรวจ Resourcesเก่าที่อาจใช้ APIไม่เข้ากับ Versionใหม่

63. อย่าเปิด Wrapperเก่าและใหม่พร้อมกันแบบสุ่ม

นอกจากเพิ่ม Connectionsแล้ว ยังทำ Diagnosisซับซ้อนขึ้น

64. Errorตอน Player Login

Loginหนึ่งครั้งอาจโหลด:

Character
Vehicles
Inventory
Housing
Phone
Business

65. Login Storm

หลัง Restart Playersจำนวนมากเข้าเมืองพร้อมกัน

MariaDBอาจส่ง Result Setsจำนวนมากพร้อมกัน

66. Errorเฉพาะหลัง Restart Server

ควรตรวจ:

Login Burst
Resource Startup
Database Readiness

67. อย่าเพิ่ม net_write_timeoutก่อนรู้ว่า Clientอ่านช้าเพราะอะไร

Clientอาจยุ่งจาก:

CPU saturation
event loop blocked
resource crash

ก็ได้

68. JavaScript Resource

หาก Event Loop ถูก Blockหนัก:

Database Clientอาจประมวลผล Resultไม่ทันตาม Designได้

69. Lua Resource

Callback FlowหรือResource Lifecycleผิดก็สามารถสร้างปัญหาได้

70. แต่ 1160 เพียงตัวเดียวไม่พิสูจน์ว่า Lua/JS Codeผิด

ต้องดู StackและTiming

71. CPU สูงเกี่ยวไหม

ถ้า Database Clientไม่สามารถรับ/ประมวลผลข้อมูลได้ทัน:

System Loadอาจเป็นปัจจัยทางอ้อม

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

72. RAM ไม่พอ

ถ้า Client Processถูก OOM Kill:

MariaDB Connectionจะหายทันที

อาจมี Communication Errorsตามมา

73. ตรวจ OS Logsถ้าสงสัย Processถูก Kill

ไม่ควรเพิ่ม Database Timeoutเพื่อแก้ OOM

74. Disk I/O ช้า

สามารถทำ Application/DBช้าลง แต่ Error1160ไม่พิสูจน์ว่า Diskเป็น Root Cause

75. Remote DB Latency

Latencyสูงอย่างเดียวอาจยังใช้งานได้

ปัญหาหลักคือ Connectionต้องเสถียรและ Clientต้องอ่าน Resultต่อเนื่อง

76. Network Stall สำคัญกว่า Pingเฉลี่ยอย่างเดียว

ดู:

packet loss
reconnects
resets

77. Firewall/NAT

Remote Database Connectionอาจผ่าน:

Firewall
NAT
Security Appliance

ซึ่งสามารถมี Session Timeout/Reset Policies

78. Errorหลังเปลี่ยน Firewall

ถ้า 1160เริ่มหลัง Infrastructure Change:

Correlationควรถูกตรวจ

79. อย่าเปิด Database Portให้ Publicเพื่อแก้ Error

MariaDBควรถูกจำกัด Accessเฉพาะ Hostsที่จำเป็น

80. VPN/Tunnel

ถ้า Database Connectionวิ่งผ่าน VPNหรือTunnel:

Tunnel Restartสามารถทำ Connectionหาย

81. Errorทุกครั้งที่ VPN Reconnect

เป็นเบาะแสชัด

82. Databaseอยู่ Same Host

ถ้าใช้ localhost:

ตัด Network Internetภายนอกออกจาก Root Causesหลายส่วนได้

แล้วเน้น:

resource
process
wrapper
local system

83. Errorหลัง Resource Stop

เป็นหนึ่งในสถานการณ์ที่สอดคล้องกับ Client Abortมากที่สุด

เพราะ MariaDBเองระบุ Client Hard Abortเป็น Possible Causeของ1160.

84. Errorหลัง FiveM Crash

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

Applicationไม่มีโอกาสปิด Database Connectionตามปกติ

85. Errorตอน Graceful Shutdownน้อยกว่าไหม

ถ้า Wrapper/Clientปิด Connectionตาม Lifecycleอย่างถูกต้อง ย่อมลดโอกาส Abnormal Abortในเชิงออกแบบ

86. Productionควร Shutdownอย่างเป็นระเบียบ

โดยเฉพาะเมื่อมี:

Character Save
Banking
Inventory

กำลังทำงาน

87. อย่า Force Kill Processกลาง Transaction

นอกจาก Connection Errorแล้ว Player Dataอาจอยู่ใน Stateที่ต้องตรวจ

88. Error1160กับTransaction Integrity

1160เองไม่ได้บอกว่า SQL Transaction:

Commit
Rollback

แบบใดแล้ว

89. นี่สำคัญมากกับ Write Operations

ตัวอย่างซื้อรถ:


UPDATE money
INSERT vehicle
SELECT result

ถ้า Connectionหาย:

Applicationต้องรู้ Transaction Stateก่อน Retry

90. อย่า Retryทุก Queryแบบ Blind

โดยเฉพาะ:

INSERT
UPDATE
DELETE

ที่มี Side Effects

91. SELECT Retryง่ายกว่าหรือไม่

โดยทั่วไป Read Operationที่ไม่มี Side Effectsมีความเสี่ยงเรื่อง Duplicate Actionต่ำกว่า Write

แต่ Resourceควรใช้ Retry Policyของ Wrapper/Applicationจริง

92. Bankingต้องระวังมากที่สุด

Connection Errorไม่ควรทำให้:


ถอนเงินซ้ำ
โอนเงินซ้ำ

93. Vehicle Purchase

ต้องป้องกัน:

รถซ้ำ
เงินหักซ้ำ

94. Inventory Reward

ต้องป้องกัน:

Item Dupe
Rewardซ้ำ

95. Idempotency

ระบบที่สำคัญสามารถใช้ Transaction Reference/Unique Request Identifierเพื่อป้องกัน Requestเดียวถูกดำเนินการซ้ำ

แต่ขึ้นกับ Resource Architecture

96. อย่าเพิ่ม Columnเองใน Paid Resourceโดยไม่มี Migration

เพียงเพราะต้องการ Idempotency

97. Error1160หลัง Queryคืน Resultขนาดใหญ่

เป็น Caseที่ควรตรวจ net_write_timeoutร่วมด้วย เพราะ MariaDB Connector/J ระบุ Serverคาดหวังให้ Clientอ่าน Result Setออกไปค่อนข้างเร็ว และ net_write_timeoutควบคุมช่วงเวลานี้.

98. แต่ 1160ไม่เท่ากับ1161

ย้ำอีกครั้ง:


1160 = Write Error
1161 = Write Timeout

99. ถ้ามี1161ตามมา

นั่นทำให้ Timeoutเป็นเบาะแสที่แรงขึ้น

100. ถ้ามี2013ร่วม

Clientอาจรายงาน:


Lost connection to MySQL server during query

ใน Connection Incidentเดียวกันได้

แต่ต้องอ่าน Timeline

101. ถ้ามี2006ร่วม

Connectionหลังจากนั้นอาจไม่สามารถใช้ต่อได้

102. ถ้ามี1153ก่อนหน้า

ตรวจ:


max_allowed_packet

เพราะ Packetใหญ่เกินมี Errorเฉพาะ1153.

103. ถ้ามี1158ร่วม

ทั้ง ReadและWrite Communication Pathอาจมีปัญหา

104. Error Chain ตัวอย่าง


1153 packet too large
↓
connection disturbed
↓
1160 write error
↓
2013 lost connection

ในกรณีนี้อย่าแก้ net_write_timeoutอย่างเดียว

105. Errorแรกอาจสำคัญที่สุด

อ่าน Logก่อนและหลังเหตุการณ์อย่างน้อยช่วงสั้น ๆ

106. MariaDB Error Log

MariaDB สามารถเขียน Read/Write Connection Errors ลง Error Log ได้ตามระดับ log_warnings ที่ตั้งไว้ โดยเอกสารระบุระดับสูงกว่าสามารถบันทึกรายละเอียด Read/Write Errors ของ Connectionมากขึ้น.

107. Error Logอยู่ไหน

ตำแหน่งขึ้นกับ MariaDB Configuration/Environment

MariaDB Documentation ระบุว่าสามารถกำหนดไฟล์ผ่าน log_error; หากไม่ได้กำหนดชื่อเฉพาะ การจัดวางจะขึ้นกับ Configuration และ datadir ของระบบ.

108. อย่าเดา Pathไฟล์

เพราะ:

Linux
DirectAdmin
Docker
Managed DB

ต่างกัน

109. ดู Timestamp

เช่น FiveM:


16:25:10

และ MariaDB:


16:25:10

Correlationของเวลาเป็นเบาะแสสำคัญ

110. Timezoneต้องตรง

ถ้า FiveMกับDatabaseอยู่คนละ Region/Timezone:

แปลงเวลาให้ตรงก่อนเทียบ

111. ดู User/Hostใน Error Log

ถ้ามีหลาย Applicationsใช้ Databaseเดียวกัน:

จะช่วยหา Clientต้นทาง

112. FiveMอาจไม่ใช่ต้นเหตุ

Website/APIอาจเป็น Clientที่ถูก Abort

113. แยก Database Userต่อ Service

เช่น:


fivem_user
web_user
api_user

ช่วย ObservabilityและLeast Privilege

114. แต่ไม่ต้องเปลี่ยน Credentialsทันทีเพื่อแก้ Errorหนึ่งครั้ง

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

115. Error1160หมายความว่าโดน Hackไหม

ไม่

Errorนี้เพียงระบุ Communication Write Failure และ Client/Connection Abort เป็น Possible Cause ไม่ใช่หลักฐานการโจมตี.

116. ต้องเปลี่ยน Passwordไหม

ไม่ใช่ First Fix

Authentication Errorเช่น1045เป็นปัญหาคนละประเภท

117. max_connectionsเกี่ยวไหม

ไม่ใช่ Errorเดียวกัน

Connectionsเต็มจะมี Error1040

118. แต่ High Connection Loadอาจทำระบบโดยรวมหนัก

จึงควรดู Metricsถ้ามี Errorsหลายกลุ่มร่วมกัน

119. max_allowed_packetเกี่ยวไหม

เฉพาะเมื่อมี Query/Result/Payloadใหญ่หรือ Errorเกี่ยวกับ Packetร่วม

ไม่ควรเพิ่มเพราะ1160อย่างเดียว

120. net_read_timeoutเกี่ยวไหม

ไม่ใช่ Directionหลักของ1160

net_read_timeoutคือ Serverรอรับข้อมูลจาก Client

1160คือ Serverกำลัง Writeไป Client

121. net_write_timeoutจึงเกี่ยวกว่าใน Direction

แต่1160ยังคงไม่ใช่ Timeout Codeโดยตรง

122. Error1161คือ Timeout Codeโดยตรง

ดังนั้นถ้าเห็น1161:

ตรวจ net_write_timeoutเป็นพิเศษ.

123. Query Result Setใหญ่

MariaDB Connector/J Documentation ชี้ว่าการอ่าน Result Setขนาดใหญ่สามารถทำให้ Serverรอ Client consume Resultนาน และหาก Clientไม่อ่านครบภายใน net_write_timeout Connectionอาจถูก discard.

124. FiveM Admin Logsเป็นตัวอย่างเด่น

ถ้า Admin เปิด Pageเดียวแล้วดึง:


ทุก log ตั้งแต่เปิด server

ควรตรวจ Query Design

125. Pagination

เหมาะกับข้อมูลอย่าง:

logs
messages
transaction history

เมื่อ UIไม่ได้แสดงทุก Rowพร้อมกัน

126. LIMIT

ใช้เมื่อ Business Logicต้องการจำนวนจำกัดจริง

127. WHERE

จำกัดข้อมูลให้ Player/Resourceที่เกี่ยว

128. Index

Queryที่ Scopeถูกแต่ช้ามากอาจต้องตรวจ Indexตาม Queryจริง

129. อย่าเพิ่ม Indexสุ่ม

เพราะ Indexทุกตัวมี Costกับ Writes/Storage

130. SELECT * จาก Tableใหญ่

อาจทำให้:

Resultใหญ่
Networkสูง
Client Memoryสูง

131. เลือก Columnsเท่าที่ใช้

หาก Featureไม่ต้องใช้ JSONใหญ่

132. Example Admin Player List

อาจต้องเพียง:


identifier
name
online status

ไม่จำเป็นต้องดึง:


inventory
appearance
metadata

ของทุกคนพร้อมกัน

133. Inventory Admin Search

ถ้าต้องค้น Item:

อาจ Queryเฉพาะ Item/Playerที่เกี่ยว

แทนโหลด Inventoriesทุกคนมาที่ Lua

134. Databaseควรทำ Filteringเมื่อเหมาะสม

ลดข้อมูลที่ส่งออก

135. แต่ Queryต้องใช้ Index/Schemaให้เหมาะ

ไม่ใช่ย้าย Logicทั้งหมดเข้า SQLแบบสุ่ม

136. Error1160เฉพาะ Playerเดียว

ตรวจ:

Player data
Result size
Feature

137. Errorทุก Player

ตรวจ:

wrapper
network
core query

138. Errorเฉพาะ Houseเดียว

Furniture Resultอาจใหญ่ผิดปกติ

139. Errorเฉพาะ Vehicleหนึ่งคัน

Propertiesอาจผิดปกติ

140. Errorเฉพาะ Phone Account

Messages/Attachment Dataอาจโตมาก

141. Errorเฉพาะ Admin Page

Query Result Setมีโอกาสเป็นต้นเหตุ

142. Errorเฉพาะตอน Backup

Backup Clientก็เป็น MariaDB Client

ถ้า Backup Processถูกหยุดหรือ Connectionเสีย MariaDBอาจเห็น Write Communication Errorได้ในเชิง Client/Server Communication

143. อย่าแก้ FiveMถ้า ErrorเกิดจากBackup Process

ดู Host/User/Timing

144. Errorเฉพาะตอน SQL Export

Clientปลายทางอาจอ่านข้อมูลไม่ทันหรือถูกปิด

145. MariaDB Documentation มีคำแนะนำในบริบท Large Data Transfers

เอกสารบางส่วนของ MariaDB ระบุว่าการโหลดข้อมูลขนาดใหญ่บางกรณีอาจต้องพิจารณาเพิ่ม net_read_timeout และ net_write_timeout เมื่อ Workloadต้องใช้เวลามากขึ้นจริง.

146. แต่นี่ไม่ใช่คำแนะนำให้เพิ่มทุก Server

เป็นคำแนะนำเฉพาะกรณี Large Data Transfer

147. Runtime FiveM Queryปกติควรใช้เวลา60วินาทีเพื่อรับ Resultไหม

ถ้า Gameplay Queryทั่วไปต้องส่ง Resultนานมากขนาดนั้น:

ควรตรวจ Query/Result Sizeก่อน

148. Queryช้าที่ Databaseกำลังประมวลผลกับ Clientอ่านช้าคนละเรื่อง

net_write_timeoutเกี่ยวกับช่วง Serverส่งข้อมูลไป Client

ไม่ได้แปลว่า Query Execution Timeoutทั้งหมด

149. Slow Query Optimizationยังสำคัญ

ถ้า Queryใช้เวลานานก่อนเริ่มส่ง Result:

ตรวจ Execution Plan/Indexes

150. Query Result Processingก็สำคัญ

ถ้า Resultออกมาแล้วมหาศาล:

ลดข้อมูลที่ต้องส่ง

151. Errorหลัง Server Playersเพิ่ม

อาจเป็น Queryที่ Scaleตาม Player Count

ตัวอย่าง:


SELECT all player data

ทุกครั้งที่ Resourceทำงาน

152. Players20คนผ่าน

Players500คน Resultโตมาก

153. เพิ่ม net_write_timeoutอาจซื้อเวลา

แต่ Query Designยัง Scaleไม่ดี

154. Fixระยะยาว

โหลดเฉพาะข้อมูลที่ Featureต้องการ

155. Errorหลัง Database Tableโต

เช่น Logs Tableโตปีต่อปี

Queryเดิมเริ่ม Return Dataมากขึ้น

156. Retention Policyช่วยได้ไหม

สำหรับ Debug Logsบางประเภทอาจช่วย

แต่ต้องเป็น Policyของ Server

157. Banking Historyไม่ควรถูกลบเหมือน Debug Logs

Data Semanticsต่างกัน

158. Error1160หลัง Network Migration

ตรวจ:

new route
firewall
NAT
proxy

ถ้า Errorเริ่มหลัง Infrastructure Change

159. Errorหลังย้าย MariaDBไป Remote VPS

ตรวจ Network StabilityและLatency

160. Errorหลังย้าย FiveMไป Hostใหม่

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

161. Errorหลังเปิด Proxy

ถ้ามี Database Proxyจริง:

Proxyมี Timeout/Bufferของตัวเองได้

162. อย่าปรับ Proxyถ้า Architectureไม่มี

รู้ Stackก่อนแก้

163. Errorหลังเปิด TLS

อย่าปิด Encryptionทันที

ตรวจ:

certificate
network
connector configuration

ก่อน

164. Securityไม่ควรถูกลดเพื่อแก้ Communication Error

ใช้ Diagnosisก่อน

165. Quick Troubleshooting Flow


Error 1160
↓
เกิด Resourceไหน?
↓
เกิดตอน Restart/Crashหรือไม่?
↓
Local หรือ Remote DB?
↓
Result Setใหญ่ไหม?
↓
มี 1161 ร่วมไหม?
↓
ตรวจ net_write_timeout
↓
ดู MariaDB Error Log
↓
ดู FiveM Console
↓
ตรวจ Wrapper / Network / Query
↓
แก้ Root Cause

166. ถ้าเกิดครั้งเดียวตอน Restart

ตรวจ Resource Lifecycleก่อน

167. ถ้าเกิดตลอด Gameplay

ตรวจ Query/Network/Wrapperจริงจัง

168. ถ้าเกิดเฉพาะ Resultใหญ่

ลด Result Sizeหรือปรับ Queryก่อน

169. ถ้ามี1161

ตรวจ Clientอ่าน Resultช้าและ net_write_timeout

170. ถ้ามี1153

ตรวจ max_allowed_packet

171. ถ้ามี1158/1159

ตรวจ Read Sideด้วย

172. ถ้ามี2006

Connectionต่อมาอาจถูกใช้งานต่อไม่ได้

173. ถ้ามี2013

Clientอาจสูญเสีย Connectionกลาง Query

174. ถ้ามี1040

ตรวจ Connection Capacityแยก

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

เพิ่มทุก Timeoutพร้อมกัน
เพิ่ม max_allowed_packetสุ่ม
Restart MariaDBทุกครั้ง
Clear FiveM Cache
เปิด Port Databaseให้ Public
Retry Writesไม่จำกัด
ลบ Player Data

176. FiveM Error 1160 FAQ

FiveM `Got an error writing communication packets` คืออะไร

MariaDB Error1160 / SQLSTATE08S01 / ER_NET_ERROR_ON_WRITE หมายถึง Serverเกิด Errorขณะเขียน Communication Packetsไปยัง Client.

สาเหตุที่ MariaDB ระบุมีอะไร

เอกสารระบุ Connection Abort โดย Clientเป็นสาเหตุทั่วไป รวมถึง Connection/Packet Problems.

Error1160กับ1158ต่างกันอย่างไร

1158คือ Read Error ส่วน1160คือ Write Error.

Error1160กับ1159ต่างกันอย่างไร

1159คือ Read Timeout ส่วน1160คือ Write Error.

Error1160กับ1161ต่างกันอย่างไร

1160คือ Write Error ส่วน1161คือ Write Timeout.

`net_write_timeout` คืออะไร

เป็น Server Variableที่เกี่ยวกับระยะเวลาที่ MariaDBรอการส่งข้อมูลไปยัง Client โดยเอกสาร Connector/J ปัจจุบันระบุ Default 60วินาที.

ดูค่าอย่างไร


SHOW VARIABLES LIKE 'net_write_timeout';

เพิ่ม net_write_timeoutช่วยไหม

มีเหตุผลเมื่อ Clientต้องใช้เวลารับ Resultมากขึ้นจริง โดยเฉพาะ Result Setใหญ่ แต่ไม่ควรเป็น First Fixของ Error1160ทุกกรณี

ตั้งเป็น600ดีไหม

ไม่มีค่าที่เหมาะกับ FiveMทุก Server

ต้องดู Workloadจริง

Result Setใหญ่เกี่ยวไหม

เกี่ยวได้ MariaDB Connector/J ระบุ Clientที่อ่าน Result Setขนาดใหญ่ช้าอาจเกี่ยวกับ net_write_timeout.

Admin Logsเกี่ยวไหม

ควรตรวจหาก Queryคืน Logsจำนวนมากมาก

Phone Messagesเกี่ยวไหม

ได้ในเชิง Result Sizeถ้า Resourceดึงประวัติขนาดใหญ่เกินที่ต้องใช้

Inventoryเกี่ยวไหม

ถ้าดึง Inventories/Metadataจำนวนมากพร้อมกัน Resultอาจใหญ่

Housingเกี่ยวไหม

Furniture JSONจำนวนมากสามารถเพิ่ม Result Size

Vehicle Propertiesเกี่ยวไหม

การดึงรถจำนวนมากพร้อม Propertiesขนาดใหญ่ควรถูกตรวจ

Resource Restartเกี่ยวไหม

ได้ในเชิง Client Lifecycle เพราะ MariaDBระบุ Client Hard Abortเป็น Possible Causeของ Error1160.

FiveM Crashเกี่ยวไหม

เป็นไปได้เช่นกัน เพราะ Client Connectionอาจหายโดยไม่ปิดตามปกติ

Remote Databaseเกี่ยวไหม

เกี่ยวได้เพราะ Networkอยู่ระหว่าง ClientกับServer และ MariaDBระบุ Connection/Packet Problemเป็น Possible Cause.

Localhostเกิดได้ไหม

ได้ เพราะ Client Processสามารถยุติ Connectionผิดปกติได้แม้อยู่ Hostเดียวกัน

Pingปกติแปลว่า Networkไม่เกี่ยวไหม

ไม่ เพราะ PingกับDatabase TCP Connectionเป็นคนละ Traffic

Clear FiveM Cacheช่วยไหม

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

Restart FiveMช่วยไหม

อาจ Reset Connectionsชั่วคราวแต่ไม่แก้ Root Cause

Restart MariaDBช่วยไหม

ไม่ใช่ First Fixและจะตัด Connectionsอื่นทั้งหมด

ต้องเพิ่ม max_allowed_packetไหม

เฉพาะเมื่อมีหลักฐาน Packet/Resultขนาดใหญ่หรือ Error1153ร่วม

ต้องเพิ่ม net_read_timeoutไหม

ไม่ใช่ Directionหลักของ1160

Error1160หมายถึงโดนแฮ็กไหม

ไม่ใช่หลักฐานการถูกแฮ็ก

ต้องเปลี่ยน Passwordไหม

ไม่ใช่ First Fix

ต้องเปิด Port3306เพิ่มไหม

ไม่

Errorหลัง Resource Updateทำอย่างไร

ตรวจ Changelog, Database Wrapper Compatibilityและ Query Result Size

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

ตรวจ Network Path, Firewallและ Database Connection Configuration

Errorหลัง Server Restartทำอย่างไร

ตรวจ Resource Startup/Login Burst และ Connection Lifecycle

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

ตรวจ Data/Resultของ Playerนั้นเทียบกับ Playerปกติ

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

ตรวจ Core Resource, Wrapperและ Infrastructure

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

ตรวจ Queryที่อาจดึง Resultจำนวนมาก

Errorตอน Backupทำอย่างไร

ตรวจ User/Hostใน MariaDB Logเพื่อแยกว่าเป็น Backup Clientหรือ FiveM

ต้อง Reinstall MariaDBไหม

ไม่ควรเป็น First Fix

ต้องลบ Databaseไหม

ไม่

ต้อง Backupไหม

หากจะเปลี่ยน:

Data
Schema
Migration
Player Records

ควร Backupก่อน แต่การตรวจ Logs/Timeoutไม่ต้องลบข้อมูล

สรุป FiveM MySQL Got an Error Writing Communication Packets Error 1160

FiveM MySQL/MariaDB Error 1160 Got an error writing communication packets หมายถึง MariaDB เกิดปัญหาขณะส่งข้อมูลกลับไปยัง Client โดย Error นี้คือ ER_NET_ERROR_ON_WRITE, SQLSTATE 08S01 และ MariaDB ระบุ Client Connection ที่ถูก Abort รวมถึง Connection/Packet Problems เป็น Possible Causes.

จำความแตกต่างให้ได้:


1158 = Read Error
1159 = Read Timeout
1160 = Write Error
1161 = Write Timeout

และใช้ Flow นี้:


1160
↓
Resource ไหน?
↓
Client ถูก Restart/Crash หรือไม่?
↓
Local / Remote DB?
↓
Result Set ใหญ่ไหม?
↓
มี 1161 หรือไม่?
↓
ตรวจ net_write_timeout
↓
ดู MariaDB Error Log
↓
ตรวจ FiveM Wrapper / Network / Query
↓
แก้ Root Cause

สิ่งที่ comsiam แนะนำคืออย่าเพิ่ม net_write_timeout ทันทีเพียงเพราะ Error มีคำว่า Writing เพราะ 1160 เป็น Write Communication Error ส่วน Write Timeout มี Error1161แยกต่างหาก หาก1160เกิดหลัง Resource Restartหรือ FiveM Crash ให้ตรวจ Client Lifecycleก่อน แต่ถ้าเกิดตอน Queryที่คืน Resultใหญ่ ให้ตรวจ Query Scope, Result Size และ net_write_timeoutร่วมกัน.

อีกหลักที่ comsiam แนะนำคือหาก Errorเกิดกับ Logs, Phone, Inventoryหรือ Admin Search ให้ตรวจว่ากำลังส่งข้อมูลมากเกินความจำเป็นหรือไม่ เพราะ MariaDBระบุว่า Clientที่รับ Result Setขนาดใหญ่ช้าอาจชนพฤติกรรมที่ควบคุมโดย net_write_timeout; การลด Resultด้วย WHERE, LIMIT, Paginationหรือเลือกเฉพาะ Columnsที่ใช้จริงมักยั่งยืนกว่าการเพิ่ม Timeoutอย่างเดียวเมื่อ Queryถูกออกแบบไม่ดี