FiveM MySQL Result String Is Longer Than max_allowed_packet Error 1162 แก้อย่างไร? ตรวจ SQL Result, JSON, TEXT และ Query ที่สร้างข้อมูลใหญ่เกิน

August 17, 2026

ปัญหา FiveM MySQL/MariaDB ขึ้น Result string is longer than 'max_allowed_packet' bytes หรือ Error 1162 หมายความว่า MariaDB กำลังสร้างหรือจัดการ Result String ที่มีขนาดใหญ่เกินค่าที่ max_allowed_packet อนุญาต โดย MariaDB Error Code Reference ระบุ Error 1162 พร้อมข้อความนี้โดยตรง.

ตัวอย่าง:


ERROR 1162:
Result string is longer than 'max_allowed_packet' bytes

ใน FiveM ปัญหานี้อาจสัมพันธ์กับ Resource ที่จัดการข้อมูลขนาดใหญ่ เช่น:

JSON
Inventory
Character Metadata
Vehicle Properties
Housing Furniture
Phone Data
Logs
TEXT/LONGTEXT
BLOB
SQL Expression ที่ประกอบ String ขนาดใหญ่
Query ที่รวมข้อมูลจำนวนมากเข้าด้วยกัน
Stored Function หรือ SQL Function ที่สร้าง Result ขนาดใหญ่

MariaDB กำหนด max_allowed_packet เป็น ขนาดสูงสุดเป็น Bytes ของ Packet หรือ Generated/Intermediate String และระบุว่าควรกำหนดค่าให้รองรับ BLOB ที่ใหญ่ที่สุดซึ่งระบบจำเป็นต้องจัดการ.

ดังนั้นหลักการแก้ที่ถูกต้องคือ:

หา Query → ดูว่า Result String ใหญ่จากอะไร → วัดขนาด Data → ตรวจ max_allowed_packet → ตรวจว่า Resource สร้างข้อมูลใหญ่ผิดปกติหรือไม่ → แก้ Root Cause ก่อนเพิ่ม Limit

① Error 1162 คืออะไร

MariaDB Error Code 1162 ใช้ข้อความ:


Result string is longer than 'max_allowed_packet' bytes

โดยตรง.

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

หัวข้อก่อนหน้า Error 1153 คือ:


Got a packet bigger than 'max_allowed_packet' bytes

เน้น Packet ที่ส่งผ่าน Connection ใหญ่เกิน Limit

ส่วน 1162 คือ:


Result string is longer than 'max_allowed_packet' bytes

เน้น String Result ที่มีขนาดเกิน Limit.

③ จำง่าย ๆ


1153 = Packet ใหญ่เกิน
1162 = Result String ใหญ่เกิน

④ แล้ว Error 1301 ล่ะ

MariaDB มี Error 1301 อีกตัว:


Result was larger than max_allowed_packet - truncated

จึงต้องอ่าน Error Code และข้อความให้ครบ เพราะ 1153, 1162 และ 1301 ล้วนเกี่ยวข้องกับ max_allowed_packet แต่เป็นคนละสถานการณ์.

⑤ `max_allowed_packet` คืออะไร

MariaDB ระบุว่า Variable นี้ควบคุมขนาดสูงสุดของ:

Packet
Generated String
Intermediate String

เป็น Bytes.

⑥ ตรวจค่าปัจจุบันอย่างไร

ใช้:


SHOW VARIABLES LIKE 'max_allowed_packet';

หรือ:


SELECT @@max_allowed_packet;

⑦ ค่าแสดงเป็น Bytes

ตัวอย่าง:

16777216

หมายถึงประมาณ:


16 MB

⑧ อย่าเห็น 16777216 แล้วเปลี่ยนทันที

ต้องรู้ก่อนว่า Query ที่ Error กำลังสร้าง Result ขนาดเท่าไร

⑨ FiveM เจอ Error 1162 บ่อยกว่า 1153 ไหม

โดยลักษณะของ Error แล้ว 1153 มักตรงกับ Payload/Packet ที่ใหญ่เกินได้ง่ายกว่า ส่วน 1162 มีความเฉพาะกับ Result String ที่ MariaDB กำลังสร้างมากกว่า

ดังนั้นถ้า FiveM Console ระบุ 1162 จริง ให้ตรวจ Query หรือ SQL Expression ที่สร้าง String ขนาดใหญ่เป็นพิเศษ

⑩ JSON เกี่ยวได้อย่างไร

FiveM Resources จำนวนมากสามารถเก็บ State เป็น JSON เช่น:


inventory
metadata
vehicle properties
appearance
furniture

หาก Query นำ JSON หลายส่วนมารวมเป็น String ขนาดใหญ่มาก Result อาจเติบโตจนชน Limit

⑪ BLOB/TEXT เกี่ยวอย่างไร

MariaDB เตือนว่าการทำงานกับ BLOB หรือ TEXT ขนาดใหญ่มากอาจเกิน max_allowed_packet.

⑫ LONGTEXT ใหญ่มากก็ไม่ได้แปลว่าปลอดภัย

MariaDB ระบุว่า LONGTEXT สามารถมี Capacity สูงมาก แต่การส่งค่าขนาดใหญ่มากยังติดข้อจำกัด max_allowed_packet และสำหรับค่าที่ใหญ่มากอาจต้องพิจารณาวิธีส่งข้อมูลเป็นส่วน ๆ ตาม Connector ที่รองรับ.

⑬ Column Capacity กับ Packet Limit เป็นคนละเรื่อง

ตัวอย่าง:


LONGTEXT

อาจรองรับค่าขนาดใหญ่ใน Schema

แต่:


max_allowed_packet

ยังสามารถเป็นข้อจำกัดตอนประมวลผลหรือรับส่งข้อมูล

⑭ Error 1406 จึงไม่เหมือน 1162

1406


Data too long for column

คือ Column รองรับข้อมูลไม่พอ

1162


Result string is longer than max_allowed_packet

คือ Result String ใหญ่เกิน Packet/String Limit

⑮ เปลี่ยน VARCHAR เป็น LONGTEXT ช่วย 1162 ไหม

ไม่จำเป็น

ถ้า Root Cause คือ Result String ใหญ่กว่า max_allowed_packet:

การขยาย Column อย่างเดียวไม่ได้แก้ Limit นี้

⑯ Query ที่สร้าง Result String ใหญ่

ควรตรวจ SQL ที่:

รวม Strings
Aggregate Data
Generate JSON
Return Large TEXT
Return Large BLOB

⑰ ตัวอย่างเชิงแนวคิด

Resource อาจต้องการข้อมูล Player หนึ่งคน

แต่ Query กลับรวมข้อมูล Players ทั้ง Server

⑱ Result จึงโตผิดปกติ

เช่นต้องการ:


character_id = 50

แต่ลืม Filter

⑲ Query Scope สำคัญ

ตรวจ:

WHERE
JOIN conditions
Player ID
Character ID

⑳ Missing WHERE อันตรายมาก

Query ที่ควร Scope Player เดียวอาจอ่านข้อมูลทุก Player

㉑ ตัวอย่าง

ตั้งใจ:


SELECT metadata
FROM characters
WHERE id = ?;

แต่ Code กลายเป็น:


SELECT metadata
FROM characters;

㉒ ถ้า Resource นำ Result ทั้งหมดมารวม

String สามารถใหญ่ขึ้นอย่างรวดเร็ว

㉓ อย่าเพิ่ม Packet เพื่อรองรับ Missing WHERE

แก้ Query

㉔ Phone Resource เป็นตัวอย่าง

Resource ต้องการ Messages ของ:


phone_number = X

แต่ Queryผิดจนอ่าน Messagesของทุกคน

㉕ Result Size อาจมหาศาล

โดยเฉพาะ Serverเปิดมานาน

㉖ Logs Resource ก็เช่นกัน

Admin ต้องการ:


50 logs ล่าสุด

แต่ Resourceไปอ่าน:


all logs

㉗ Table ล้าน Rows

Resultอาจ:

ใหญ่มาก
ช้า
ใช้ RAMมาก

แม้ไม่ชน1162ทุกครั้ง

㉘ LIMIT ช่วยได้ไหม

ถ้า Featureต้องการเฉพาะบางรายการ:

ควร Queryเฉพาะจำนวนที่ต้องใช้

แต่ห้ามเพิ่ม LIMITแบบสุ่มถ้า Logicต้องใช้ข้อมูลครบจริง

㉙ Pagination เป็นทางออกที่ดีเมื่อข้อมูลต้องแสดงทีละหน้า

เช่น:

Phone history
Transaction logs
Admin logs

㉚ ไม่ต้องโหลดทุกอย่างครั้งเดียว

ถ้า UIแสดงเพียง:


20 รายการ

㉛ FiveM Inventory

ถ้า Resourceเก็บ Inventoryเป็น JSONใหญ่:

ควรดูขนาด JSONจริง

㉜ Item Metadata สามารถทำ Data โต

โดยเฉพาะ Metadataที่มี:

History
Nested JSON
Base64
Duplicate structures

㉝ ตัวอย่าง Data Growth

Save ครั้งแรก:


10 KB

ครั้งที่สอง:


20 KB

ครั้งที่สาม:


40 KB

ทั้งที่ Inventoryจริงไม่ได้เพิ่ม

นี่เป็นสัญญาณ Bug

㉞ อย่าเพิ่ม max_allowed_packet เพื่อรองรับการโตแบบนี้

ต้องหา:

Serialization Bug
Append Bug
Duplicate Metadata

㉟ Double Encode

ข้อมูล:


{"item":"water"}

ถูก Encodeซ้ำอาจกลายเป็น Stringที่มี Escape Charactersจำนวนมาก

㊱ Saveซ้ำหลายครั้ง

Stringอาจซับซ้อนขึ้นเรื่อย ๆ

㊲ ตรวจก่อน/หลัง Save

บน Development:


Length ก่อน Save
Length หลัง Save

㊳ ถ้าขนาดเพิ่มโดยไม่มี Dataใหม่

พบเบาะแสสำคัญแล้ว

㊴ Character Metadata

Frameworkหรือ Custom Resourceอาจเพิ่ม Fieldsเรื่อย ๆ

㊵ Metadataควรเป็น Current StateหรือHistory

ต้องดู Resource Design

㊶ ถ้าต้องการ History

อาจเหมาะกับ Tableแยกมากกว่า JSONที่โตไม่มีที่สิ้นสุด

แต่ไม่ควร Rewrite Third-party Schemaเองโดยไม่ดู Official Migration

㊷ Vehicle Properties

รถหนึ่งคันอาจมี JSONสำหรับ:

mods
colors
extras
damage

㊸ ถ้า Vehicleหนึ่งคัน Error

เปรียบเทียบ JSONรถคันนั้นกับรถปกติ

㊹ ตัวอย่าง


Normal vehicle = 8 KB
Problem vehicle = 12 MB

ควรตรวจ Vehicle Dataก่อนปรับ Global Limit

㊺ Housing Furniture

บ้านหนึ่งหลังอาจมี Objectsจำนวนมาก

Resourceอาจจัด Furnitureเป็น JSON

㊻ Object Duplication Bug

ถ้า Furnitureเดิมถูก Appendใหม่ทุก Save:

Dataจะโตเร็ว

㊼ Phone Social Data

Resourceบางระบบอาจมีข้อมูล:

posts
messages
contacts

จำนวนมาก

ควรตรวจว่า Queryกำลังคืนข้อมูลมากเกิน Featureต้องการหรือไม่

㊽ Base64 สำคัญ

หาก Resourceเก็บ:

Image
Avatar
Attachment

เป็น Base64 String:

ขนาดข้อมูลสามารถสูงกว่าการเก็บ Binaryต้นฉบับ

㊾ อย่าให้ Clientส่งรูปมหาศาลโดยไม่มี Limit

Serverควร Validate Payloadตาม Feature

㊿ Validation ต้องอยู่ Server

Client-side จำกัด Sizeอย่างเดียวไม่เพียงพอ

51. Resource ควร Whitelist Fields

ไม่ควรรับ Objectจาก Clientแล้ว Saveทั้งก้อนลง Databaseโดยตรง

52. ตัวอย่างผิด

Clientส่ง:


{
  "profile": "...",
  "everything": "..."
}

Server Serialize Objectทั้งหมด

53. Dataที่ไม่ควร Saveอาจเข้าฐานข้อมูล

และ Result/Payloadโตขึ้น

54. Database Errorจึงอาจเปิดเผย Security/Validation Problem

ไม่ใช่แค่ Performance

55. Bulk INSERTเกี่ยวกับ1162ไหม

Bulk INSERTใหญ่มากมักชี้ไป Packet 1153ได้ชัดกว่า

แต่ระบบที่ Generate/Manipulate Result Stringขนาดใหญ่ก็ต้องพิจารณา max_allowed_packet เช่นกัน.

56. Batch Operations

MariaDB Connector/Node.js Documentation เตือนว่า Batch Operations ถูกจำกัดโดย max_allowed_packet ของ Server.

57. Batch ใหญ่ที่สุดไม่ได้ดีที่สุด

Batch ใหญ่:

Queriesน้อยลง

แต่:

Packetใหญ่ขึ้น
Memoryสูงขึ้น
Transactionอาจใหญ่ขึ้น

58. Batch เล็กเกินก็ไม่ดีเสมอไป

Queriesจำนวนมากเพิ่ม Round Trips

ต้อง Balance

59. Logs มักแบ่ง Batch ได้ง่ายกว่า

เพราะ Log Entriesอาจไม่ได้ต้อง Atomicทั้งหมด

แต่ขึ้นกับ System

60. Banking ไม่ควร Copy Strategyจาก Logs

Money Transactionsมี Data Integrity Requirementsสูงกว่า

61. Query Result ใหญ่เพราะ JOIN

JOINผิดสามารถคูณจำนวน Rows

62. ตัวอย่าง

มี:


100 players

JOINผิดกับ:


1,000 logs

อาจสร้าง Resultจำนวนมหาศาล

63. Cartesian Product คือ Red Flag

ถ้า JOIN Conditionหาย:

Rowsสามารถคูณกัน

64. Result Stringอาจโตเร็วมาก

จึงควรตรวจ JOIN Conditions

65. Errorเกิดหลังแก้ SQL Query

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

ตรวจ Query Diffเป็นอันดับต้น ๆ

66. JOINเพิ่มใหม่

อาจเป็นสาเหตุ

67. GROUP/Aggregation Query

ถ้า Queryรวม Textจำนวนมากเป็น Resultเดียว:

ตรวจว่า Resourceตั้งใจจริงหรือไม่

68. อย่ารวม Logทั้งหมดเป็น Stringเดียว

ถ้า Applicationสามารถรับเป็น Rowsได้

69. Database Functionsที่สร้าง String

สามารถสร้าง Intermediate/Generated Strings และ MariaDBระบุ max_allowed_packet ครอบคลุม Generated/Intermediate Stringsด้วย.

70. นี่คือจุดต่างสำคัญจากแค่ Network Packet

เพราะ Variableนี้ไม่ได้จำกัดเฉพาะ Network Messageในนิยามของ MariaDB

71. Stored Function

Custom Databaseบาง Serverอาจใช้ Stored Functions

ถ้า Functionสร้าง Stringใหญ่:

อาจเกี่ยว

72. แต่ FiveMทั่วไปไม่จำเป็นต้องมี Stored Function

อย่าเริ่ม Debugตรงนี้ถ้า Schemaไม่มี

73. เริ่มจาก Queryของ Resourceก่อน

74. Resource Error Stackช่วยมาก

ดูว่า Errorเกิดจาก:

phone
inventory
housing
admin logs

75. Search Queryใน Source

ใช้:

Table name
Column name
SQL fragment

หา Caller

76. Closed-source Resource

ถ้ามอง Codeไม่ได้:

เก็บ:

Error
Resource version
Featureที่ Trigger
Data size

ส่ง Official Developer

77. อย่าส่ง Database Password

ไม่จำเป็น

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

ให้ตรวจ Recordของ Playerนั้น

79. Errorทุก Player

ให้ตรวจ Query/Schemaระดับระบบ

80. Errorเฉพาะ Playerเก่า

น่าสงสัย Accumulated Data

81. Errorเฉพาะ Playerใหม่

น่าสงสัย New Creation/Default Data

82. Errorหลัง Resource Update

อาจมี Fieldใหม่ที่ถูก Appendเข้า JSON

83. Updateใหม่อาจมี Migration

อ่าน Changelog

84. Code VersionกับSchema Versionต้องตรง

เหมือน Database Errorsก่อนหน้า

85. Errorหลัง Rollback Resource

Databaseอาจมีข้อมูลรูปแบบ Versionใหม่

Codeเก่า Serializeผิด

86. อย่า Rollbackโดยไม่มี Backup

โดยเฉพาะถ้ามี Schema/Data Migration

87. Errorหลัง Hosting Migration

Environmentใหม่อาจใช้ max_allowed_packet ต่างจากเดิม

88. ตรวจค่าทั้ง Serverเก่าและใหม่

ถ้ามีข้อมูล

89. แต่ไม่ควร Copy Configurationทั้งไฟล์

MariaDB VersionsและHardwareต่างกันได้

90. เปรียบเทียบค่าที่เกี่ยวโดยตรงก่อน

เช่น:


max_allowed_packet

91. Errorหลัง MariaDB Upgrade

ตรวจ Actual Variableหลัง Upgrade

อย่าคิดว่า Configurationเดิมถูก Loadเสมอ

92. MariaDB Option Files

MariaDBรองรับการตั้ง Server Optionsผ่าน Configuration/Option Files และค่าที่ถูกกำหนดซ้ำภายหลังสามารถ Overrideค่าก่อนหน้าได้.

93. แก้ Configแล้วไม่เปลี่ยน

อาจเพราะแก้ไฟล์ผิดตัว

94. Verifyทุกครั้ง


SHOW VARIABLES LIKE 'max_allowed_packet';

95. Runtime Valueคือ Source of Truth

ไม่ใช่ค่าที่เราเขียนไว้ในไฟล์อย่างเดียว

96. Client-side Limit

MariaDB Documentation ระบุว่าเมื่อเปลี่ยน max_allowed_packet ฝั่ง Server ควรพิจารณาฝั่ง Clientด้วยหาก Client Programมีการกำหนด Buffer/Limitที่เกี่ยวข้อง.

97. FiveM Database Wrapperอาจมีข้อจำกัดของตัวเอง

จึงต้องตรวจ Documentationของ Wrapper Versionจริง

98. อย่า Copy Settingจาก mysql CLI

ไปใส่ oxmysql/Resourceโดยตรงถ้า Optionนั้นไม่มี

99. Server Limitเพิ่มแล้ว Errorยังอยู่

ตรวจ:

Client limit
Resource bug
Payload growth
Error codeจริง

100. วัดขนาด Columnได้อย่างไร

สำหรับ String/Textสามารถใช้แนวคิด:


SELECT LENGTH(metadata)
FROM characters
WHERE id = ?;

101. `LENGTH()` มีประโยชน์

ใช้ตรวจขนาดเป็น Bytesโดยไม่ต้องดึง/แสดง JSONทั้งหมด

102. หา Recordใหญ่ผิดปกติ

แนวคิด:


SELECT id, LENGTH(metadata)
FROM characters
ORDER BY LENGTH(metadata) DESC
LIMIT 20;

เปลี่ยน Table/Columnตาม Serverจริง

103. Read-only Queryก่อน

ปลอดภัยกว่าการ DELETEข้อมูลทันที

104. ถ้า Top Recordใหญ่กว่าอันดับสองหลายร้อยเท่า

น่าสงสัย Data Corruption/Growth

105. ถ้าทุก Recordใหญ่ใกล้กัน

อาจเป็น Normal Resource Requirement

แล้วค่อยประเมิน Limit

106. ตรวจขนาด Resultเอง

อย่าดูแค่ Columnเดียว

Queryอาจรวมหลาย Columns/Rows

107. `SELECT *` อาจดึง Columnsที่ไม่ต้องใช้

เช่น:


id
name
status
large_json

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


id
name

108. เลือก Columnsที่ต้องการ

ช่วยลด Result Size

109. Phone Contacts

ไม่จำเป็นต้องดึง Message Historyพร้อม Contact Listหาก Applicationไม่ต้องใช้

110. Admin Player List

ไม่จำเป็นต้องดึง Inventory JSONของทุก Playerถ้าหน้าจอแสดงแค่ชื่อ

111. Character Selection

อาจไม่ต้องโหลด Full Character Stateทุก Slotทันที

ขึ้นกับ Framework

112. Optimize Data Loadingเป็นชั้น

แต่ไม่ควร Rewrite Frameworkจาก Guess

113. ตรวจ Official Updatesก่อน

Developerอาจแก้ Queryใน Versionใหม่แล้ว

114. Error1162หลัง Player Countเพิ่ม

อาจเกิดถ้า Queryรวมข้อมูลทุก Playerเข้าด้วยกัน

115. Example

20 Players:

Resultยังต่ำกว่า Limit

200 Players:

Resultเกิน Limit

116. นี่เป็นสัญญาณว่า Query Scaleไม่ดี

ไม่จำเป็นต้องหมายความว่า Packet Limitต่ำเกินไป

117. เพิ่ม Limitอาจซื้อเวลา

แต่ Playersโตอีก:

Errorกลับมา

118. Fixที่ยั่งยืน

ลด Resultตามข้อมูลที่ Featureต้องการจริง

119. Errorหลัง Tableโต

เหมือนกัน

Log Table:


10,000 rows → ผ่าน
10,000,000 rows → Error

ถ้า Queryไม่จำกัดข้อมูล

120. Cleanup Logsอย่างเดียวไม่ใช่ Root Fix

ถ้า Query Designยัง SELECTทั้งหมด

อีกไม่นาน Tableก็โตและ Errorกลับมา

121. ต้องมี Retention + Query Scope

ถ้า Systemต้องการ

122. Packet LimitกับMemory

Result/Stringขนาดใหญ่มากยังหมายถึง Application/Databaseต้องใช้ Memoryเพื่อจัดการข้อมูลนั้น

ดังนั้นการเพิ่ม Limitสูงมากไม่ควรถูกมองว่าไม่มี Cost

123. MariaDBแนะนำตั้ง Packetให้รองรับ BLOBที่จำเป็น

ไม่ใช่กำหนดสูงสุดเสมอ.

124. LONGTEXT สูงสุดใหญ่มาก

MariaDBระบุ LONGTEXTรองรับข้อมูลขนาดใหญ่มากและ Non-chunked Valuesที่เกิน 16Mสามารถต้องเพิ่ม max_allowed_packet โดยมีเพดานที่เอกสารระบุสูงถึง 1024M.

125. แต่นี่ไม่ใช่คำแนะนำให้ตั้ง 1GB

เป็นเพียง Capacityที่ระบบรองรับใน Contextดังกล่าว

126. FiveM Inventoryหลาย MBควรถูกตรวจก่อน

โดยเฉพาะถ้า Resourceอื่นไม่ใช้ขนาดนั้น

127. SQL Dump

Error1162ใน Runtimeกับ Dump Importเป็นคนละ Use Case

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

ตรวจ Dump/Import Process

128. `mariadb-dump`

MariaDBมี Utilityทางการสำหรับ Database Dump/Restore.

129. Dump Statementใหญ่

อาจชน Packet Limitsใน Workflowบางแบบ

130. ถ้า Runtimeปกติ

ไม่ต้องแก้ FiveM Scriptsเพราะ Import Errorอย่างเดียว

131. Error1162กับ2006

ถ้า Connectionถูกตัดตาม Error Chain:

อาจเห็น:


1162
↓
connection problem
↓
2006

ให้แก้ Errorต้นทางก่อน

132. Error1162กับ2013

หลักเดียวกัน

ถ้ามี 1162ชัดก่อน Lost Connection:

ตรวจ Result/Packet Sizeก่อน Network Guess

133. Error1162กับ1153

สองตัวนี้ควรดูคู่กันมากที่สุด


1153 = packet
1162 = result string

134. Error1162กับ1301

1301ระบุว่า Resultใหญ่กว่า max_allowed_packet และถูก Truncated.

135. Error1162 FAQ

FiveM Error 1162 คืออะไร

MariaDB Error1162ใช้ข้อความ Result string is longer than 'max_allowed_packet' bytes หมายถึง Result Stringมีขนาดใหญ่เกิน Limitที่กำหนด.

Error1162กับ1153ต่างกันอย่างไร

1153คือ Packetใหญ่เกิน ส่วน1162คือ Result Stringใหญ่เกิน max_allowed_packet.

max_allowed_packetคืออะไร

MariaDBกำหนดเป็นขนาดสูงสุดของ Packetหรือ Generated/Intermediate Stringเป็น Bytes.

ดู max_allowed_packetอย่างไร


SHOW VARIABLES LIKE 'max_allowed_packet';

เพิ่ม max_allowed_packetได้ไหม

ได้เมื่อ Workloadต้องรองรับ Result/Payloadขนาดนั้นจริง แต่ควรตรวจ Query/Dataก่อน

ตั้งเป็น1GBเลยดีไหม

ไม่ควรเป็น Default Fix แม้ MariaDBรองรับขนาดสูงมากในบาง Contextของ LONGTEXT/LONGBLOBก็ตาม.

LONGTEXTช่วยไหม

LONGTEXTเพิ่ม Column Capacity แต่ไม่ได้ลบข้อจำกัด max_allowed_packet; MariaDBระบุว่าข้อมูล BLOB/TEXTขนาดใหญ่อาจชน Limitนี้.

Inventory JSONทำ Errorได้ไหม

ถ้า Query/Result Stringที่ Resourceสร้างมีขนาดใหญ่มากก็เป็นสิ่งที่ควรตรวจ โดยเฉพาะเมื่อ Metadataโตผิดปกติ

Character Metadataทำได้ไหม

ได้ในเชิง Data Size หาก Resourceรวม/สร้าง Stringขนาดใหญ่มาก

Vehicle Propertiesทำได้ไหม

ควรตรวจถ้า Errorเกิดเฉพาะ Vehicleหนึ่งคันและ Propertiesมีขนาดผิดปกติ

Housing Furnitureทำได้ไหม

ควรตรวจถ้า Resourceรวม Objectsจำนวนมากเป็น JSON/Stringก้อนเดียว

Phone Dataทำได้ไหม

ควรตรวจ Query Scopeถ้า Resourceกำลังรวม MessagesหรือDataจำนวนมากเกิน Featureต้องใช้

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

เปรียบเทียบ LENGTH() ของ Recordนั้นกับ Playerปกติก่อนลบหรือแก้ Data

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

ตรวจ Queryระดับระบบ, Missing WHERE/JOINและ Resource Version

Errorเกิดหลัง Playerเพิ่มเยอะทำอย่างไร

ตรวจว่า Queryกำลังรวมข้อมูลทุก Playerหรือไม่ ไม่ควรเพิ่ม Limitอย่างเดียว

Errorเกิดหลัง Tableโตทำอย่างไร

ตรวจ WHERE, LIMIT, Paginationและ Query Scope

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

ตรวจ Changelog, Migrationและ Serialization/Data Structureที่เปลี่ยน

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

ตรวจค่า max_allowed_packet Environmentใหม่เทียบกับ Requirementจริง

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

ตรวจ Runtime Valueของ Variableและ Configuration Filesที่ถูก Loadจริง

Error1162กับ1301ต่างกันอย่างไร

MariaDB Error1301ระบุ Resultใหญ่กว่า max_allowed_packet และถูก Truncated ขณะที่1162ระบุ Result Stringยาวเกิน Limit.

Clear FiveM Cacheช่วยไหม

โดยทั่วไปไม่เกี่ยวกับ Server-side SQL Result String Size

Restart FiveMช่วยไหม

ไม่แก้ Queryหรือ Result Size

Restart MariaDBช่วยไหม

ไม่แก้ Resultที่ใหญ่เกิน Limit

Retry Queryช่วยไหม

หาก QueryและDataเท่าเดิมก็มีแนวโน้มเจอปัญหาเดิม จึงควรแก้ Query/Data/Configurationก่อน

ต้องลบ Characterไหม

ไม่ควร

ตรวจและ Backup Recordก่อน

ต้องล้าง Inventoryไหม

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

Double JSON Encodeเกี่ยวไหม

เกี่ยวได้ในเชิง Application Bug เพราะสามารถทำ Serialized Stringโตเกินความจำเป็น

Missing WHEREเกี่ยวไหม

มาก เพราะ Queryอาจอ่านข้อมูลมากกว่าที่ตั้งใจหลายเท่า

JOINผิดเกี่ยวไหม

ได้ เพราะ Joinที่ไม่ถูกต้องสามารถเพิ่มจำนวน Result Rowsอย่างมาก

SELECT *เกี่ยวไหม

ถ้ามี Columnsขนาดใหญ่ที่ Featureไม่ได้ใช้ การเลือกเฉพาะ Columnsที่จำเป็นสามารถลด Result Sizeได้

Prepared Statementแก้1162ไหม

ไม่ใช่ Fixของ Result String Sizeโดยตรง

Chunk Dataได้ไหม

MariaDB Connector/Cมี APIสำหรับส่ง Long Dataเป็น Chunks แต่การใช้งานจริงขึ้นกับ Connector/Database Wrapperที่ Resourceใช้ ไม่ควรนำ C APIไปดัดแปลง FiveM Scriptโดยตรง.

ต้อง Backupไหม

ควร Backupก่อน:

JSON Cleanup
Metadata Rewrite
Migration
Schema Changes

โดยเฉพาะข้อมูล Player Assets

สรุป FiveM MySQL Result String Is Longer Than max_allowed_packet Error 1162

FiveM MySQL/MariaDB Error 1162 Result string is longer than 'max_allowed_packet' bytes หมายถึง Result String ที่ MariaDB กำลังจัดการมีขนาดเกิน max_allowed_packet โดย MariaDBกำหนด Variableนี้เป็นขนาดสูงสุดของ Packet หรือ Generated/Intermediate String.

ให้ไล่ตรวจแบบนี้:


Error 1162
↓
Query ไหน?
↓
Result มาจาก Table/Column ไหน?
↓
มี WHERE / JOIN ถูกไหม?
↓
JSON / TEXT ใหญ่ผิดปกติไหม?
↓
วัด LENGTH
↓
ตรวจ max_allowed_packet
↓
แก้ Query / Data Growth
หรือ
เพิ่ม Limitเมื่อ Requirementต้องการจริง

สิ่งที่ comsiam แนะนำคืออย่ารีบเพิ่ม max_allowed_packet ไปถึงค่ามหาศาลเพียงเพื่อให้ Errorหาย เพราะหาก Resourceกำลัง SELECTข้อมูลเกิน Scope, JOINผิด, Serialize JSONซ้ำ หรือ Metadataโตทุกครั้งที่ Save การเพิ่ม Limitเป็นเพียงการเลื่อนเวลาที่ Errorจะกลับมา และ MariaDBเองระบุว่าค่านี้ครอบคลุมทั้ง Packetและ Generated/Intermediate String.

อีกหลักที่ comsiam แนะนำคือให้วัด Dataจริงก่อน หาก Playerปกติมี Metadataไม่กี่ KBแต่ Playerที่มีปัญหามีหลาย MB ให้แก้ Data/Resourceนั้นก่อน แต่ถ้าทุก Recordมีขนาดใหญ่ตาม Designจริงและ Queryถูก Scopeแล้ว จึงค่อยประเมินการเพิ่ม max_allowed_packet ให้รองรับ Workload พร้อมตรวจ Client/Database Wrapperด้วย เพราะ MariaDBแนะนำว่าหากปรับ Packet Sizeฝั่ง Server ก็ควรคำนึงถึง Limitฝั่ง Clientที่ใช้งานด้วย