FiveM MySQL Got a Packet Bigger Than max_allowed_packet Error 1153 แก้อย่างไร? ตรวจ JSON, Query ใหญ่ และ Packet Size ให้ถูกจุด

August 17, 2026

ปัญหา FiveM MySQL/MariaDB ขึ้น Got a packet bigger than 'max_allowed_packet' bytes หรือ Error 1153 เกิดเมื่อข้อมูลที่ Client และ Database กำลังรับส่งมี Packet ขนาดใหญ่กว่าค่า max_allowed_packet ที่ MariaDB อนุญาต

MariaDB กำหนด Error 1153, SQLSTATE 08S01 เป็น ER_NET_PACKET_TOO_LARGE พร้อมข้อความ:


Got a packet bigger than 'max_allowed_packet' bytes

โดยตรง.

ใน FiveM ปัญหานี้มักเกี่ยวข้องกับข้อมูลขนาดใหญ่ เช่น:

Inventory JSON
Character Metadata
Skin / Appearance
Vehicle Properties
Vehicle Mods
Housing Furniture
Property Objects
Phone Data
Large Logs
Bulk INSERT
SQL Dump
Migration
BLOB/TEXT
Query ที่รวมข้อมูลจำนวนมากไว้ใน Statement เดียว

สิ่งสำคัญคือ อย่าเห็น Error 1153 แล้วตั้ง max_allowed_packet เป็นค่าสูงสุดทันที เพราะบางครั้ง Packet ใหญ่ผิดปกติเกิดจาก Resource Bug เช่น JSON ถูก Encode ซ้ำ, Metadata โตไม่หยุด, Inventory Duplication หรือ Query รวม Rows มากเกินความจำเป็น

วิธีที่ถูกต้องคือ:

หา Query ที่ Error → วัดขนาดข้อมูล → ตรวจ max_allowed_packet → ตรวจว่าข้อมูลควรใหญ่ขนาดนั้นจริงหรือไม่ → แก้ Resource/Data Structure หรือเพิ่ม Limit เมื่อมีเหตุผล

① Error 1153 คืออะไร

MariaDB ระบุ Error 1153 ว่า:


1153
08S01
ER_NET_PACKET_TOO_LARGE
Got a packet bigger than 'max_allowed_packet' bytes

หมายถึง Packet ที่กำลังรับส่งมีขนาดเกินค่าที่ Database กำหนดไว้.

② `max_allowed_packet` คืออะไร

เป็น MariaDB Server Variable ที่จำกัดขนาดสูงสุดของ Packet หรือ Generated/Intermediate String บางประเภทที่ Database จะจัดการได้.

③ Packet คืออะไรแบบง่าย

FiveM Resource ไม่ได้ส่ง SQL ไป Database แบบไม่มีขนาด

ข้อมูลอย่าง:


SQL Query
Parameters
JSON
TEXT
BLOB

ต้องถูกส่งผ่าน Connection

ถ้าข้อมูลชุดหนึ่งใหญ่เกิน Limit:

Database สามารถ Reject ได้ด้วย Error 1153.

④ Error นี้เป็น Connection Error หรือไม่

Error 1153 ใช้ SQLSTATE 08S01 และ MariaDB จัดเป็น ER_NET_PACKET_TOO_LARGE; จึงเกี่ยวข้องกับการรับส่งข้อมูลผ่าน Connection มากกว่าปัญหา SQL Syntax.

⑤ ต่างจาก Error 1406 อย่างไร

Error 1406


Data too long for column

คือค่าที่จะเก็บยาวเกิน Column Capacity

Error 1153


Got a packet bigger than max_allowed_packet

คือ Packet ที่รับส่งใหญ่เกิน Limit

สองเรื่องนี้ไม่เหมือนกัน

⑥ Column ใหญ่มากก็ยังเจอ 1153 ได้

แม้ Column เป็น:


LONGTEXT

และตัว Column รองรับข้อมูลขนาดใหญ่

การรับส่งข้อมูลยังมีข้อจำกัด max_allowed_packet; MariaDB เตือนโดยตรงว่า BLOB/TEXT ขนาดใหญ่อาจเกิน Limit นี้ได้.

⑦ จึงไม่ใช่แค่เปลี่ยน VARCHAR เป็น LONGTEXT

ถ้า Error คือ 1153:

ต้องตรวจ Packet ก่อน

⑧ ตรวจค่า `max_allowed_packet` อย่างไร

ใช้:


SHOW VARIABLES LIKE 'max_allowed_packet';

หรือ:


SELECT @@max_allowed_packet;

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

เช่น:

16777216

คือจำนวน Bytes ที่กำหนดไว้

ไม่ควรอ่านตัวเลขแล้วคิดว่าเป็น MB โดยตรงโดยไม่ Conversion

⑩ อย่า Copy ค่า Server อื่น

Server A อาจมี:

Resource ต่าง
Players ต่าง
Hardware ต่าง
Payload ต่าง

การตั้งค่าควรตาม Workload จริง

⑪ FiveM Inventory เป็นสาเหตุสำคัญอย่างไร

Inventory Resource บางตัวอาจบันทึกข้อมูลจำนวนมากใน JSON เช่น:


[
  {
    "name": "item",
    "amount": 1,
    "metadata": {}
  }
]

ถ้า Inventory มี Items/Metadata จำนวนมาก JSON ก็จะใหญ่ขึ้น

⑫ Inventory ใหญ่ไม่ได้แปลว่าต้องเพิ่ม Packet

ต้องถามก่อน:

ขนาดนั้นเป็นข้อมูลจริง หรือ Data Growth Bug?

⑬ Metadata ซ้อนผิดปกติ

ตัวอย่าง Bug:


{
  "metadata": {
    "metadata": {
      "metadata": {}
    }
  }
}

เมื่อ Save ซ้ำ Data อาจโตต่อเนื่อง

⑭ เพิ่ม Packet จะทำอะไร

Error อาจหายชั่วคราว

แต่ Metadata ยังโต

อีกไม่นานอาจชน Limit ใหม่

⑮ ดังนั้นต้องตรวจ Root Cause

เปรียบเทียบ:

Player ปกติ
Player ที่ Error

⑯ Character คนเดียว Error

ถ้าทุกคน Save ได้ แต่ Character หนึ่งขึ้น 1153:

น่าสงสัย Data ของ Character นั้นมากกว่า Global Configuration

⑰ ตรวจ Inventory JSON

ดู:

จำนวน Items
Metadata
Duplicate Data
Serialized Data

⑱ อย่าลบ Inventory ทันที

Backup Record ก่อน

เพราะอาจมี Assets ของ Player จริง

⑲ Character Metadata ก็เช่นกัน

Custom Framework อาจเก็บ:

Hunger
Stress
Skills
Licenses
States
Custom Resource Data

ใน JSON

⑳ Resource หนึ่งอาจเพิ่ม Metadata ผิด

เช่นเพิ่ม History ทุกครั้ง:


state1
state2
state3
state4
...

โดยไม่ลบของเก่า

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

นี่เป็น Application Design Problem

ไม่ใช่ Database Limit อย่างเดียว

㉒ Appearance / Skin

Character Appearance สามารถมี:

Components
Props
Hair
Tattoos
Face Features

แต่หาก Appearance JSON ใหญ่ผิดปกติควรตรวจว่ามีข้อมูลซ้ำหรือไม่

㉓ Double Serialization

เป็น Pattern ที่ควรตรวจมาก

ตัวอย่างข้อมูลเดิม:


{"hair":1}

ถูก Encode เป็น String

แล้ว String นั้นถูก Encode อีกครั้ง

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


"{\"hair\":1}"

㉔ ทำซ้ำหลายรอบ

Payload สามารถโตโดยไม่จำเป็น

㉕ แก้ที่ Serializer

ไม่ใช่เพิ่ม Packet ทุกครั้ง

㉖ Vehicle Properties

Vehicle Resources อาจบันทึก:

Mods
Color
Extras
Damage
Wheels
Neon
Engine State

ใน JSON

㉗ Vehicle คันเดียว Error

ถ้าเฉพาะ Vehicle หนึ่ง:

ตรวจ Properties ของรถคันนั้น

㉘ Vehicle JSON ปกติควรเทียบกัน

เช่น:


Vehicle A = 5 KB
Vehicle B = 8 KB
Vehicle C = 20 MB

Vehicle C ชัดเจนว่าควรถูกตรวจ

㉙ อย่าเพิ่ม Packet เพียงเพื่อ Vehicle C

หา Data Growth Bug ก่อน

㉚ Housing Furniture

Housing Resource อาจมี Furniture/Object จำนวนมาก

แต่ละ Object อาจเก็บ:


model
position
rotation
metadata

㉛ บ้านที่มี Objects หลายพันตัว

Payload สามารถใหญ่

㉜ ต้องมี Gameplay Limit หรือไม่

ขึ้นอยู่กับ Resource

แต่ถ้าไม่มี Limit เลย Resource อาจสร้าง Database Payload ใหญ่มาก

㉝ Furniture Dupe Bug

ถ้า Object ถูก Save ซ้ำทุกครั้ง:

Data อาจโตแบบผิดปกติ

㉞ เพิ่ม Packet ไม่ได้แก้ Duplication

ต้องแก้ Object Save Logic

㉟ Phone Resource

Phone Data อาจใหญ่จาก:

Messages
Images metadata
Contacts
Social data

㊱ ไม่ควรเก็บทุกอย่างใน Row เดียวโดยไม่จำเป็น

แต่ต้องยึด Resource Schema จริง

ไม่ควร Rewrite Third-party Phone Database จาก Guess

㊲ Messages Table แยก Rows

มักจัดการ Scale ได้ต่างจาก JSON ก้อนเดียว

แต่ Architecture ของ Resource เป็นผู้กำหนด

㊳ Logs เป็นอีก Case

Resource อาจใช้ Bulk INSERT เช่น:


INSERT INTO logs (...)
VALUES (...), (...), (...), (...);

㊴ Batch มากเกิน

Statement เดียวสามารถใหญ่ขึ้นเรื่อย ๆ

จนเกิน Packet Limit

㊵ ลด Batch Size ช่วยได้ไหม

สำหรับ Background Logging บางระบบ:

ได้ ถ้า Resource รองรับและ Logic ไม่ต้อง Atomic ทั้ง Batch

㊶ แต่อย่าใช้กับ Banking แบบสุ่ม

Money Transactions อาจมี Atomicity Requirements ต่างกัน

㊷ Log กับ Money ไม่เหมือนกัน

Database Strategy ควรตาม Data Semantics

㊸ SQL Dump สามารถเกิด 1153 ได้

Dump บางรูปแบบรวม Rows จำนวนมากไว้ใน:


INSERT INTO ...
VALUES (...), (...), (...);

ทำให้ Statement ใหญ่มาก

㊹ Import Fail ไม่ได้แปลว่า FiveM Runtime มีปัญหา

ถ้า Error เกิดเฉพาะตอน Restore:

Focus ที่ Dump/Import Process

㊺ Resource SQL Installer ปกติเล็กมากแต่ Error 1153

ถ้า Installer มี Statement ขนาดผิดปกติ:

ตรวจ File

อาจมี:

Embedded Data
Corruption
Dumpขนาดใหญ่

㊻ `mariadb-dump`

MariaDB มี Utility สำหรับ Backup/Restore SQL และ Workflow ของ Dump ควรใช้ Tool/Options ที่เหมาะกับ Environment.

㊼ อย่า Copy Dump ผ่าน Text Editor โดยไม่จำเป็น

ไฟล์ใหญ่อาจถูก:

ตัด
Encoding เปลี่ยน

เพิ่มปัญหาอื่น

㊽ Error 1153 อาจสัมพันธ์กับ Error 2013

หัวข้อก่อนหน้าเป็น:


Lost connection to MySQL server during query

ถ้า Packet ใหญ่เกิน Configuration อาจมี Connection-level Errors ตาม Context/Connector ดังนั้น Error ก่อนหน้าใน Log สำคัญมาก

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

นี่เป็นเบาะแสแรงว่า Packet Size ควรถูกตรวจเป็นอันดับต้น ๆ

㊿ ถ้าเห็น 2006 ตามมา

Connection อาจไม่สามารถใช้ต่อหลัง Network/Protocol Error บางสถานการณ์

อย่าแก้เฉพาะบรรทัดสุดท้าย

51. อ่าน Error Timeline

ตัวอย่าง:


1153 packet too large
↓
connection closed
↓
2013 lost connection
↓
2006 server has gone away

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

52. อย่าเริ่มจาก Error 2006 ถ้ามี 1153 ชัดเจนก่อนหน้า

เพราะ Root Cause อาจเป็น Packet

53. Error 1301 ก็เกี่ยวกับ Packet ได้

MariaDB มี Error 1301:


Result of ... was larger than max_allowed_packet - truncated

เป็นอีก Error ที่อ้างถึง max_allowed_packet โดยตรง.

54. Error 1162 ก็มี

MariaDB กำหนด Error 1162 สำหรับกรณี:


Result string is longer than 'max_allowed_packet' bytes

55. ดังนั้น `max_allowed_packet` ไม่ได้เกี่ยวกับ 1153 ตัวเดียว

แต่เมื่อเห็น 1153 ข้อความก็ชัดที่สุดว่า Packet ใหญ่เกิน Limit.

56. BLOB/TEXT ต้องระวัง

MariaDB ระบุว่าเมื่อจัดการ BLOB/TEXT ขนาดใหญ่มาก ข้อมูลอาจเกิน max_allowed_packet.

57. LONGTEXT ใหญ่มากไม่ได้หมายถึงควรเก็บก้อนใหญ่ขนาดนั้น

ความสามารถของ Data Type กับ Application Design เป็นคนละเรื่อง

58. ตัวอย่างผิดด้าน Architecture

เก็บ:


inventory ของผู้เล่นทุกคน

เป็น JSON เดียวใน Row เดียว

แม้ทำได้ทางเทคนิค ก็อาจสร้าง Bottleneck ใหญ่

59. แต่ไม่ควร Rewrite Resource เอง

หากเป็น Paid/Third-party Script:

ตรวจ Official Update ก่อน

60. Resource Developer อาจมี Migration ใหม่

เช่นย้ายจาก:


single JSON

ไป:


normalized rows

ถ้า Version ใหม่แก้ Scale Problem แล้ว

61. Error หลัง Resource Update

ถ้าก่อน Update ไม่เกิด แต่หลัง Updateเกิด:

ตรวจ Changelog

62. Version ใหม่อาจเพิ่ม Data Fields

Payloadจึงใหญ่ขึ้น

63. หรือเกิด Regression

Resourceอาจ Serializeข้อมูลซ้ำ

64. Rollback Code ต้องระวัง

ถ้า Database Schemaถูก Migrationไปแล้ว:

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

65. Backupก่อน Rollback

สำคัญ

66. Error หลัง Framework Update

Frameworkอาจเพิ่ม Metadata/Player Data

Third-party Resourceอาจจับ Objectทั้งก้อนแล้ว Saveแทน Fieldsที่ต้องการ

67. ตัวอย่าง

เดิม Save:


player.metadata

Versionใหม่ accidentally Save:


entire player object

Payloadอาจใหญ่ขึ้นอย่างมหาศาล

68. ตรวจ Query Parameter

ดูว่า Parameterที่ควรเป็น:


metadata

กลับกลายเป็น Objectใหญ่ทั้งหมดหรือไม่

69. Parameter Mapping ผิดทำ Packetใหญ่ได้

ไม่จำเป็นต้องเป็น Serialization Bug

70. ตัวอย่าง

Query:


UPDATE users
SET metadata = ?
WHERE id = ?;

แต่ Parameterแรกถูกส่ง:


allPlayers

แทน:


playerMetadata

71. Databaseรับ JSONมหาศาล

แล้วเจอ1153

72. อย่าเพิ่ม Limitก่อนตรวจ Parameter

โดยเฉพาะถ้า Errorเริ่มหลังแก้ Code

73. NUI Payloadเกี่ยวได้ไหม

ข้อมูลอาจเริ่มจาก NUI → Client → Server → Database

ถ้า Clientส่ง Objectใหญ่เกินจำเป็น:

Serverอาจ Saveต่อ

74. Serverต้อง Validate Payload

อย่า Trust Raw Client Data

75. Playerสามารถส่งข้อมูลจำนวนมากได้หรือไม่

ขึ้นกับ Resource/Event Design

Serverควรมี:

Validation
Field whitelist
Size/range controls

เพื่อไม่ให้ arbitrary payloadถูก Save

76. SecurityกับPerformanceมาชนกันตรงนี้

Payload Validationช่วยทั้ง:

Database Stability
Abuse Prevention

77. อย่าเปิดให้ Clientกำหนด JSON Databaseตรง ๆ

หาก Featureไม่จำเป็น

78. Prepared Statements แก้ Packet Limitไหม

ไม่

Prepared Statementsช่วยเรื่อง Parameter Handling/SQL Injectionในหลาย Context

แต่ Dataยังต้องถูกส่งผ่าน Connection

Packet Limitยังมีอยู่

79. Connectorบางตัวรองรับส่ง Long Dataเป็น Chunks

MariaDB Connector/C API มี mysql_stmt_send_long_data() สำหรับส่ง TEXT/BLOB Parameterเป็นหลายส่วน โดยเอกสารระบุใช้กับข้อมูลที่อาจเกิน max_allowed_packet.

80. FiveM Resourceควรใช้ฟังก์ชันนี้ไหม

ไม่ควรเอา C APIตัวนี้ไปยัดใน FiveM Scriptเอง

Database Wrapperของคุณอาจใช้ Connectorคนละชนิด

81. หลักคืออะไร

มี Connector-level Techniquesสำหรับ Large Data

แต่ต้องใช้ APIของ Libraryจริง

82. FiveMทั่วไปไม่ควรต้อง Stream Inventory JSONหลาย MB

ถ้าต้องทำ:

ควรถามก่อนว่า Data Modelเหมาะหรือไม่

83. Image/Binary Filesใน Database

ถ้า Phone Resourceเก็บ Binary Imageตรงใน BLOB:

Payloadอาจใหญ่มาก

84. ควรเปลี่ยนไปเก็บ Fileไหม

ขึ้นกับ Resource Architecture

ไม่ควรแก้ Third-party Phoneด้วยการย้าย Storageเองโดยไม่มี Support

85. แต่เป็นสิ่งที่ต้องรู้

การเก็บ Binaryจำนวนมากใน Databaseมี Packet/Storage Considerations

86. Base64 ทำข้อมูลใหญ่ขึ้น

ถ้า Resourceเก็บ Binaryเป็น Base64 String:

Payloadจะไม่เท่ากับ Binaryต้นฉบับและมี Encoding Overhead

จึงควรตรวจ Architecture

87. อย่าบีบข้อมูลเองโดยไม่รู้ Resource

Applicationที่อ่านข้อมูลกลับอาจไม่รองรับ Compression

88. MariaDB รองรับ BLOB/TEXTตาม Typeต่าง ๆ

แต่ Packet Limitยังเป็นข้อจำกัดการสื่อสารสำหรับข้อมูลขนาดใหญ่มาก.

89. Error1153เฉพาะตอน Upload Image

นี่เป็นเบาะแสชัดว่า Payloadอาจเป็นสาเหตุ

90. Error1153ตอน Saveข้อความธรรมดา

ถ้าข้อความแค่ไม่กี่ตัวอักษร:

Packetไม่ควรใหญ่จากข้อความนั้นเอง

ตรวจว่า Resourceส่ง Objectอะไรเพิ่มเติม

91. Errorตอน Save Inventory Itemหนึ่งชิ้น

ถ้า Itemเดียว:

Metadataของ Itemนั้นอาจใหญ่มาก

92. Example Item Metadata


{
  "image": "very_large_base64_data..."
}

หาก Resource Save Imageเข้า Metadata:

Payloadอาจมหาศาล

93. Item Metadataไม่ควรรับ Arbitrary Data

Resourceควรจำกัด Fieldsตาม Feature

94. Errorหลังใช้ Custom Item

ตรวจ Config/Metadataของ Itemใหม่

95. Errorหลัง Crafting

Crafting Resourceอาจ Copy Metadataของ Ingredientsทั้งหมดเข้า Itemใหม่

96. ทำซ้ำหลายรอบ

Metadataอาจสะสมเป็น Tree

97. นี่เป็น Data Growth Bug

ไม่ควรแก้ด้วย Packet Limitอย่างเดียว

98. Errorหลัง Vehicle Modification

Resourceอาจ Append Mod Historyทุกครั้งแทน Replace Current State

99. ตรวจ JSON Structure

ถ้ามี:


history
history
history

โตมาก

ให้หา Resource Source

100. Error Housing Furnitureเฉพาะบ้านผู้เล่นหนัก

อาจ Resourceไม่จำกัด Furniture Count

101. Server Ruleช่วยได้ไหม

สามารถมี Gameplay Limit

แต่ Resourceควร Enforceฝั่ง Serverด้วย

102. UI Limitอย่างเดียวไม่พอ

Clientสามารถถูก Bypass

103. Errorจาก Bulk Player Save

Frameworkอาจพยายาม Serialize Playersทั้งหมดเป็น Queryเดียว

104. Saveหนึ่งคนต่อ Queryอาจดีกว่าไหม

ขึ้นกับ Framework Design

ไม่ควร Rewrite Coreโดยไม่ดู Official Implementation

105. Batch Sizeต้องเหมาะ

Batchเล็กลง:

Packetเล็กลง

แต่:

Queriesมากขึ้น

จึงมี Trade-off

106. ไม่ใช่ Batchเล็กที่สุดดีที่สุด

ต้อง Balance:

Packet
Round trips
Transactions
Throughput

107. Error1153ตอน Auto Saveทุกคน

ดู Batch Implementationเป็นอันดับต้น ๆ

108. Errorเฉพาะ Server Playersเยอะ

ถ้า Batchรวมทุก Player:

Packetอาจโตตาม Player Count

109. Server 20คนไม่ Error

แต่200คน Error

นี่เป็น Patternที่เข้ากับ Batch Payload Growthได้

110. แต่อาจเป็น Loadอื่น

ต้องดู Queryจริงก่อนสรุป

111. Error SQL Dumpจาก Databaseใหญ่

mariadb-dump เป็น Utilityทางการของ MariaDBสำหรับ Dump Database และควรใช้ Workflow Backup/Restoreที่เหมาะกับขนาดข้อมูล.

112. Extended Insertsทำ Statementใหญ่

Dump Options/Tool Behaviorอาจส่งผลต่อขนาดแต่ละ INSERT

113. Server Ownerทั่วไปควรทำอะไร

ถ้า Errorเกิดตอน Import:

ตรวจ Lineที่ Error
ดู Statement Size
ตรวจ max_allowed_packet
ตรวจ Dump Tool

114. อย่าแก้ FiveM Resource

ถ้า Runtimeไม่ได้ Errorเลย

115. Errorเกิดตอน phpMyAdmin Import

มีอีกชั้น:

PHP upload limit
Web timeout

ดังนั้นอ่านข้อความว่า Errorมาจาก MariaDBจริงหรือ Web Layer

116. ถ้าเป็น 1153ชัด

Database Packet Limitคือจุดสำคัญ

117. Error1153แล้วควรเพิ่มค่าเท่าไร

ไม่มีค่ามาตรฐานเดียว

วิธีที่ดีกว่า:

วัด Packet/Payload
ดู Limitเดิม
ประเมิน Dataจริง
เพิ่ม Marginที่เหมาะสม

118. อย่าตั้ง Maxเพราะง่าย

MariaDB System Variablesรองรับ Rangeกว้าง แต่ค่าที่อนุญาตสูงไม่ได้แปลว่า Applicationต้องใช้ค่าสูงสุด.

119. Environmentจริงสำคัญ

Hostingบางแห่งไม่ให้เปลี่ยน Global Variableเอง

120. Shared Hosting

อาจต้องติดต่อ Provider

121. VPS/Root Server

อาจเปลี่ยน Configurationได้เอง

แต่ควร:

Backup Config
บันทึกค่าเดิม

122. Dynamicหรือ Restart?

พฤติกรรมการเปลี่ยน Variableขึ้นกับ Scope/Version/Configurationที่ใช้อยู่ จึงควรตรวจเอกสาร MariaDB Versionจริงและวิธี Persistent Configurationของ Environment.

123. เปลี่ยน Runtimeอย่างเดียว

อาจหายหลัง MariaDB Restart

ถ้าไม่ได้บันทึกใน Configurationถาวร

124. Option File

MariaDBรองรับการกำหนด Server Variablesผ่าน Option Files เช่น my.cnf/configuration filesตาม Environment.

125. DirectAdminอาจจัด Configurationต่างกัน

อย่าเดา Pathของ my.cnf

ดู Environmentจริง

126. Containerก็เช่นกัน

Configอาจมาจาก:

environment
mounted file
command arguments

127. Managed Database

Providerอาจใช้ Parameter Group/Control Panel

อย่า SSHไปแก้ไฟล์ที่ไม่มี

128. หลังเปลี่ยนค่า

ตรวจอีกครั้ง:


SHOW VARIABLES LIKE 'max_allowed_packet';

129. อย่าคิดว่าแก้ Configแล้วค่าถูกใช้

Verify

130. Client-side max_allowed_packet มีไหม

Connectors/Clientsบางชนิดอาจมีข้อจำกัด/Settingsของตัวเองด้วย

จึงต้องดู Database Wrapperจริงหาก Server Limitเพิ่มแล้วปัญหายังอยู่

131. MariaDB Connector/Node Batch API

MariaDB Connector/Node documentationเตือนด้วยว่า Serverมี max_allowed_packet ซึ่งจำกัด Packet Exchangeสำหรับ Batch Operations.

132. FiveM JavaScript Resourceใช้ MariaDB Node Connectorตรงหรือไม่

อย่าสมมติ

FiveM Database Wrapperอาจใช้ Implementationของตัวเอง

133. ถ้าใช้ oxmysql หรือ Wrapperอื่น

ตรวจ Documentationของ Versionนั้นโดยตรงก่อนปรับ Client Options

134. Server LimitกับClient Limitต้องสัมพันธ์กัน

เพิ่มฝั่งหนึ่งอาจไม่พอถ้าอีกฝั่งยังมี Limitต่ำกว่าใน Stackที่ใช้อยู่

135. Error1153หลังเปลี่ยน Hosting

Environmentใหม่อาจมี max_allowed_packet ต่ำกว่าเดิม

136. ตรวจ Configurationเก่ากับใหม่

ถ้า Resource/Dataไม่เปลี่ยนแต่ Errorเกิดหลัง Migration:

นี่เป็นเบาะแสที่ดี

137. แต่อย่า Copy Configทั้งหมดจาก Serverเก่า

MariaDB Version/Hardwareอาจต่าง

138. Compareเฉพาะค่าที่เกี่ยวก่อน

เช่น:


max_allowed_packet

139. Error1153หลัง Restore Database

Databaseใหม่อาจ Restore Dataใหญ่ได้บางส่วน

แต่ Runtime Saveกลับเข้าไปด้วย Queryรูปแบบใหม่แล้วชน Limit

140. Recordใหญ่ที่มีอยู่เดิม

ไม่ได้แปลว่า INSERT/UPDATEใหม่จะผ่าน Configurationปัจจุบันเสมอ

141. ตรวจ Data Size

สำหรับ TEXT/JSONสามารถดู Lengthของข้อมูลด้วย SQL Diagnosticที่เหมาะสม

เช่นแนวคิด:


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

ใช้ Table/Columnจริง

142. LENGTHให้ Bytes

ใน MariaDB/MySQL semanticsทั่วไปควรระวัง Differenceกับ Character Lengthเมื่อเป็น Multibyte Text

แต่สำหรับ Packet Size Bytesมีความเกี่ยวข้องมากกว่า

143. ไม่ต้อง Queryทั้ง JSONออกมาดู

ถ้าแค่ต้องการวัดขนาด

ใช้ Lengthช่วยลดการดึง Payloadใหญ่

144. หา Recordใหญ่สุด

แนวคิด:


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

145. ใช้ Read-only Diagnosisก่อน

ไม่ต้อง DELETEทันที

146. ถ้า Recordหนึ่งใหญ่ผิดกลุ่ม

ตรวจ Resource/Dataของ Recordนั้น

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

อาจเป็น Normal Designหรือ Schemaใหม่

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

148. ถ้า Dataโตตามอายุ Account

น่าสงสัย Accumulation Bug

149. วัดหลัง Saveหลายครั้ง

Development/Staging:

ดูขนาดก่อนและหลัง Save

150. ถ้าขนาดเพิ่มทุก Saveทั้งที่ Gameplay Dataไม่เปลี่ยน

เป็นหลักฐาน Serialization/Data Growth Bugที่ดี

151. JSON Compressionช่วยไหม

ไม่ควรเพิ่ม Custom Compressionเองถ้า Resourceไม่ได้รองรับ

เพราะทุก Consumerต้อง Decodeให้ตรงกัน

152. Database Compressionเป็นอีก Topic

ไม่ใช่ Fixแรกของ1153

153. Split JSONออกหลาย Columnsช่วยไหม

อาจแก้ Architectureบางระบบ

แต่ไม่ควรทำ Third-party Resourceเองโดยไม่มี Migrationรองรับ

154. Normalize Dataช่วย Scaleได้

แต่เป็น Structural Change

ต้องคิดถึง:

Queries
Relationships
Migration

155. Error1153ไม่ควรทำให้ Rewrite Databaseทั้ง Server

เริ่มจาก Payloadจริง

156. Decision Tree


Error 1153
↓
Queryไหน?
↓
Payloadอะไร?
↓
ขนาดเท่าไร?
↓
max_allowed_packet เท่าไร?
↓
ข้อมูลควรใหญ่ขนาดนั้นไหม?
├─ ไม่ → แก้ Resource/Data
└─ ใช่ → ประเมินเพิ่ม Limit

157. ถ้าเกิด Playerเดียว


Player data
↓
Inventory / Metadata / Appearance

158. ถ้าเกิด Vehicleเดียว


Vehicle properties
↓
mods / metadata

159. ถ้าเกิด Houseเดียว


Furniture / objects

160. ถ้าเกิดทุก Playerตอน Autosave


Batch save / global payload

161. ถ้าเกิดตอน SQL Import


Dump statement size

162. ถ้าเกิดหลัง Hosting Move


Database configuration

163. ถ้าเกิดหลัง Resource Update


New fields / serialization / migration

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

ตั้ง max_allowed_packet สูงสุดทันที
เปลี่ยนทุก Columnเป็น LONGTEXT
ลบ Player Data
ลบ Inventory
Restart Databaseซ้ำ
Ignore Error
Retry Write Queryไม่จำกัด

165. Restart MariaDBช่วยไหม

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

Queryเดิมจะชน Limitอีก

166. Restart FiveMช่วยไหม

ไม่แก้ Payload Size

167. Clear FiveM Cacheช่วยไหม

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

168. Reinstall MariaDBช่วยไหม

ไม่ควรทำ

Configuration/Data Problemไม่ต้อง Reinstall Database

169. Retry Queryช่วยไหม

ถ้า Packetเท่าเดิมและ Limitเท่าเดิม:

Retryก็ Fail

170. Retry Write Queryยังมีความเสี่ยง

โดยเฉพาะ Asset/Money Operations

ไม่ควรทำ Infinite Retry

171. Error1153 FAQ

FiveM `Got a packet bigger than max_allowed_packet` คืออะไร

MariaDB Error1153 / SQLSTATE08S01 / ER_NET_PACKET_TOO_LARGE หมายถึง Packetที่รับส่งใหญ่กว่า max_allowed_packet.

ดู `max_allowed_packet` อย่างไร


SHOW VARIABLES LIKE 'max_allowed_packet';

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

ได้เมื่อ Workloadต้องการ Packetใหญ่จริง แต่ควรตรวจ Payloadก่อน ไม่ใช่เพิ่มจากการเดา

Inventory JSONทำ Error1153ได้ไหม

ได้ หาก Serialized Dataมีขนาดใหญ่เกิน Packet Limit โดยเฉพาะ Inventoryที่มี Metadataจำนวนมาก

Vehicle Propertiesทำได้ไหม

ได้ หาก JSONของ Vehicleผิดปกติหรือใหญ่เกิน Configuration

Housing Furnitureทำได้ไหม

ได้ หาก Resource Save Objectsจำนวนมากเป็น Payloadเดียว

Phone Dataทำได้ไหม

ได้หาก Query/Payloadมีขนาดใหญ่มาก

LONGTEXTแก้ได้ไหม

ไม่ใช่ Fixของ1153 เพราะ BLOB/TEXTขนาดใหญ่เองยังสามารถเกิน max_allowed_packet.

BLOBทำ Errorได้ไหม

ได้ MariaDBระบุว่าข้อมูล BLOB/TEXTขนาดใหญ่อาจเกิน Limitดังกล่าว.

SQL Dumpทำ Errorได้ไหม

ได้ โดยเฉพาะ Statementขนาดใหญ่ที่รวมข้อมูลจำนวนมาก

Error1153กับ2013เกี่ยวกันไหม

อาจปรากฏใน Error Chainเดียวกันเมื่อ Connectionมีปัญหาระหว่าง Query แต่1153เป็นเบาะแสตรงว่าขนาด Packetเกิน Limit

Error1153กับ2006เกี่ยวกันไหม

Connection-level Errorอาจตามมาได้ตาม Context แต่ถ้า1153เกิดก่อน ควรแก้ Packetก่อน

Error1153กับ1406ต่างกันอย่างไร

1406 = Columnเล็กเกินข้อมูล
1153 = Packetใหญ่เกิน Limit

Error1153กับ1162ต่างกันอย่างไร

MariaDB Error1162หมายถึง Result Stringยาวเกิน max_allowed_packet ส่วน1153หมายถึง Packetใหญ่เกิน Limit.

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

1301คือ Function Resultใหญ่กว่า max_allowed_packet และถูก Truncated ส่วน1153คือ Packetใหญ่เกิน.

Error1153กับ1153เกิด Playerเดียวควรทำอะไร

เปรียบเทียบ Serialized Dataของ Playerนั้นกับ Playerปกติ

ต้องลบ Characterไหม

ไม่

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

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

ไม่ควรทำโดยไม่มี Diagnosis

Errorหลัง Resource Updateควรทำอะไร

ตรวจ Changelog, Schema Migrationและขนาด Payloadก่อน/หลัง Update

Errorหลังย้าย Hostingควรทำอะไร

เปรียบเทียบ max_allowed_packet ของ Environmentเก่ากับใหม่

Errorตอน Auto Saveควรทำอะไร

ตรวจว่า Frameworkรวม Playersหลายคนเป็น Batch Queryใหญ่มากหรือไม่

Errorตอน Import SQLควรทำอะไร

ตรวจ Statementที่ Error, Dump Formatและ max_allowed_packet

เพิ่มค่าแล้ว Errorยังอยู่ทำอย่างไร

ตรวจ:

Client/Wrapper limits
Actual Variableหลังเปลี่ยน
Payloadใหญ่ขึ้นอีก
Errorจริงเป็น Codeอื่นหรือไม่

ต้อง Restart MariaDBหลังเปลี่ยนไหม

ขึ้นกับวิธีตั้งค่า, Scopeและ MariaDB Version/Environment จึงควรตรวจ Documentationและ Verifyค่าจริงหลังเปลี่ยน.

Configอยู่ไฟล์ไหน

ขึ้นกับ OS, Package, ContainerและHosting อย่าเดา Path; MariaDBรองรับ Option Filesแต่ตำแหน่งจริงขึ้นกับ Environment.

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

ไม่ควรใช้ค่าสูงสุดเป็น Default Solution ควรวัด Payloadและเลือก Limitที่มีเหตุผล

Queryเล็กแต่ขึ้น1153ได้ไหม

ถ้าข้อความ Error1153จริง ให้ค้นว่า Parameterตัวใดทำ Packetใหญ่ เพราะ SQL Textอาจสั้นแต่ Bound Parameterอาจมี JSON/BLOBขนาดมหาศาล

Prepared Statementช่วยไหม

ไม่ได้ทำให้ Packet Limitหาย ข้อมูล Parametersยังต้องถูกส่ง

ส่งข้อมูลเป็นChunksได้ไหม

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

ต้อง Backupไหม

ควร Backupก่อน:

Data Cleanup
Migration
Rewrite JSON
Schema Change

โดยเฉพาะ Inventory, VehicleและHousing Data

สรุป FiveM MySQL Got a Packet Bigger Than max_allowed_packet Error 1153

FiveM MySQL/MariaDB Error 1153 Got a packet bigger than 'max_allowed_packet' bytes เกิดเมื่อ Packet ที่ Resource และ Database กำลังรับส่งใหญ่กว่าค่า max_allowed_packet โดย MariaDB ระบุ Error นี้เป็น ER_NET_PACKET_TOO_LARGE, SQLSTATE 08S01.

ให้จำขั้นตอนนี้:


Error 1153
↓
หา Query ที่ล้ม
↓
ดู Parameter / JSON / BLOB
↓
วัดขนาด Payload
↓
SHOW max_allowed_packet
↓
Payload ใหญ่ผิดปกติหรือไม่?
↓
แก้ Resource / Data Growth
หรือ
เพิ่ม Packet Limitอย่างมีเหตุผล

สิ่งที่ comsiam แนะนำคืออย่ารีบเพิ่ม max_allowed_packet เป็นค่ามหาศาล เพราะถ้า Inventory Metadata, Vehicle Properties หรือ Furniture JSON กำลังโตจาก Duplicate/Serialization Bug การเพิ่ม Limitเพียงทำให้ข้อมูลผิดโตต่อได้อีก และ MariaDBเองยืนยันว่า BLOB/TEXTขนาดใหญ่ยังสามารถชน max_allowed_packetได้ แม้ Columnรองรับข้อมูลขนาดใหญ่ก็ตาม.

อีกหลักที่ comsiam แนะนำคือให้เปรียบเทียบขนาดข้อมูลก่อนเสมอ ถ้า Playerทั่วไปมี JSONไม่กี่ KBแต่ Playerที่ Errorมีหลาย MB ให้ตรวจ Recordและ Resourceนั้นก่อน แต่ถ้าข้อมูลมีขนาดใหญ่ตาม Requirementจริงและ Server Limitต่ำกว่าความต้องการ จึงค่อยเพิ่ม max_allowed_packetตาม Capacityที่เหมาะสม พร้อม Verifyค่าหลังเปลี่ยนและทดสอบ Queryเดิมอีกครั้ง