FiveM MariaDB Data Too Long for Column แก้อย่างไร? วิธีแก้ Error 1406, VARCHAR/TEXT และข้อมูลยาวเกิน Column

August 13, 2026

FiveM MariaDB Data too long for column คือ Error ที่เกิดเมื่อ Resource พยายามบันทึกข้อมูลลง Column แต่ข้อมูลนั้นยาวเกินขนาดที่ Data Type ของ Column รองรับ โดย MariaDB กำหนด Error นี้เป็น 1406, SQLSTATE 22001 และชื่อ Error ER_DATA_TOO_LONG.

ตัวอย่าง Error:

ERROR 1406 (22001):
Data too long for column 'metadata' at row 1

หรือใน FiveM/oxmysql อาจเห็นลักษณะ:

Data too long for column 'skin' at row 1
Data too long for column 'metadata' at row 1
Data too long for column 'inventory' at row 1
Data too long for column 'description' at row 1

ปัญหานี้พบบ่อยเมื่อ Script รุ่นใหม่เริ่มเก็บข้อมูลมากกว่าเดิม เช่น JSON, Metadata, Character Appearance, Settings หรือข้อมูล Serialized จำนวนมาก แต่ Database Schema ยังใช้ Column ขนาดเดิม

แนวทางแก้ที่ถูกต้องคือ:

Error 1406
↓
ดูชื่อ Column
↓
ดูค่าที่ Resource ส่งจริง
↓
SHOW CREATE TABLE
↓
ตรวจ Data Type / ขนาด
↓
ตรวจ Resource Version กับ Schema Version
↓
เลือกขยาย Column หรือแก้ข้อมูลต้นเหตุ
↓
Backup
↓
ALTER TABLE
↓
ทดสอบอีกครั้ง

ไม่ควรเริ่มจากการปิด Strict Mode เพียงเพื่อให้ Error หาย เพราะ MariaDB ระบุว่าเมื่อใช้ Strict SQL Mode ค่าที่เกินขนาด Data Type จะเกิด Error แทนการปล่อยให้ข้อมูลถูกตัดแบบเงียบๆ.

① Error 1406 คืออะไร

MariaDB ระบุ Error:

SQLSTATE:

ชื่อ:

ER_DATA_TOO_LONG

ข้อความ:

Data too long for column '%s' at row %ld

ดังนั้นถ้า FiveM ขึ้น:

Data too long for column 'metadata'

แปลอย่างง่ายว่า:

ค่าที่ Resource ส่ง
>
ขนาดที่ Column รองรับ

Database Connection ทำงานแล้ว Query ไปถึง MariaDB แล้ว แต่ MariaDB ปฏิเสธค่าที่ใหญ่เกิน Schema

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

สมมติ Table:

CREATE TABLE `players` (
    `nickname` VARCHAR(10)
);

แต่ Resource พยายามบันทึก:

SuperLongPlayerName

ซึ่งยาวกว่าความจุที่กำหนด

ภายใต้ Strict Mode MariaDB สามารถคืน Error 1406 แทนการรับค่าที่เกินขนาด.

③ VARCHAR(50) หมายถึงอะไร

VARCHAR เป็น String Data Type แบบ Variable-length โดยกำหนดความยาวสูงสุดไว้ใน Definition เช่น:

VARCHAR(50)

หรือ:

VARCHAR(255)

MariaDB ระบุว่าเมื่อพยายามบันทึก String ยาวเกินขนาดของ VARCHAR ผลจะขึ้นอยู่กับ SQL Mode และใน Strict Modeจะเกิด Error.

ตัวอย่าง:

`description` VARCHAR(100)

ถ้า Resource ส่งข้อความยาวมากกว่า Schema ยอมรับ ก็ต้องตรวจว่า:

ข้อมูลยาวผิดปกติ?

หรือ:

Column เล็กเกิน Requirement ใหม่?

④ อย่าเพิ่ม VARCHAR แบบสุ่มทันที

ถ้าเดิม:

`identifier` VARCHAR(50)

แล้ว Error เกิด

อย่ารีบเปลี่ยนเป็น:

VARCHAR(5000)

ก่อนรู้ว่า Resource ส่งอะไร

เพราะต้นเหตุอาจเป็น Bug เช่น:

identifier ควรเป็นข้อความสั้น
แต่ Resource ส่ง JSON ทั้งก้อนเข้าไป

ในกรณีนี้การขยาย Column เพียงทำให้ Bug ถูกซ่อน

⑤ วิธีดู Column จริง

ใช้:

SHOW CREATE TABLE `players`;

MariaDB ระบุว่า SHOW CREATE TABLE แสดง SQL Definition ที่ใช้สร้าง Table รวมถึง Column Definitions และ Indexes.

ตัวอย่างผล:

CREATE TABLE `players` (
    `id` INT NOT NULL,
    `metadata` VARCHAR(255) DEFAULT NULL
);

ตรงนี้จะเห็นทันทีว่า:

metadata
=
VARCHAR(255)

⑥ อย่าเดาจากไฟล์ install.sql อย่างเดียว

Resource อาจมี SQL File ระบุ:

`metadata` LONGTEXT

แต่ Database Production จริงอาจยังเป็น:

`metadata` VARCHAR(255)

เพราะ Migration ไม่เคยรัน

ดังนั้นต้องตรวจ Database จริงด้วย:

SHOW CREATE TABLE `table_name`;

ไม่ใช่ดูเพียงไฟล์ SQL ใน Resource.

⑦ สาเหตุอันดับหนึ่งใน FiveM: Schema เก่า

ตัวอย่าง:

Resource v1
metadata = VARCHAR(255)

ต่อมา:

Resource v3
metadata = JSON ใหญ่ขึ้น

แต่ Database ยัง:

Schema v1

Resource จึงส่งข้อมูลใหม่ลง Column เก่า

ผล:

Error 1406

วิธีแก้ที่ถูกต้องคือหา Migration ของ Resource Version ที่ใช้งานและอัปเดต Schema ให้ตรง ไม่ใช่เดาขนาด Column เอง

⑧ สาเหตุอันดับสอง: JSON ใหญ่ขึ้น

FiveM Resources จำนวนมากใช้ข้อมูล Serialized/JSON สำหรับเก็บ State หลายค่าไว้ใน Column เดียว เช่น:

Appearance
Preferences
Metadata
Properties
Custom Configuration

ใน MariaDB JSON เป็น Alias ของ LONGTEXT และ MariaDB ใช้ JSON_VALID เพื่อช่วยตรวจความถูกต้องของ JSON ตาม Definition ของ JSON Alias.

ดังนั้นหาก Script รุ่นใหม่ต้องการเก็บ JSON แต่ Column เดิมเป็น:

VARCHAR(255)

อาจไม่เพียงพอ

⑨ JSON ไม่ได้แปลว่าต้องเปลี่ยนทุก Column เป็น LONGTEXT

อย่าใช้สูตร:

FiveM JSON
=
LONGTEXT ทุก Column

ทันที

ต้องดู Official Schema ของ Resource เพราะบาง JSON มีขนาดเล็กมากและ Data Model อาจตั้งใจใช้ Type อื่น

การเลือก Data Type ควรสะท้อนข้อมูลที่ต้องเก็บจริง ไม่ใช่แก้ Error ด้วย Type ใหญ่ที่สุดเสมอ

⑩ VARCHAR กับ TEXT ต่างกันอย่างไร

MariaDB มี String Types หลายแบบ เช่น:

CHAR
VARCHAR
TINYTEXT
TEXT
MEDIUMTEXT
LONGTEXT

VARCHAR เหมาะกับข้อความ Variable-length ที่มี Maximum Length ตาม Definition ส่วน TEXT Family เหมาะกับข้อมูลข้อความที่อาจมีขนาดใหญ่กว่า โดยแต่ละชนิดมีขีดจำกัดต่างกัน.

⑪ TINYTEXT คืออะไร

MariaDB ระบุว่า TINYTEXT ใช้เก็บข้อความขนาดเล็ก โดยรองรับสูงสุดประมาณ 255 หน่วยตามข้อจำกัดของ Type.

ดังนั้นถ้า FiveM Script เก็บ:

JSON หลายพันตัวอักษร

ใน:

TINYTEXT

มีโอกาสชนข้อจำกัดได้ง่าย

⑫ TEXT คืออะไร

TEXT เป็น String Data Type สำหรับข้อความขนาดใหญ่กว่า TINYTEXT

MariaDB แสดงตัวอย่างโดยตรงว่าเมื่อบันทึกข้อมูลเกินขนาดของ TEXT ภายใต้ Strict Mode จะเกิด:

ERROR 1406 (22001):
Data too long for column

ดังนั้นแม้เปลี่ยนจาก VARCHAR เป็น TEXT ก็ไม่ได้หมายความว่า Column ไม่มี Limit

⑬ MEDIUMTEXT คืออะไร

MariaDB ระบุว่า MEDIUMTEXT สามารถเก็บข้อมูลข้อความได้สูงสุดประมาณ 16 MB.

จึงเหมาะกับข้อมูลข้อความที่ใหญ่กว่า TEXT ใน Use Case ที่ Data Model ต้องการจริง

แต่:

MEDIUMTEXT

ไม่ควรถูกเลือกเพียงเพราะ:

TEXT Error
→ เพิ่มให้ใหญ่สุด

ควรวัดขนาดข้อมูลจริงก่อน

⑭ LONGTEXT คืออะไร

MariaDB ระบุว่า LONGTEXT รองรับข้อมูลขนาดใหญ่มาก โดย Maximum ตาม Type สูงถึงระดับประมาณ 4 GB แต่ Effective Maximum ยังขึ้นกับ Character Encoding, Protocol Packet Size และ Memory.

นี่คือ Type ที่ MariaDB ใช้เป็นพื้นฐานของ JSON Alias ด้วย.

⑮ ตารางจำง่าย

Data Type	เหมาะกับ
`VARCHAR(n)`	ข้อความที่มี Maximum Length ชัดเจน
`TINYTEXT`	ข้อความสั้นมาก
`TEXT`	ข้อความยาว
`MEDIUMTEXT`	ข้อมูลข้อความขนาดใหญ่
`LONGTEXT`	ข้อมูลข้อความขนาดใหญ่มาก
`JSON`	MariaDB Alias ของ LONGTEXT พร้อม JSON Validation Behavior

รายละเอียดของ String Types และ JSON Alias เป็นไปตาม MariaDB Documentation.

⑯ Error Metadata Too Long แก้อย่างไร

ถ้า Console ขึ้น:

Data too long for column 'metadata'

ทำ:

SHOW CREATE TABLE `players`;

หรือ Table ที่ Error ระบุ

จากนั้นดู:

metadata VARCHAR(255)?
metadata TEXT?
metadata LONGTEXT?

แล้วหา Resource ที่กำลังบันทึก Metadata

เปรียบเทียบกับ Official Schema/Migration ของ Resource ก่อนแก้ Type

⑰ Error Skin Too Long

Character Skin หรือ Appearance Data อาจถูก Serialize เป็น JSON ยาวกว่าข้อความธรรมดามาก

ถ้า Schema เก่ายัง:

`skin` VARCHAR(255)

แต่ Resource ส่ง JSON ที่ยาวหลายพันตัวอักษร การชน Error 1406 เป็นสิ่งที่สอดคล้องกับข้อจำกัดของ String Column.

ต้องตรวจ Schema Official ของ Resource ที่ใช้จริง

⑱ Error Inventory Too Long

ถ้า Script เก็บ Inventory ทั้งก้อนเป็น JSON ใน Column เดียว:

inventory

ข้อมูลสามารถโตตามจำนวน Entries

หาก Column เดิมเล็กเกิน Requirement ปัจจุบัน Error 1406 อาจเกิดเมื่อข้อมูลถึงจุดหนึ่ง

แต่ไม่ควรรีบขยายอย่างเดียว ต้องถามว่า:

Resource รุ่นนี้ยังออกแบบให้เก็บ Inventory JSON ทั้งก้อนอยู่หรือไม่?

บาง Framework Version อาจย้ายไปใช้ Normalized Tables แล้ว

⑲ Description Too Long

กรณีนี้ง่ายกว่า:

`description` VARCHAR(100)

แต่ผู้ใช้ใส่:

ข้อความ 300 ตัวอักษร

มีสองทาง:

① จำกัด Input ให้ไม่เกิน 100

หรือ:

② เพิ่ม Column Size เพราะ Requirement ต้องการข้อความยาวกว่า

ต้องเลือกตาม Business Rule

⑳ Database Constraint กับ Application Validation ควรตรงกัน

ถ้า Database:

VARCHAR(100)

แต่ UI อนุญาต:

500 ตัวอักษร

ระบบมี Contract ไม่ตรงกัน

ควรทำ:

UI Limit
Server Validation
Database Column

ให้สัมพันธ์กัน

ไม่ควรพึ่ง MariaDB Error เป็น Validation สำหรับผู้เล่นทุกครั้ง

㉑ Server ต้อง Validate ก่อน Database

Flow ที่ดีกว่า:

Client
↓
ส่งข้อความ
↓
Server ตรวจ Length / Format
↓
ผ่าน
↓
Database

แทน:

Client
↓
ส่งอะไรก็ได้
↓
Database
↓
Error 1406

Database Constraint ยังเป็น Safety Layer แต่ Gameplay Validation ควรเกิดก่อน Query

㉒ อย่าเชื่อ Length ที่ Client ส่ง

ถ้า Client ส่ง:

length = 50

Server ไม่ควรเชื่อค่าตัวเลขนี้

ให้ Server วัด Value ที่ได้รับจริง

โดยเฉพาะ Fields ที่ผู้เล่นแก้ได้ เช่น:

name
description
profile
custom text

㉓ Character Count กับ Byte Count ต้องระวัง

VARCHAR และ String Storage เกี่ยวข้องกับ Character Set และจำนวน Bytes ที่ Characters ใช้ MariaDB ระบุว่า Maximum/Storage ของ VARCHAR สามารถได้รับผลจาก Character Set และ Multi-byte Characters.

ดังนั้น:

100 ตัวอักษรภาษาอังกฤษ

กับ:

100 Characters ที่ใช้ Multi-byte Encoding

อาจไม่ได้มี Storage Footprint เท่ากัน

㉔ ภาษาไทยเกี่ยวข้องไหม

ได้ในแง่ Character Encoding/Storage เพราะ Unicode Characters สามารถใช้หลาย Bytes ตาม Character Set ที่เลือก

แต่ไม่ควรสรุปว่า:

ภาษาไทย
=
Error 1406 เสมอ

ตัวปัญหาหลักยังเป็น Data Type, Column Definition, Character Set และข้อมูลจริงที่กำลังบันทึก

MariaDB มี Character Set/Collation Configuration แยกใน Table และ Column Definitions.

㉕ utf8mb4 ต้องระวังอะไร

Character Set ที่รองรับ Unicode หลาย Bytes ต่อ Character ทำให้ Storage Calculation ต่างจาก Single-byte Encoding

ดังนั้นเมื่อออกแบบ:

VARCHAR(n)

บน Tables ที่ใช้ Unicode จำนวนมาก ควรพิจารณา Character Set และ Index Design ไปพร้อมกัน ไม่ใช่ดูเพียงตัวเลข n.

㉖ วิธีดู Character Set ของ Table

ใช้:

SHOW CREATE TABLE `players`;

แล้วดูส่วน:

DEFAULT CHARSET=...
COLLATE=...

SHOW CREATE TABLE แสดง Definition ของ Table รวมถึงส่วนประกอบที่ใช้สร้าง Table.

㉗ วิธีวัดข้อมูลก่อน INSERT

ใน Application สามารถตรวจ String Length ก่อนส่ง Databaseได้

ตัวอย่างแนวคิด Lua:

local value = description or ''

if #value > 500 then
    return
end

แต่ต้องระวังว่าการนับ Bytes ใน Lua ไม่จำเป็นต้องเท่ากับการนับ Unicode Characters ที่ผู้ใช้มองเห็น

ดังนั้นสำหรับ Fields ที่ต้องจำกัดเป็น “จำนวนตัวอักษร” จริง อาจต้องใช้ Unicode-aware Validation ตาม Runtime/Library ที่ใช้อยู่

㉘ วิธีวัด Length ใน MariaDB

สำหรับการตรวจข้อมูลที่มีอยู่ สามารถใช้ String Functions ที่เหมาะสม เช่น Function ที่วัด Characters หรือ Bytes ตาม Requirement

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

ค่าที่ใหญ่ที่สุดใน Column

ก่อนตัดสินใจ Migration

อย่าเดาว่า:

VARCHAR(255) ไม่พอ
→ VARCHAR(10000)

ทันที

㉙ ตรวจข้อมูลยาวที่สุดก่อน Migration

ตัวอย่างแนวคิด:

SELECT
    `id`,
    CHAR_LENGTH(`metadata`) AS `chars`
FROM `players`
ORDER BY `chars` DESC
LIMIT 20;

ใช้เพื่อดูว่าข้อมูลจริงมีขนาดประมาณเท่าไร

จากนั้นจึงเทียบกับ Requirement ของ Resource และ Schema Official

㉚ ขนาด JSON โตขึ้นเพราะอะไร

JSON สามารถโตจาก:

เพิ่ม Fields
เพิ่ม Arrays
เพิ่ม Nested Objects
เก็บ History
เก็บ Options จำนวนมาก

ดังนั้น Resource Update ที่เพิ่มข้อมูลใหม่อาจทำให้ JSON เดิมจาก:

200 Characters

กลายเป็น:

2,000+

ได้

ถ้า Schema ไม่ถูก Migration ตาม Version ก็ชน Error 1406

㉛ JSON ใน MariaDB คือ LONGTEXT Alias

MariaDB ระบุโดยตรงว่า:

JSON

เป็น Alias ของ:

LONGTEXT

และใช้ Validation Constraint เพื่อรองรับ JSON Semantics.

ดังนั้นถ้า Resource Official Schema ใช้:

`metadata` JSON

แต่ Production Table ยัง:

`metadata` VARCHAR(255)

นี่เป็นสัญญาณชัดว่าควรตรวจ Migration

㉜ แต่อย่า ALTER เป็น JSON โดยไม่ตรวจ Version

MariaDB/MySQL มีความแตกต่างด้าน JSON Implementation และ Compatibility ในบาง Version

จึงควรใช้ Schema ที่ Resource รองรับจริง ไม่ใช่เห็นคำว่า JSON แล้วเปลี่ยนเองทุก Database Environment

MariaDB Documentation ปัจจุบันระบุ JSON เป็น LONGTEXT Alias.

㉝ วิธี ALTER VARCHAR ให้ใหญ่ขึ้น

สมมติ Official Schema ยืนยันว่า Column ควรเป็น:

VARCHAR(500)

สามารถใช้ ALTER TABLE ตาม Syntax ของ MariaDB เพื่อแก้ Table Definition.

ตัวอย่าง:

ALTER TABLE `players`
MODIFY COLUMN `description` VARCHAR(500);

แต่ก่อนทำ Production:

Backup
↓
ตรวจ Index
↓
ตรวจ NULL/DEFAULT
↓
ตรวจ Character Set
↓
Migration

ก่อนเสมอ

㉞ อย่าลืม NULL และ DEFAULT ตอน MODIFY COLUMN

ถ้าเดิม:

`description` VARCHAR(100) NOT NULL DEFAULT ''

แล้วเขียน:

MODIFY COLUMN `description` TEXT;

โดยไม่ตรวจ Definition อื่น คุณอาจเปลี่ยน Semantics ของ Column เพิ่มเติมโดยไม่ตั้งใจ

ดังนั้น Copy Definition ปัจจุบันจาก:

SHOW CREATE TABLE

ก่อนแก้.

㉟ เปลี่ยน VARCHAR เป็น TEXT

ถ้า Official Migration ระบุว่าควรเปลี่ยนเป็น TEXT ตัวอย่างเชิง Syntax อาจเป็น:

ALTER TABLE `players`
MODIFY COLUMN `metadata` TEXT;

แต่ต้องตรวจ:

Indexes
Defaults
Application Expectations
Resource Version

เพราะ VARCHAR กับ TEXT มีความแตกต่างด้าน Storage/Indexing Behavior.

㊱ เปลี่ยน TEXT เป็น MEDIUMTEXT

ถ้าข้อมูลจริงเกิน Capacity ของ TEXT และ Official Schema รองรับ/ต้องการ:

ALTER TABLE `players`
MODIFY COLUMN `metadata` MEDIUMTEXT;

MariaDB ระบุว่า MEDIUMTEXT รองรับข้อความสูงสุดประมาณ 16 MB.

อย่าใช้ Type นี้กับทุก Field โดยไม่จำเป็น

㊲ เปลี่ยนเป็น LONGTEXT

ตัวอย่าง:

ALTER TABLE `players`
MODIFY COLUMN `metadata` LONGTEXT;

LONGTEXT รองรับ Data Size ที่ใหญ่มากกว่า TEXT และ MEDIUMTEXT.

แต่ก่อนเลือกให้ถาม:

ข้อมูลนี้ควรใหญ่ขนาดนั้นจริงหรือ?

ถ้า Resource ส่งข้อมูลผิด Field การเพิ่มเป็น LONGTEXT จะเพียงซ่อน Bug

㊳ Column ที่เป็น Index ต้องระวังมากขึ้น

MariaDB ระบุว่า VARCHAR สามารถถูก Index ได้เต็ม Column ในบริบทที่เหมาะสม ขณะที่ TEXT มีข้อแตกต่างด้าน Indexing และอาจใช้ Prefix Length ตามการออกแบบ.

ดังนั้นถ้า Column เป็น:

UNIQUE
INDEX
PRIMARY relationship

อย่าเปลี่ยน Data Type โดยไม่ตรวจ Index Design

㊴ Identifier ไม่ควรกลายเป็น LONGTEXT ง่ายๆ

ถ้า Field:

license
identifier
uuid
email-like key

ถูกออกแบบให้ใช้ Search/Index บ่อย

การเปลี่ยนเป็น LONGTEXT เพียงเพราะ Error 1406 อาจเป็นวิธีแก้ที่ผิด

ควรตรวจว่าทำไม Identifier ถึงยาวผิดปกติก่อน

㊵ Metadata เหมาะกับ TEXT Family มากกว่าในบาง Design

ถ้า Field เป็น Data Blob/JSON ที่ไม่ได้ใช้เป็น Main Relational Key การใช้ Text Family อาจสัมพันธ์กับ Requirement มากกว่า VARCHAR เล็กๆ

แต่คำตอบที่ถูกต้องต้องมาจาก Official Schema ของ Framework/Resource

อย่าแก้ Database Architecture โดยอาศัยชื่อ Column อย่างเดียว

㊶ Error 1406 หลัง Resource Update

ตรวจทันที:

① Release Notes
② Migration SQL
③ install.sql
④ ALTER TABLE files
⑤ Database Version Requirement
⑥ Resource Version

ถ้าก่อน Update ใช้ได้ แต่หลัง Update Error:

Data too long

มีความเป็นไปได้สูงที่ Data Shape หรือ Schema Requirement เปลี่ยน

ควรเปรียบเทียบ Schema Version ก่อนและหลัง

㊷ Error 1406 หลัง Import Database

อาจเกิดเมื่อ:

Database A
มี Column ใหญ่

แต่ Import Schema/Data ไป:

Database B
Column เล็กกว่า

MariaDB มีตัวอย่างใน Replication Documentation ว่า Schema Definitions ที่ไม่ตรงกันสามารถนำไปสู่ Error 1406 เมื่อข้อมูลจากต้นทางไม่พอดีกับ Column ฝั่งปลายทาง.

ดังนั้น Restore/Migration ต้องตรวจทั้ง Data และ Schema

㊸ Error 1406 หลังย้าย Hosting

ตรวจ:

Database Schema เหมือนเดิมหรือไม่
SQL_MODE เหมือนเดิมหรือไม่
Character Set เหมือนเดิมหรือไม่
MariaDB Version เหมือนเดิมหรือไม่

โดยเฉพาะกรณี Export/Import เฉพาะ Data แต่ไม่ได้ย้าย Table Structure ตามเดิม

㊹ Strict Mode เกี่ยวอย่างไร

MariaDB Documentation ของ VARCHAR และ TEXT ระบุว่าเมื่อ Strict SQL Mode เปิด การบันทึกข้อมูลที่ยาวเกิน Type จะเกิด Error; หากไม่ Strict Behavior อาจกลายเป็น Warning/Truncation ตาม Type และ Situation.

นี่คือเหตุผลที่:

Server A
Error 1406

แต่:

Server B
เหมือนจะบันทึกผ่าน

อาจมี Configuration ต่างกัน

㊺ ปิด Strict Mode แก้ได้ไหม

ไม่ควรเป็นวิธีหลัก

เพราะสิ่งที่อาจเกิดขึ้นคือ:

ข้อมูล 500 ตัว
↓
Column รองรับ 255
↓
Database ตัดข้อมูล
↓
Resource อ่านกลับ
↓
JSON เสีย / Data หาย

ในกรณี JSON หรือ Serialized Data การตัดเพียงท้ายข้อความไม่กี่ Bytes อาจทำให้ Document ใช้งานไม่ได้ทั้งหมด

ดังนั้น Error ที่ชัดเจนอาจดีกว่าการปล่อยให้ข้อมูลถูก Truncate โดยไม่รู้ตัว

㊻ JSON ถูกตัดอันตรายอย่างไร

สมมติ JSON:

{"appearance":{"hair":5,"eyes":2}}

ถ้าถูกตัดเหลือ:

{"appearance":{"hair":5,

ก็ไม่ใช่ JSON ที่สมบูรณ์

MariaDB JSON Alias ใช้ JSON_VALID เพื่อช่วยยืนยันรูปแบบ JSON ใน Definition ที่เกี่ยวข้อง.

จึงไม่ควรแก้ Overflow ด้วยการยอมให้ข้อมูลถูกตัด

㊼ oxmysql เป็นสาเหตุไหม

โดยปกติ Error 1406 เป็น Error ที่ MariaDB คืนหลังได้รับค่าที่เกิน Column Definition

oxmysql ทำหน้าที่ส่ง Queries/Parametersระหว่าง FXServer และ Database โดย Official Project ระบุว่าเป็น MySQL Resource สำหรับ FXServer.

ดังนั้นควรตรวจ:

Resource Data
+
Database Schema

ก่อนสรุปว่า oxmysql เสีย

㊽ วิธีจับ Query จาก oxmysql

oxmysql มี Debug Tools สำหรับรายงาน Query Speed/Queries ที่กำลังทำงาน และสามารถใช้ mysql_debug เพื่อดู Query Information ใน Server Console.

เป้าหมายคือให้รู้ว่า:

Resource ไหน
Query ไหน
Column ไหน
ค่าอะไร

เป็นต้นเหตุ

㊾ อย่า Print ข้อมูล Sensitive ทั้งก้อน

ถ้ากำลัง Debug JSON หรือ Metadata ใหญ่ อย่า Print:

Password
Tokens
Secrets
Private identifiers
Connection strings

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

สามารถ Log:

Resource
Column
Length
Record ID

แทนค่าทั้งก้อนได้ในหลายกรณี

㊿ Log Length แทน Content

ตัวอย่างเชิง Debug:

print(('metadata length: %s'):format(#metadata))

แล้วเปรียบเทียบกับ Schema

ถ้าเห็น:

metadata length = 4800

แต่ Database:

metadata VARCHAR(255)

ก็เห็นปัญหาได้โดยไม่ต้อง Dump ข้อมูลทั้งหมดลง Console

51. Data Too Long หลัง Player คนเดียว

ถ้า Error เกิดเฉพาะ Player หนึ่งคน อาจหมายถึง Record/Data ของ Player นั้นผิดปกติ

ตรวจ:

Character JSON
Metadata
Appearance
Custom Settings

ของ Record นั้น

อย่า ALTER ทั้ง Database ทันที ถ้าคนอื่นทุกคนมีข้อมูลขนาดปกติและ Official Schema บอกว่า Column เดิมถูกต้อง

52. Data Too Long หลังทุกคนเข้า Server

ถ้าเกิดกับทุก Player หลัง Update:

มีโอกาสสูงกว่า

ว่า:

Schema Version

ไม่ตรง Resource Version

ตรวจ Migration ก่อนแก้ Individual Data

53. Data Too Long เฉพาะ Character ใหม่

ถ้า Character เก่าโหลดได้ แต่ Character ใหม่สร้างไม่ได้ ให้ตรวจ:

Character Creation Payload
Default JSON
Default Metadata
INSERT Query

Resource Version ใหม่อาจเพิ่ม Default Fields จน Insert Value ใหญ่กว่า Column เดิม

54. Data Too Long ตอน Save

ถ้า Load ได้แต่ Save ไม่ได้:

Database Row เดิม
→ ขนาดยังเล็ก

แต่ระหว่าง Gameplay:

Metadata โตขึ้น
↓
Save
↓
1406

ต้องหา Data ที่สะสม เช่น Array/History ที่ Resource เพิ่มไม่หยุด

55. Metadata โตไม่หยุดเป็น Bug ได้

ตัวอย่าง Logic:

ทุก Save
↓
เอา Metadata เก่า
↓
Append ทั้งก้อนอีกครั้ง

ทำให้:

1 KB
2 KB
4 KB
8 KB
...

ต่อให้เปลี่ยนเป็น MEDIUMTEXT วันหนึ่งก็อาจเต็มอีก

ดังนั้นต้องดู Growth Pattern ไม่ใช่แค่ปัจจุบัน

56. อย่าขยาย Column เพื่อแก้ Data Leak

ถ้าข้อมูลควร:

500 bytes

แต่ Resource ส่ง:

5 MB

อย่าแก้ด้วย:

LONGTEXT

ทันที

ถามก่อนว่า:

ทำไมข้อมูลใหญ่ผิดปกติ?

Resource อาจกำลัง Serialize Object ที่ไม่ควรเก็บทั้งหมด

57. JSON ควร Normalize ไหม

ขึ้นกับ Data Model

JSON เหมาะกับ Flexible/Semi-structured Data ในบาง Use Case แต่ข้อมูลที่ต้อง:

Search
Join
Index
Update บ่อยเป็น Field

อาจเหมาะกับ Relational Columns/Tables มากกว่า

ไม่ควรนำทุกอย่างใน FiveM ไปเก็บใน JSON ก้อนเดียวเพียงเพราะเขียน Resource ง่าย

58. JSON ขนาดใหญ่มีผลด้าน Performance ด้วย

แม้ LONGTEXT รองรับข้อมูลใหญ่มาก แต่การส่ง/อ่าน/เขียน Payload ใหญ่ก็ยังใช้:

Network
Memory
Serialization
Database I/O

และ Effective Maximum ของ LONGTEXT ยังได้รับผลจาก Client/Server Packet และ Memory ตาม MariaDB Documentation.

ดังนั้น “ใส่ LONGTEXT แล้วจบ” ไม่ใช่ Performance Strategy

59. Data Type ใหญ่ที่สุดไม่ได้ดีที่สุด

ตัวอย่าง:

player_name

ควรมี Limit ตาม Business Rule

การตั้ง:

LONGTEXT

สำหรับ Player Name ไม่มีประโยชน์ในหลาย Design

Limit ที่เหมาะช่วย:

Validate
Index
Control Data Quality

ได้ชัดกว่า

60. VARCHAR(255) ไม่ใช่มาตรฐานสำหรับทุกอย่าง

Developer มักใช้:

VARCHAR(255)

เป็นค่าเริ่มต้นโดยไม่คิด

แต่แต่ละ Field ควรออกแบบตาม Requirement เช่น:

Identifier
Name
URL
Description
JSON
Metadata

แต่ละชนิดมี Data Shape ต่างกัน

เมื่อ Error 1406 เกิด นี่เป็นโอกาสตรวจ Schema Design ไม่ใช่เพียงเพิ่มตัวเลข

61. วิธีตรวจ Column จาก information_schema

หากมี Tables จำนวนมาก สามารถใช้ Metadata ของ Database เพื่อดู:

Column Name
Data Type
Maximum Length

แทนเปิด SHOW CREATE TABLE ทีละ Table

แต่สำหรับ Debug Table เดียว:

SHOW CREATE TABLE

มักอ่านง่ายที่สุดและแสดง Definition ครบ.

62. ALTER TABLE ก่อนทำต้อง Backup

การแก้ Data Type เป็น Schema Migration

ก่อน:

ALTER TABLE

Production ควรมี Backup/Recovery Plan และควรทดสอบ Migration บนสำเนา Database ก่อน โดยเฉพาะ Table ใหญ่

อย่าทำ:

Console Error
↓
ALTER Production ทันที

โดยไม่มี Rollback Plan

63. Table ใหญ่ ALTER อาจใช้ทรัพยากร

ผลกระทบของ ALTER TABLE ขึ้นกับ Operation, MariaDB Version, Storage Engine และ Table Structure

ดังนั้น Table ขนาดใหญ่ควรทดสอบ:

Execution Time
Locks
Disk Space
Load

ใน Environment ใกล้เคียง Production ก่อน

MariaDB มี ALTER TABLE เป็น DDL สำหรับแก้ Table Definition และความสามารถ/Algorithm ที่รองรับขึ้นกับ Operation.

64. อย่าแก้ระหว่าง Player เยอะถ้าไม่จำเป็น

ถ้า Table สำคัญ เช่น:

players
characters
vehicles

การทำ Schema Migration ช่วง Peak Traffic มีความเสี่ยงด้าน Operational Impact มากกว่าช่วง Maintenance

ควร:

Backup
↓
Maintenance
↓
Migration
↓
Verify
↓
เปิด Resources

ตามระดับความสำคัญของ Server

65. ตรวจหลัง ALTER

หลัง Migration:

SHOW CREATE TABLE `players`;

อีกครั้ง

อย่าเชื่อเพียงข้อความ:

Query OK

ต้อง Verify ว่า Column เป็น Type ที่ต้องการจริง.

66. ทดสอบข้อมูลเดิมหลัง ALTER

ตรวจ:

Player Login
Character Load
Character Save
Resource Restart
FXServer Restart

รวมถึง Record ที่เคย Error

ถ้าเปลี่ยน Type แล้ว Error หายแต่ Resource อ่าน JSON ไม่ได้ อาจมี Data Corruption เดิมค้างอยู่

67. ตรวจ Existing Truncated Data

ถ้า Server เคยทำงานโดยไม่ใช้ Strict Mode อาจมี Records ที่ถูก Truncate มาก่อน

เช่น:

JSON ไม่ครบ
String ขาดท้าย
Serialized Data เสีย

การขยาย Column วันนี้ไม่ได้คืน Data ที่หายไปเมื่อก่อน

อาจต้อง Restore Record จาก Backup หรือสร้างข้อมูลใหม่ตาม Resource Logic

68. Error 1406 กับ Error 1265 ต่างกัน

1406 ระบุชัดว่า:

Data too long for column

ส่วน Data Truncation/Conversion Issues อื่นอาจใช้ Error/Warning Codes ต่างกันตาม Context

จึงควรอ่าน:

Error Code
SQLSTATE
Column
Row

ครบทุกครั้ง ไม่ใช่เห็นคำว่า Data แล้วถือว่าเป็นปัญหาเดียวกัน

69. Error 1406 กับ Unknown Column ต่างกัน

Error 1406

Column มีอยู่
แต่ข้อมูลใหญ่เกิน

Unknown Column

Column ไม่มี
หรือ Query อ้างชื่อผิด

ถ้า Error เป็น 1406 ไม่ต้องเริ่มจากสร้าง Column ใหม่

Column นั้นมีอยู่แล้วพอที่ MariaDB จะตรวจขนาดของค่าที่กำลังบันทึก

70. Error 1406 กับ Duplicate Entry ต่างกัน

1406

Value ใหญ่เกิน Column

1062

Value ซ้ำใน PRIMARY/UNIQUE KEY

การเพิ่ม Column Size ไม่แก้ Duplicate Entry และการใช้ Upsert ไม่แก้ Data Too Long

ต้องแยก Error ให้ถูกก่อน

71. Error 1406 กับ Foreign Key Error ต่างกัน

1406

Data Length / Type Capacity

1452

Child Row ไม่มี Parent ที่ถูกต้อง

ทั้งคู่เกิดตอน INSERT/UPDATE ได้ แต่ Root Cause ต่างกันอย่างสิ้นเชิง

72. วิธีแก้แบบ 5 นาที

เมื่อ Console ขึ้น:

Data too long for column 'metadata'

ทำตามนี้:

① จด Table
② จด Column
③ จด Resource
④ ดูค่าที่ส่งและ Length
⑤ SHOW CREATE TABLE
⑥ ดู Data Type
⑦ ตรวจ Official Schema ของ Resource Version
⑧ ตรวจ Migration
⑨ Backup
⑩ ALTER เฉพาะเมื่อ Schema ต้องเปลี่ยนจริง
⑪ ทดสอบ Record ที่ Error

นี่เร็วกว่าการเดา VARCHAR(255) → LONGTEXT ทุกครั้ง

73. ตัวอย่าง Debug

Error:

Data too long for column 'metadata' at row 1

ตรวจ:

SHOW CREATE TABLE `players`;

พบ:

`metadata` VARCHAR(255)

Debug Resource พบ Metadata Length:

จากนั้น Official Migration ของ Resource กำหนด:

`metadata` LONGTEXT

กรณีนี้ Root Cause มีเหตุผลรองรับว่า:

Database Schema ยังเก่า

จึงค่อย Migration ตาม Schema Official

74. ตัวอย่างที่ไม่ควร ALTER

Error:

Data too long for column 'identifier'

Database:

identifier VARCHAR(100)

แต่ Debug พบ Resource ส่ง:

JSON 20 KB

ทั้งที่ identifier ควรเป็น Player Identifier

กรณีนี้:

อย่าเปลี่ยน identifier เป็น LONGTEXT

ต้องแก้:

Parameter Order
Variable Mapping
Query

ของ Resource

75. Parameter Order ผิดทำให้ Data Too Long ได้

ตัวอย่าง SQL:

MySQL.update.await([[
    UPDATE `players`
    SET `identifier` = ?,
        `metadata` = ?
    WHERE `id` = ?
]], {
    metadata,
    identifier,
    playerId
})

สังเกตว่า Parameters สลับกัน

Database จึงได้รับ:

identifier = JSON ก้อนใหญ่

และอาจขึ้น Error 1406

นี่เป็นเหตุผลที่ต้องดู Parameters จริง ไม่ใช่เพียง Schema

76. Placeholder ถูกแต่ Values สลับก็พังได้

oxmysql Query APIs ใช้ Value Placeholders ใน SQL และ Parameters ถูกส่งตามตำแหน่งที่กำหนด.

ดังนั้น:

Query Syntax ถูก

ไม่ได้แปลว่า:

Parameter Mapping ถูก

เสมอ

ตรวจลำดับ Values ให้ตรง Column

77. ใช้ mysql_debug หา Resource

oxmysql ระบุว่าความเร็ว Query จริงและข้อมูล Debug สามารถดูใน Debug UI/Server Console เมื่อเปิด mysql_debug.

ใช้เพื่อจับ:

Resource
↓
Query
↓
Column
↓
เวลาเกิด

แล้วกลับไปตรวจ Code

78. Resource หลายตัว Update Column เดียวกัน

ตัวอย่าง:

framework
→ metadata

inventory
→ metadata

custom_script
→ metadata

ถ้า Resource ใหม่ส่ง Structure ใหญ่ขึ้น ปัญหาอาจเริ่มหลังติดตั้ง Resource นั้น

ควรทำ Inventory ว่าใครเขียน Column เดียวกันบ้าง

79. ไม่ใช่ทุก Metadata ควรแชร์ Column เดียว

ถ้าหลาย Resources เพิ่มข้อมูลเข้า JSON ก้อนเดียว:

metadata

จนโตเรื่อยๆ อาจเป็นสัญญาณว่าควรประเมิน Data Model ใหม่

แยก Data ที่มี Lifecycle ต่างกันออกเป็น Tables/Columns ที่เหมาะสมอาจดูแลง่ายกว่าในระยะยาว

80. Checklist Error 1406 สำหรับ FiveM

ตรวจอย่างน้อย:

Error Code ใช่ 1406 หรือไม่
SQLSTATE ใช่ 22001 หรือไม่
Table ไหน
Column ไหน
Resource ไหน
Query ไหน
Parameter ไหนถูกใส่ Column
Parameter Order ถูกหรือไม่
Value Length เท่าไร
Data Type ปัจจุบันคืออะไร
VARCHAR เท่าไร
TEXT/TINYTEXT/MEDIUMTEXT/LONGTEXT หรือไม่
Character Set อะไร
Official Schema ระบุอะไร
Resource Version อะไร
Migration รันครบหรือไม่
Schema เก่าหรือไม่
JSON โตขึ้นหรือไม่
Metadata โตผิดปกติหรือไม่
Data ถูก Append ซ้ำหรือไม่
Input Validation มีหรือไม่
Client ส่งข้อมูลยาวเกินหรือไม่
Server จำกัด Length หรือไม่
Strict Mode เปิดหรือไม่
เคยมี Data Truncation มาก่อนหรือไม่
Column ถูก Index หรือไม่
ALTER กระทบ Index หรือไม่
Backup แล้วหรือไม่
Test Migration แล้วหรือไม่
Verify หลัง ALTER แล้วหรือไม่
Test Player Load แล้วหรือไม่
Test Player Save แล้วหรือไม่
Test Resource Restart แล้วหรือไม่
Monitor Query Errors หลังแก้แล้วหรือไม่

ตาราง Data Type ที่ควรรู้

Type	แนวทางใช้งาน
`VARCHAR(n)`	ข้อความ Variable-length ที่มี Limit ชัด
`TINYTEXT`	ข้อความขนาดเล็ก
`TEXT`	ข้อความยาว
`MEDIUMTEXT`	ข้อมูลข้อความขนาดใหญ่ ประมาณสูงสุด 16 MB
`LONGTEXT`	ข้อมูลข้อความขนาดใหญ่มาก
`JSON`	MariaDB Alias ของ LONGTEXT

MariaDB Documentation ระบุรายละเอียด String Types และขนาดของ MEDIUMTEXT, LONGTEXT รวมถึง JSON Alias ไว้โดยตรง.

FiveM Data Too Long for Column แก้อย่างไร

เริ่มจาก:

SHOW CREATE TABLE `table_name`;

แล้วดู Column ที่ Error ระบุ

MariaDB ระบุว่า Error 1406 หมายถึงข้อมูลยาวเกิน Column และ SHOW CREATE TABLE ช่วยให้เห็น Definition ของ Column จริง.

จากนั้นตรวจค่าที่ Resource ส่งก่อน ALTER

FiveM Error 1406 คืออะไร

คือ MariaDB:

ER_DATA_TOO_LONG

SQLSTATE:

เมื่อค่าที่กำลังเขียนมีขนาดเกินที่ Column รองรับ.

FiveM Metadata Too Long แก้อย่างไร

ตรวจ:

metadata value length

เทียบกับ:

metadata column type

จากนั้นตรวจ Migration ของ Resource

ถ้า Official Schema ระบุ LONGTEXT แต่ Database ยังเป็น VARCHAR(255) ควร Migration Schema ตาม Resource Version ไม่ใช่ลด Metadata แบบสุ่ม

FiveM Skin Data Too Long แก้อย่างไร

หาก Character Appearance ถูกเก็บเป็น JSON ให้ตรวจทั้ง:

JSON Length
Column Type
Resource Version
Migration

และอย่าปิด Strict Mode เพื่อให้ JSON ถูกตัด เพราะ JSON ที่ถูก Truncate อาจใช้งานไม่ได้

MariaDB JSON Type เป็น LONGTEXT Alias พร้อม JSON Validation Behavior.

FiveM Inventory Data Too Long แก้อย่างไร

ตรวจว่า Resource Version ยังออกแบบให้เก็บ Inventory ใน Column เดียวหรือไม่

หากใช่ ให้ใช้ Data Type ตาม Official Schema

หาก JSON โตผิดปกติ ให้ตรวจ Data Growth/Bug ก่อนขยาย Column

FiveM VARCHAR 255 ไม่พอควรเปลี่ยนเป็นอะไร

ไม่มีคำตอบเดียว

เลือกจาก:

ข้อมูลจริง
Official Schema
Query Pattern
Index Requirement
Maximum Expected Size

อาจเป็น:

VARCHAR ใหญ่ขึ้น
TEXT
MEDIUMTEXT
LONGTEXT

ตาม Use Case โดย MariaDB รองรับ String Types เหล่านี้แยกกัน.

FiveM TEXT กับ LONGTEXT อันไหนดีกว่า

ไม่มีคำว่า “ดีกว่า” เสมอ

LONGTEXT รองรับข้อมูลมากกว่า แต่ Type ที่ใหญ่ที่สุดไม่จำเป็นสำหรับทุก Column

เลือก Type ให้ตรง Requirement และ Official Schema

FiveM JSON ควรใช้ VARCHAR หรือ LONGTEXT

ถ้ากำลังใช้ MariaDB JSON Data Type โดยตรง MariaDB ระบุว่า JSON เป็น Alias ของ LONGTEXT.

แต่ถ้า Resource ไม่ได้ใช้ MariaDB JSON Type ต้องดู Schema ของ Resource นั้นเอง

FiveM ปิด Strict Mode แก้ Data Too Long ได้ไหม

ไม่ควรเป็นทางแก้หลัก

MariaDB ระบุว่าภายใต้ Strict Mode ข้อมูลที่เกินขนาดจะเกิด Error ส่วน Mode อื่นสามารถมี Truncation/Warning Behavior ได้.

สำหรับ Serialized Data/JSON การถูกตัดอาจทำให้ข้อมูลเสีย

FiveM ALTER VARCHAR เป็น TEXT ทำอย่างไร

ตัวอย่าง:

ALTER TABLE `players`
MODIFY COLUMN `metadata` TEXT;

แต่ต้องปรับ Definition ให้ตรงกับ Schema Official รวม:

NULL
DEFAULT
Character Set
Indexes

และควร Backup ก่อน Production Migration

FiveM ALTER TEXT เป็น MEDIUMTEXT ทำอย่างไร

ตัวอย่าง:

ALTER TABLE `players`
MODIFY COLUMN `metadata` MEDIUMTEXT;

MariaDB ระบุว่า MEDIUMTEXT รองรับข้อมูลข้อความได้สูงสุดประมาณ 16 MB.

ใช้เมื่อ Requirement รองรับจริง ไม่ใช่ขยายโดยอัตโนมัติ

FiveM ALTER เป็น LONGTEXT ทำอย่างไร

ตัวอย่าง:

ALTER TABLE `players`
MODIFY COLUMN `metadata` LONGTEXT;

MariaDB ระบุว่า LONGTEXT มี Maximum Capacity ใหญ่มาก แต่ Effective Limit ยังขึ้นกับ Encoding, Packet และ Memory.

ดังนั้นยังต้องควบคุม Data Growth

FiveM Error 1406 หลัง Update Script แก้อย่างไร

ตรวจ:

Resource Version
↓
Migration Files
↓
Current Schema
↓
Official Schema

ก่อน

หาก Schema เก่า ให้ Migration ตาม Version

ถ้า Schemaตรงแต่ Value ใหญ่ผิดปกติ ให้ Debug Resource Data

FiveM Error 1406 หลังย้าย VPS แก้อย่างไร

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

SHOW CREATE TABLE
MariaDB Version
SQL_MODE
Character Set

ระหว่างเครื่องเดิมกับเครื่องใหม่

โดยเฉพาะหากย้ายเฉพาะ Data แต่สร้าง Tables จาก SQL คนละ Version

FiveM Error 1406 เกิดจาก oxmysql ไหม

โดยทั่วไป Error 1406 มาจาก MariaDB เมื่อค่าที่ส่งมาใหญ่เกิน Column Definition ส่วน oxmysql ทำหน้าที่ส่ง Queries/Values ระหว่าง FXServer กับ Database.

จึงควรตรวจ Resource Value และ Schema ก่อน

FiveM ดู Query ที่ทำ Error 1406 ยังไง

ใช้ oxmysql Debug Tools โดย Official Documentation ระบุว่า Real Query Speeds และ Query Debug Information สามารถดูใน Debug UI/Server Console เมื่อเปิด mysql_debug.

จากนั้นหา Query ที่เขียน Column ที่ Error ระบุ

FAQ FiveM MariaDB Data Too Long

Error 1406 คืออะไร

คือ ER_DATA_TOO_LONG เมื่อข้อมูลที่กำลังบันทึกยาวเกิน Column.

SQLSTATE 22001 คืออะไร

เป็น SQLSTATE ที่ MariaDBใช้กับ Error 1406 Data too long for column.

VARCHAR เต็มแล้วทำอย่างไร

ตรวจก่อนว่าข้อมูลถูกต้องหรือไม่ จากนั้นดู Official Schema ว่าควรเพิ่ม VARCHAR หรือเปลี่ยนเป็น TEXT Family

VARCHAR 255 กับ TEXT ต่างกันอย่างไร

VARCHAR มี Maximum Length ตาม Definition และมี Indexing Behavior ต่างจาก TEXT; MariaDB ระบุความแตกต่างระหว่าง VARCHAR และ TEXT ใน Documentation.

MEDIUMTEXT ใหญ่แค่ไหน

MariaDB ระบุว่ารองรับข้อความสูงสุดประมาณ 16 MB.

LONGTEXT ใหญ่แค่ไหน

MariaDB ระบุ Maximum ระดับประมาณ 4 GB ตาม Type แต่ Effective Maximum อาจต่ำกว่านั้นจาก Encoding, Packet Size และ Memory.

MariaDB JSON คืออะไร

MariaDB JSON เป็น Alias ของ LONGTEXT พร้อม Validation Behavior สำหรับ JSON.

ปิด Strict Mode เพื่อให้ Error หายได้ไหม

ไม่ควรเป็นวิธีหลัก เพราะข้อมูลที่เกินขนาดอาจถูก Truncate แทน และข้อมูล Serialized/JSON อาจเสียได้.

Error เกิดหลัง Update Script เพราะอะไร

สาเหตุหนึ่งที่ควรตรวจคือ Resource Version เปลี่ยนแต่ Database Migration ยังไม่ถูกนำมาใช้ ทำให้ Data Shape ใหม่ใหญ่กว่า Schema เดิม

Error เกิดเฉพาะ Player คนเดียวต้อง ALTER Table ไหม

ไม่ควรรีบ ALTER ทั้ง Table ให้ตรวจ Record/Metadata ของ Player นั้นก่อนว่ามี Data Growth ผิดปกติหรือไม่

Error 1406 กับ Unknown Column เหมือนกันไหม

ไม่ 1406 หมายถึง Column มีอยู่แต่ Value ใหญ่เกิน ส่วน Unknown Column คือ Query อ้าง Column ที่ไม่มีหรือชื่อไม่ตรง

Error 1406 กับ Duplicate Entry เหมือนกันไหม

ไม่ Duplicate Entry เกี่ยวกับ Unique/Primary Key ซ้ำ ส่วน 1406 เกี่ยวกับขนาดข้อมูล

Error 1406 กับ Foreign Key Error เหมือนกันไหม

ไม่ Foreign Key Error เกี่ยวกับ Parent/Child Referential Integrity ส่วน 1406 เกี่ยวกับ Data Type Capacity

ประเด็นสำคัญ

เมื่อ FiveM ขึ้น:

Data too long for column

อย่าเริ่มจาก:

VARCHAR → LONGTEXT

ทันที

ให้เริ่มจาก:

Error 1406
↓
Column ไหน
↓
Resource ไหน
↓
Value Length เท่าไร
↓
Parameters สลับหรือไม่
↓
SHOW CREATE TABLE
↓
Schema Version ตรงไหม
↓
Official Migration ว่าอย่างไร

MariaDB กำหนด Error 1406 สำหรับข้อมูลที่ใหญ่เกิน Column และ VARCHAR/TEXT ภายใต้ Strict Mode จะ Error เมื่อค่าที่ส่งเกินขีดจำกัดตาม Type.

ถ้า Official Schema ระบุว่า Column ควรใหญ่ขึ้นจริง จึงค่อยใช้ ALTER TABLE หลัง Backup และทดสอบ Migration แต่ถ้าค่าที่ส่งเข้า Column ผิด เช่น JSON ถูกใส่ลง identifier เพราะ Parameter Order สลับ การขยาย Column จะเพียงซ่อน Bug

สำหรับ JSON ต้องจำว่า MariaDB ใช้ JSON เป็น Alias ของ LONGTEXT และมี JSON Validation Behavior ของตัวเอง. ดังนั้นหาก Resource เปลี่ยนจาก Metadata สั้นไปเป็น JSON ขนาดใหญ่ Database Schema ต้องถูก Migration ให้ตรงกับ Resource Version

สูตรที่ผู้อ่าน comsiam ควรจำคือ “1406 → วัดข้อมูลก่อน → ดู Schema → แล้วค่อยขยาย Column” และ comsiam แนะนำว่าอย่าเลือก Data Type ที่ใหญ่ที่สุดเพื่อให้ Error หาย เพราะ Schema ที่ดีต้องทั้งรองรับข้อมูลที่ถูกต้องและช่วยเปิดโปงข้อมูลที่ผิดปกติจาก Resource ได้ด้วย