FiveM Database Migration คืออะไร? วิธีอัปเดต Schema, Table และ Column หลังอัปเดต Script โดยไม่ทำข้อมูลพัง

August 13, 2026

FiveM Database Migration คือกระบวนการปรับโครงสร้างฐานข้อมูลให้ตรงกับ Resource หรือ Framework เวอร์ชันใหม่ เช่น เพิ่ม Table, เพิ่ม Column, เปลี่ยนชื่อ Column, เพิ่ม Index หรือปรับ Constraint โดยไม่ทำให้ข้อมูลเดิมของผู้เล่นสูญหาย

FiveM เองไม่ได้กำหนดระบบ Database Migration กลางให้ทุก Resource ใช้เหมือนกัน เพราะแต่ละ Resource สามารถมี Server Scripts และ Dependencies ของตัวเองผ่าน fxmanifest.lua ดังนั้นวิธี Migration ต้องอ้างอิง SQL/Migration Files ของ Resource ที่ใช้งานจริง.

ปัญหาที่พบบ่อยหลังอัปเดต Script เช่น:

Unknown column
Table doesn't exist
Duplicate column
Duplicate key
SQL syntax error
Resource เปิดได้แต่โหลดข้อมูลไม่ได้
Character เข้าไม่ได้หลังอัปเดต

หลายครั้งไม่ได้เกิดจาก oxmysql เสีย แต่เกิดจาก Resource Code กับ Database Schema เป็นคนละ Version

① Database Schema คืออะไร

Schema คือโครงสร้างของฐานข้อมูล เช่น:

Database
│
├── characters
│   ├── id
│   ├── identifier
│   ├── firstname
│   └── lastname
│
├── vehicles
│   ├── id
│   ├── owner
│   └── model
│
└── player_settings
    ├── identifier
    └── theme

ใน MariaDB สามารถสร้าง Table ด้วย CREATE TABLE และแก้โครงสร้าง Table ที่มีอยู่ด้วย ALTER TABLE.

② Database Migration คืออะไร

สมมติ Resource เวอร์ชัน 1 ใช้:

characters
├── id
├── firstname
└── lastname

แต่ Resource เวอร์ชัน 2 ต้องใช้:

characters
├── id
├── firstname
├── lastname
└── created_at

Migration คือการทำให้ Database เดิมเปลี่ยนจาก:

v1
↓
ALTER TABLE
↓
v2

โดยเก็บข้อมูล Character เดิมไว้

③ ทำไมอัปเดต Script แล้ว Database Error

เพราะอัปเดต Resource Files อย่างเดียวไม่ได้หมายความว่า Database Schema จะเปลี่ยนตามอัตโนมัติ

ตัวอย่าง:

Resource ใหม่
↓
Code เรียก column `last_seen`

แต่ Database เก่า
↓
ไม่มี `last_seen`

ผล
↓
Unknown column

MariaDB รองรับการเพิ่ม เปลี่ยนชื่อ เปลี่ยน Definition และลบ Columns ด้วย ALTER TABLE; Resource Developer จึงอาจแจก Migration SQL แยกมากับ Version ใหม่.

④ อัปเดต Resource ต้องหา Migration SQL ก่อน

ก่อน Copy Resource ใหม่ทับของเก่า ให้ตรวจ Package เช่น:

resource/
├── fxmanifest.lua
├── client/
├── server/
├── sql/
├── migrations/
├── install.sql
└── update.sql

ชื่อจริงขึ้นกับ Resource

ให้หา:

.sql
migration
update
upgrade
schema

รวมถึง Release Notes ของ Resource นั้น

⑤ install.sql กับ migration.sql ต่างกันอย่างไร

โดยแนวคิด:

install.sql

ใช้สร้าง Schema ตั้งแต่ต้น เช่น:

CREATE TABLE `player_settings` (
    `identifier` VARCHAR(64) NOT NULL,
    `theme` VARCHAR(30) NOT NULL
);

migration.sql

ใช้แก้ Schema ที่มีข้อมูลแล้ว เช่น:

ALTER TABLE `player_settings`
ADD COLUMN `language` VARCHAR(10) NULL;

จุดสำคัญคือ อย่า Import install.sql ทับ Production Database แบบสุ่ม หาก Script มี Migration File สำหรับ Version Upgrade อยู่แล้ว

⑥ ก่อน Migration ต้อง Backup หรือไม่

ต้อง

MariaDB มีทั้ง Logical Backup ผ่าน mariadb-dump และ Backup/Restore Tools อื่นสำหรับ Production Database.

ก่อนเปลี่ยน:

Table
Column
Index
Constraint
Data Type

ควรมี Backup ที่สามารถ Restore ได้จริง

⑦ ทำไม Backup สำคัญมาก

Migration ผิดอาจทำให้:

Column ถูกลบ
Data Type แปลงข้อมูลผิด
Rows ถูก Update ผิด
Index/Constraint ทำให้ Import ไม่ผ่าน
Resource เขียนข้อมูลใหม่ทับข้อมูลเก่า

หากไม่มี Backup การย้อนกลับอาจทำไม่ได้

MariaDB มีคู่มือแยกสำหรับสร้าง Dump และ Restore Dump Files โดยใช้ MariaDB Client.

⑧ Backup ต้องทดสอบ Restore ด้วยหรือไม่

ควร

แนวคิด:

Backup สำเร็จ
≠
Restore สำเร็จแน่นอน

กระบวนการที่แข็งแรงกว่า:

Backup
↓
ตรวจไฟล์
↓
Restore ลง Test Database
↓
ตรวจ Tables / Rows
↓
จึงทำ Production Migration

MariaDB จัด Backup และ Restore เป็นกระบวนการคู่กันอย่างชัดเจนใน Documentation.

⑨ ALTER TABLE คืออะไร

ALTER TABLE ใช้แก้โครงสร้าง Table ที่มีอยู่

เช่น:

เพิ่ม Column
Drop Column
Rename Column
เปลี่ยน Column Definition
เพิ่มหรือลบ Index
เปลี่ยน Constraint

MariaDB รองรับ Operations เหล่านี้ผ่าน ALTER TABLE.

⑩ วิธีเพิ่ม Column

ตัวอย่าง:

ALTER TABLE `characters`
ADD COLUMN `last_seen` DATETIME NULL;

หลัง Migration:

characters
├── id
├── identifier
├── firstname
├── lastname
└── last_seen

MariaDB รองรับ ADD COLUMN ผ่าน ALTER TABLE.

⑪ เพิ่ม Column แล้วข้อมูลเก่าจะหายไหม

การเพิ่ม Column ไม่ได้หมายถึงลบ Rows เดิม

แต่ต้องพิจารณา:

NULL หรือ NOT NULL?
มี DEFAULT หรือไม่?
Table ใหญ่แค่ไหน?
MariaDB Version อะไร?
Operation ต้อง Rebuild Table หรือไม่?

MariaDB มีทั้ง Traditional และ Instant/Online DDL Capabilities ซึ่ง Behavior และ Cost แตกต่างตาม Version, Storage Engine และชนิด Operation.

⑫ เพิ่ม NOT NULL Column ต้องระวัง

สมมติมี Player Records อยู่แล้ว 500,000 Rows แล้วเพิ่ม:

ALTER TABLE `characters`
ADD COLUMN `status` VARCHAR(20) NOT NULL;

ต้องรู้ว่าข้อมูลเก่าจะมีค่าอะไร

บาง Schema จึงเลือก:

ALTER TABLE `characters`
ADD COLUMN `status`
VARCHAR(20) NOT NULL DEFAULT 'active';

แต่ Default ที่เหมาะสมต้องอิง Business Logic ของ Resource ไม่ควรเดาเอง

⑬ วิธี Rename Column

MariaDB รองรับ Syntax:

ALTER TABLE `characters`
RENAME COLUMN `old_name` TO `new_name`;

ตัวอย่าง:

ALTER TABLE `characters`
RENAME COLUMN `surname` TO `lastname`;

แต่ Resource Code ทุกจุดต้องใช้ชื่อใหม่ให้ตรงกันด้วย

⑭ เปลี่ยนชื่อ Column แล้ว Resource เก่ายังใช้ได้ไหม

ถ้า Resource เก่ายัง Query:

SELECT `surname`
FROM `characters`;

แต่ Database ถูกเปลี่ยนเป็น:

lastname

Resource เก่าจะไม่ตรงกับ Schema ใหม่

ดังนั้น Migration ต้องพิจารณาคู่กัน:

Resource Version
+
Database Version

ไม่ควรอัปเกรด Database แยกจาก Code โดยไม่ดู Compatibility

⑮ DROP COLUMN อันตรายแค่ไหน

ตัวอย่าง:

ALTER TABLE `characters`
DROP COLUMN `legacy_data`;

คือการเอา Column ออกจาก Schema

MariaDB รองรับการ Drop Columns ผ่าน ALTER TABLE แต่การเปลี่ยน Schema ลักษณะนี้ควรถือเป็น Destructive Migration และต้อง Backup ก่อน.

ถ้ามีข้อมูลสำคัญอยู่ใน Column นั้น การ Drop อาจทำให้ข้อมูลหายถาวรจาก Production Database

⑯ อย่า DROP Column เพราะ Script ใหม่ไม่ใช้

ก่อนลบตรวจ:

Resource ปัจจุบันใช้ไหม
Framework ใช้ไหม
Admin Tool ใช้ไหม
Script อื่นใช้ไหม
Migration เก่าต้องใช้ไหม
Reporting ใช้ไหม
Backup มีไหม

Database อาจถูกแชร์โดยหลาย Resources

อย่าดูเฉพาะ Resource ที่เพิ่งอัปเดตตัวเดียว

⑰ Table doesn't exist แก้อย่างไร

ถ้า Error:

Table 'fivem.player_settings' doesn't exist

แปลว่า Database Connection ผ่านมาไกลพอที่จะ Execute SQL แล้ว แต่ Table ที่ Query ต้องการไม่มี

ตรวจ:

① Database ถูกตัวหรือไม่
② install.sql Import แล้วหรือยัง
③ Migration สร้าง Table นี้หรือไม่
④ Table Name ตรงหรือไม่
⑤ Resource Version ตรงกับ SQL หรือไม่

MariaDB ใช้ CREATE TABLE สำหรับสร้าง Table ใหม่.

⑱ Unknown column แก้อย่างไร

ตัวอย่าง:

Unknown column 'last_seen'

ตรวจ:

Resource Query
↓
ต้องการ last_seen

Database Schema
↓
มี last_seen หรือไม่

ถ้าไม่มี ให้ค้น Migration ที่มาพร้อม Resource ก่อนเขียน ALTER TABLE เอง

⑲ Duplicate column เกิดจากอะไร

มักเกิดเมื่อ Migration พยายาม:

ALTER TABLE `characters`
ADD COLUMN `last_seen` DATETIME NULL;

แต่ Database มี Column นี้อยู่แล้ว

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

Migration เคย Run แล้ว
Import SQL ซ้ำ
Database ถูกอัปเดตบางส่วน
ใช้ Migration ผิด Version

อย่า Drop Column เพื่อให้ Migration Run ใหม่โดยไม่ดูข้อมูลข้างใน

⑳ Duplicate key เกี่ยวกับ Migration อย่างไร

Resource Version ใหม่อาจเพิ่ม:

PRIMARY KEY
UNIQUE KEY
INDEX

แต่ Data เดิมอาจมีค่าซ้ำที่ขัดกับ Constraint ใหม่

MariaDB Constraints สามารถใช้บังคับ Data Integrity เช่นความไม่ซ้ำของค่าผ่าน Unique Constraints.

ดังนั้นก่อนเพิ่ม Unique Constraint อาจต้องตรวจและ Cleanup Existing Data ก่อน

㉑ Migration เพิ่ม Index ได้ไหม

ได้

เช่น:

CREATE INDEX `idx_characters_identifier`
ON `characters` (`identifier`);

MariaDB รองรับ CREATE INDEX และมี IF NOT EXISTS สำหรับ Index Name ใน Syntax ที่รองรับ.

แต่ Index ใหม่ต้องออกแบบจาก Query Pattern ไม่ใช่เพิ่มทุก Column

㉒ Migration ลบ Index ได้ไหม

ได้

MariaDB มี DROP INDEX ซึ่งถูก Map ไปยัง ALTER TABLE ในการลบ Index.

ก่อนลบต้องตรวจ Queries ทั้งระบบ เพราะ Resource อื่นอาจพึ่ง Index นั้นด้าน Performance

㉓ Foreign Key Migration ต้องระวังอะไร

MariaDB Foreign Keys บังคับความสัมพันธ์ระหว่าง Child/Parent Rows และสร้างได้ผ่าน CREATE TABLE หรือ ALTER TABLE.

ก่อนเพิ่ม Foreign Key ต้องตรวจ:

Data เดิมมี Orphan Rows หรือไม่
Data Types ตรงกันหรือไม่
Indexes รองรับหรือไม่
Delete Behavior เป็นอย่างไร

ไม่ควร Copy Foreign Key SQL ลง Production โดยไม่ตรวจ Existing Data

㉔ Resource Update แล้ว SQL Import ใหม่ทั้งหมดดีไหม

ไม่ใช่วิธีที่ปลอดภัยเสมอ

ถ้า install.sql มี:

CREATE TABLE ...

สำหรับการติดตั้งใหม่ แต่ Production มี Tables และข้อมูลอยู่แล้ว การ Import File ใหม่ทั้งก้อนอาจ:

Error
สร้าง Object ซ้ำ
แก้ Schema ไม่ครบ
ทำให้เกิด Conflict

ให้ใช้ Upgrade/Migration Instructions ของ Resource Version นั้นก่อน

㉕ ห้าม DROP DATABASE เพื่อแก้ Update Error

ถ้า Server มีข้อมูลจริง:

Characters
Vehicles
Profiles
Settings
Logs

การลบ Database แล้ว Install ใหม่เป็นวิธีที่รุนแรงเกินไป

ควรทำ:

Backup
↓
ตรวจ Error
↓
หา Migration
↓
Test
↓
แก้เฉพาะ Schema ที่ต้องเปลี่ยน

㉖ FiveM Resource มี Schema Version กลางไหม

ไม่มีมาตรฐาน Database Schema Version เดียวสำหรับ Resources ทั้งหมด

FiveM Resource เป็นชุด Files/Scripts ที่สามารถ Start, Stop และ Restart แยกกัน และ Manifest ใช้กำหนด Scripts/Metadata ของ Resource.

แต่ละ Framework/Resource จึงสามารถกำหนด Migration Strategy ของตัวเองได้

㉗ fxmanifest.lua บอก Database Migration ไหม

ไม่จำเป็น

fxmanifest.lua มีหน้าที่เป็น Resource Manifest สำหรับ Scripts และ Metadata ของ Resource.

ตัวอย่าง oxmysql Lua Integration:

server_script '@oxmysql/lib/MySQL.lua'
server_script 'server.lua'

oxmysql ระบุให้ Library อยู่ก่อน Scripts ที่ต้องใช้ Database API.

แต่ Migration SQL อาจอยู่ใน Folder อื่นตาม Resource Design

㉘ oxmysql เปลี่ยน Schema ให้อัตโนมัติไหม

oxmysql เป็น Database Wrapper สำหรับ Resource และให้ APIs สำหรับ Query Database; การติดตั้งกำหนด Connection String และ Library Integration แยกจาก Schema Design ของแต่ละ Resource.

ดังนั้นอย่าคาดหวังว่า:

Update oxmysql
↓
Database Tables ของทุก Script Update เอง

Resource แต่ละตัวต้องจัดการ Schema/Migration ของตัวเอง

㉙ Resource Start แล้วทำ Migration อัตโนมัติได้ไหม

Developer สามารถเขียน Server Code ให้ตรวจหรือแก้ Database ได้เอง เพราะ Resource สามารถมี Server Scripts และ oxmysql Query APIs ได้.

แต่ Auto Migration ต้องออกแบบอย่างระมัดระวัง โดยเฉพาะ Destructive Changes

ระบบ Production ที่ดีควรแยก:

Safe automatic migration

ออกจาก:

DROP/Transform ข้อมูลสำคัญ

㉚ Database Migration ควรมี Version Table ไหม

สำหรับ Resource ที่พัฒนาเอง การเก็บ Migration Version ช่วยให้รู้ว่า Database ผ่าน Migration ใดมาแล้ว

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

resource_schema_versions

resource_name
schema_version
updated_at

Flow:

Resource Version 5
↓
Database Schema Version 3
↓
Run Migration 4
↓
Run Migration 5
↓
Save Version 5

นี่เป็น Application Design Pattern ไม่ใช่ข้อกำหนดของ FiveM

㉛ อย่า Run Migration ซ้ำโดยไม่มีระบบป้องกัน

Migration:

ALTER TABLE `characters`
ADD COLUMN `last_seen` DATETIME;

ถ้า Run ซ้ำอาจ Error เพราะ Column มีอยู่แล้ว

Developer ควรออกแบบ Migration ให้รู้:

Migration ไหนเคย Run
Migration ไหนยังไม่ Run

แทนการ Execute SQL ทุกไฟล์ทุกครั้งที่ Resource Start

㉜ Migration Order สำคัญไหม

สำคัญเมื่อ Migration หลังพึ่ง Migration ก่อน

ตัวอย่าง:

001_create_table
↓
002_add_character_id
↓
003_add_index_character_id

หาก Run:

ก่อน 002

Column ที่ต้องสร้าง Index อาจยังไม่มี

ดังนั้น Migrationควรถูก Apply ตาม Version Order

㉝ Migration ข้ามหลาย Version ทำอย่างไร

สมมติ:

Database = v2
Resource = v6

อย่า Run เฉพาะ:

v6 migration

โดยไม่อ่าน Instructions

อาจต้อง:

v2 → v3
v3 → v4
v4 → v5
v5 → v6

หรือ Resource อาจมี Consolidated Migration File

ให้ยึด Documentation ของ Resource นั้น

㉞ Migration ควรทำตอน Server เปิดให้ผู้เล่นอยู่ไหม

สำหรับ Schema Change สำคัญควรหลีกเลี่ยง Production Load หากทำได้

MariaDB ระบุว่า DDL Operations บางชนิดสามารถใช้ Online/Instant Algorithms ได้ แต่ Behavior แตกต่างตาม Operation, Version และ Storage Engine และบางการแก้ Table อาจมี Cost ตามขนาด Table/Indexes.

ดังนั้น Database ใหญ่ควร:

Maintenance Window
+
Backup
+
Test

ก่อน

㉟ ADD COLUMN Table ใหญ่ใช้เวลานานไหม

ขึ้นกับ MariaDB Version, InnoDB Capability และชนิด Alter

MariaDB มี Instant ADD COLUMN สำหรับบาง Version/Conditions ซึ่งสามารถลดงานเมื่อเทียบกับการ Rebuild Table แต่ไม่ควรสมมติว่าทุก ALTER TABLE เป็น Instant.

ตรวจ Version และ Operation จริงก่อน Production

㊱ Migration เปลี่ยน Data Type ต้องระวัง

ตัวอย่าง:

VARCHAR
↓
INT

หรือ:

LONGTEXT
↓
JSON

อาจมี Existing Values ที่แปลงไม่ได้

ก่อนเปลี่ยนควร:

ตรวจข้อมูลเดิม
↓
ทดสอบ Conversion
↓
Backup
↓
Migration Test

อย่าทำ Production โดยไม่ดูข้อมูลจริง

㊲ Migration Rename ดีกว่า Drop + Add

ถ้าจุดประสงค์คือเปลี่ยนชื่อ Column:

surname
→
lastname

การ Rename ช่วยรักษาความหมายว่าเป็นข้อมูลชุดเดิม โดย MariaDB มี RENAME COLUMN ผ่าน ALTER TABLE.

ถ้าใช้:

DROP surname
ADD lastname

โดยไม่ Copy Data อาจทำข้อมูลเก่าหาย

㊳ Migration แบ่งเป็น Safe กับ Destructive

Safe-ish Changes

เช่น:

เพิ่ม Nullable Column
เพิ่ม Index ที่ทดสอบแล้ว
สร้าง Table ใหม่

Destructive Changes

เช่น:

DROP COLUMN
DROP TABLE
เปลี่ยน Data Type
Delete/Transform Existing Data

แม้กลุ่มแรกก็ยังต้องทดสอบ แต่กลุ่มหลังควรมี Backup/Rollback Plan ชัดเจนกว่า

㊴ Rollback Migration คืออะไร

คือวิธีย้อน Database กลับเมื่อ Migration ใหม่มีปัญหา

อาจเป็น:

Reverse SQL

หรือ:

Restore Backup

MariaDB รองรับการ Restore Dump Files ที่สร้างจาก mariadb-dump.

㊵ ทุก Migration ย้อนกลับด้วย SQL ได้ไหม

ไม่จำเป็น

สมมติ Migration:

DROP COLUMN `legacy_json`;

แล้ว Column มีข้อมูลจริง

การ:

ADD COLUMN `legacy_json`;

กลับมาไม่ได้ทำให้ข้อมูลเก่ากลับมาด้วย

จึงต้องพึ่ง Backup

นี่คือเหตุผลที่ Destructive Migration ต้อง Backup ก่อน

㊶ Test Database สำคัญอย่างไร

ก่อน Production:

Copy Schema/Data ตัวอย่าง
↓
Import Resource ใหม่
↓
Run Migration
↓
Start FXServer
↓
ตรวจ Console
↓
ทดสอบ Gameplay

หากมีปัญหา ผู้เล่นจริงและ Production Data จะไม่ถูกกระทบทันที

㊷ หลัง Migration ต้อง Restart Resource ไหม

ขึ้นกับ Resource

ถ้า Resource Start ก่อน Migration แล้ว Code หรือ Cache ถูก Initialize จาก Schema เดิม การ Restart Resource หลัง Migration อาจจำเป็นเพื่อให้ Initialization ทำงานใหม่

FiveM Resources สามารถ Start, Stop และ Restart ได้แยกกัน.

แต่ Database Schema เองไม่ได้ต้องรอ FXServer Restart เพื่อ “เปิดใช้งาน” การเปลี่ยนที่ Database Commit สำเร็จ

㊸ restart กับ ensure ใช้ต่างกันอย่างไร

FiveM Server Commands รองรับการ Start/Restart Resources และ refresh สำหรับ Rescan Resource Manifests.

หลังอัปเดต Resource Files ต้องเลือก Command ให้เหมาะกับสถานการณ์และ Resource Dependencies

อย่า Restart Framework หลักกลาง Production โดยไม่รู้ Side Effects

㊹ Schema Migration แล้ว Connection Error เกี่ยวกันไหม

เป็นคนละ Layer

Unable to establish connection
→ Connection Layer

Unknown table / column
→ Schema Layer

ถ้า oxmysql เชื่อม Database ไม่ได้ Migration SQL ก็ยังทำงานผ่าน Resourceไม่ได้

ต้องแก้ Connection ก่อน

㊺ Schema Error กับ Slow Query ต่างกันอย่างไร

Schema Error

Column ไม่มี
Table ไม่มี
Constraint ไม่ตรง

Performance Error

Query ทำงานได้
แต่ช้า

Slow Query ต้องวิเคราะห์ Index, Query Plan และ Workload แยกจาก Migration

oxmysql มี Slow Query Warning และ Debug Tools สำหรับ Query Performance.

㊻ อัปเดต oxmysql แล้วต้อง Migration Database ไหม

ไม่จำเป็นเสมอไป

oxmysql เป็น Wrapper/Database Resource ส่วน Schema ของ Characters, Vehicles หรือ Settings มักเป็นของ Framework/Gameplay Resource

ดังนั้น:

oxmysql update

ไม่เท่ากับ:

Gameplay Database Migration

ให้ดู Release Notes ของ Resource ที่เป็นเจ้าของ Table นั้นโดยตรง

㊼ MySQL 8 กับ MariaDB Schema ต่างกันได้ไหม

oxmysql Documentation ระบุว่า FiveM Resources จำนวนมากเดิมออกแบบสำหรับ MySQL 5.7 และอาจเจอ Compatibility Issues กับ MySQL 8 เช่น Reserved Keywords และ LONGTEXT/JSON Default Behaviors โดย oxmysql แนะนำ MariaDB สำหรับ Compatibility.

ดังนั้น SQL Migration ที่ใช้ได้กับ Environment หนึ่งอาจต้องตรวจ Compatibility ก่อนใช้กับอีก Environment

㊽ Resource ใช้คำว่า stored แล้ว Migration Error

oxmysql ยก stored และ group เป็นตัวอย่าง Reserved Keywords ที่ Resources เก่าอาจเจอปัญหากับ MySQL 8.

ดังนั้นหาก Error เกี่ยวกับชื่อ Column/SQL Syntax หลังเปลี่ยน Database Engine ให้ตรวจ Compatibility ก่อนสรุปว่า Migration File เสีย

㊾ Migration แล้ว Query ยัง Error

ตรวจ:

Migration Run ครบหรือไม่
↓
Database ถูกตัวหรือไม่
↓
Column Name ตรงหรือไม่
↓
Resource ใหม่ถูกโหลดจริงหรือไม่
↓
Resource Cache/Old Files มีไหม
↓
Framework Version ตรงหรือไม่

อย่า Run Migration ซ้ำทันทีโดยไม่ตรวจ Database ก่อน

㊿ วิธีตรวจ Table Structure

ใช้ Database Management Tool หรือ SQL Metadata Commands ของ MariaDB เพื่อดู:

Tables
Columns
Indexes
Constraints

จากนั้นเปรียบเทียบกับ SQL ที่ Resource ต้องการ

เป้าหมายคือหา Difference ระหว่าง Expected Schema กับ Actual Schema

51. วิธีวิเคราะห์ Unknown Column แบบเร็ว

Error:

Unknown column 'garage_id'

ทำ:

① Resource ไหน Error
② File/Query ไหน
③ Table ไหน
④ Schema มี garage_id หรือไม่
⑤ Release มี Migration เพิ่ม garage_id หรือไม่
⑥ Backup
⑦ Run Migration ที่ถูก Version
⑧ Restart/Test Resource

ไม่ควรเพิ่ม Column ด้วย Data Type ที่เดาเองถ้ายังหา SQL Official ของ Resource ได้

52. วิธีวิเคราะห์ Table Doesn't Exist

Error:

Table 'fivem.vehicle_metadata' doesn't exist

ทำ:

① Database Name ถูก?
② Resource install.sql มี Table นี้?
③ Migration สร้าง Table นี้?
④ SQL Import สำเร็จ?
⑤ ใช้ Prefix/Table Name ถูก?
⑥ Resource Version ตรง?

53. วิธีวิเคราะห์ Duplicate Column

Error:

Duplicate column name 'last_seen'

ทำ:

① ตรวจ Schema
② ดูว่า Column มีอยู่จริง
③ ตรวจ Migration History
④ อย่า Run File เดิมซ้ำ
⑤ ตรวจว่า Migration ต่อไปคือไฟล์ไหน

อย่า Drop Column เพื่อให้ Error หาย หาก Column มีข้อมูลอยู่แล้ว

54. วิธีวิเคราะห์ Duplicate Entry ตอนเพิ่ม UNIQUE

ถ้า Migration ต้องเพิ่ม:

UNIQUE(identifier)

แต่ข้อมูลเดิมมี:

identifier A
identifier A

Constraint จะขัดกับ Existing Data

MariaDB Constraints มีหน้าที่บังคับข้อจำกัดของข้อมูลใน Table.

ต้องตัดสินก่อนว่า Duplicate Row ไหนถูกต้อง ไม่ควร Delete แบบสุ่ม

55. Workflow Database Migration ที่แนะนำ

① อ่าน Release Notes
② หา SQL/Migration Files
③ ตรวจ Version ปัจจุบัน
④ Backup Production Database
⑤ Restore Copy ลง Test Database
⑥ Run Migration บน Test
⑦ ตรวจ Tables/Columns/Indexes
⑧ Start Resource Version ใหม่
⑨ ตรวจ Console Errors
⑩ ทดสอบ Character/Data สำคัญ
⑪ ทดสอบ Save
⑫ ทดสอบ Resource Restart
⑬ วัด Query Performance
⑭ ทำ Maintenance Production
⑮ Run Migration
⑯ Verify Schema
⑰ Start/Restart Resource
⑱ Monitor Errors

Checklist ก่อนอัปเดต FiveM Database

รู้ Resource Version ปัจจุบัน
รู้ Version ที่กำลังอัปเดต
อ่าน Migration Instructions
หา .sql Files
Backup Database
Backup Resource Files
ทดสอบ Restore
มี Test Database
ตรวจ Table ปัจจุบัน
ตรวจ Columns
ตรวจ Indexes
ตรวจ Constraints
ตรวจ Duplicate Data
ตรวจ Database Engine
ตรวจ MariaDB/MySQL Version
ตรวจ Resource Dependencies
ตรวจ oxmysql Version
Run Migration ตามลำดับ
ไม่ Run Migration ซ้ำ
ไม่ Import install.sql ทับแบบสุ่ม
ไม่ DROP Database
ไม่ DROP Column โดยไม่มี Backup
ไม่เปลี่ยน Data Type แบบเดา
ตรวจ ALTER TABLE
ตรวจ Migration Error ทุกบรรทัด
Restart Resource เมื่อเหมาะสม
ตรวจ Console หลัง Start
ทดสอบ Read Data
ทดสอบ Write Data
ทดสอบ Player Join
ทดสอบ Character Load
ทดสอบ Save
ทดสอบ Resource Restart
ตรวจ Slow Query หลัง Migration
เก็บ Backup เดิมไว้จนมั่นใจ

ตาราง Error หลังอัปเดต Script

Error	จุดที่ควรตรวจ
`Unknown column`	Missing Migration / Column
`Table doesn't exist`	Install SQL / Migration
`Duplicate column`	Migration ถูก Run ซ้ำ
`Duplicate entry`	Existing Data / UNIQUE Constraint
`Unknown database`	Connection String / Database Name
`Access denied`	Database User Permission
SQL Syntax Error	Migration Compatibility
Slow Query หลัง Migration	Index / Query / Data Size
Resource Start Failed	Dependency / Schema / Script

FiveM Unknown Column หลังอัปเดต Script แก้อย่างไร

อย่าเพิ่ม Column ด้วยการเดาทันที

ให้:

Error
↓
หา Resource
↓
หา Query
↓
หา Migration ของ Version นั้น
↓
Backup
↓
Run Migration
↓
Verify Schema

MariaDB มี ALTER TABLE สำหรับเพิ่มหรือเปลี่ยน Columns แต่ Data Type และ Default ต้องตรงกับ Resource ที่ออกแบบ Table นั้น.

FiveM Table Doesn't Exist แก้อย่างไร

ตรวจ install.sql หรือ Migration ของ Resource ว่ามี CREATE TABLE สำหรับ Table นั้นหรือไม่

MariaDB ใช้ CREATE TABLE สำหรับสร้าง Table และรองรับ Constraints/Indexes ภายใน Table Definition.

FiveM Database Migration ต้อง Backup ไหม

ต้องทำเป็นหลักปฏิบัติ

MariaDB มี mariadb-dump สำหรับ Logical Backup และมี Restore Process ผ่าน MariaDB Client.

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

DROP
RENAME
MODIFY
Data Conversion

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

FiveM Migration SQL Run ซ้ำได้ไหม

ขึ้นกับ Migration

บาง Migration ออกแบบให้ Idempotent แต่บาง SQL เช่น:

ALTER TABLE `characters`
ADD COLUMN `last_seen` DATETIME;

อาจ Error หาก Column มีอยู่แล้ว

จึงต้องมี Migration History หรือ Version Tracking แทนการ Run Files ทั้งหมดซ้ำทุกครั้ง

FiveM อัปเดต Script แล้วต้อง Import SQL ใหม่ทุกครั้งไหม

ไม่

Resource Update บาง Versionไม่มี Database Change

บาง Versionมีเฉพาะ:

Lua
JavaScript
Config
NUI

ขณะที่บาง Versionมี Migration

จึงต้องดู Release/Migration Instructions ของ Version นั้น ไม่ใช่ Import SQL ทุกครั้ง

FiveM Database Migration ทำ Server Lag ไหม

Schema Operation บางประเภทอาจใช้ Resources สูงหรือมีผลต่อ Table Availability ขึ้นกับ Operation, Table Size, Storage Engine และ MariaDB Version

MariaDB มี Instant/Online DDL สำหรับบาง Operations แต่ไม่ได้หมายความว่าทุก ALTER TABLE จะไม่มีผลต่อ Production Workload.

Table ใหญ่ควรทำใน Maintenance Window

FiveM Migration เพิ่ม Index ได้ไหม

ได้ แต่ควรตรวจ Query ที่ Resource ใช้งานจริง

MariaDB รองรับ CREATE INDEX และการจัดการ Index ผ่าน DDL.

หลังเพิ่ม Index ควรวัด Query Performance ไม่ใช่ดูเพียงว่า Migration Run ผ่าน

FiveM Migration ต้อง Restart FXServer ทั้งเครื่องไหม

ไม่จำเป็นเสมอไป

Resource สามารถ Restart แยกได้ใน FiveM แต่ Resource หลักหรือ Framework อาจมี Dependencies และ Runtime State ที่ต้องพิจารณา.

Production Server ควรวาง Maintenance Plan ตาม Resource Architecture จริง

FAQ FiveM Database Migration

FiveM Database Migration คืออะไร

คือกระบวนการเปลี่ยน Database Schema ให้ตรงกับ Resource Version ใหม่ เช่นเพิ่ม Table, Column, Index หรือ Constraint โดยพยายามรักษาข้อมูลเดิมไว้

FiveM มีระบบ Database Migration กลางไหม

FiveM Resources สามารถจัดโครงสร้าง Scripts และ Dependencies แยกกันผ่าน Resource Manifest ดังนั้น Migration Strategy ขึ้นกับ Resource/Framework แต่ละตัว.

Unknown Column หลังอัปเดต Script เกิดจากอะไร

สาเหตุที่พบบ่อยคือ Resource ใหม่ต้องการ Column ที่ Database Schema เดิมยังไม่มี จึงควรตรวจ Migration ของ Resource Version นั้นก่อน

ALTER TABLE ใช้ทำอะไร

MariaDB ใช้ ALTER TABLE สำหรับเปลี่ยนโครงสร้าง Table เช่นเพิ่ม ลบ หรือ Rename Columns และจัดการโครงสร้างอื่นของ Table.

ก่อน ALTER TABLE ต้อง Backup ไหม

ควร โดยเฉพาะ Production Database และ Destructive Schema Changes เพราะ MariaDB มีเครื่องมือ Backup/Restore โดยเฉพาะ เช่น mariadb-dump.

Table Doesn't Exist แก้อย่างไร

ตรวจ Install/Migration SQL, Database Name และ Resource Version แล้วสร้าง Table ตาม Schema ที่ Resourceกำหนด ไม่ควรเดา Columns เอง

Duplicate Column แก้อย่างไร

ตรวจว่า Migration เคย Run แล้วหรือไม่และดู Schema ปัจจุบัน อย่า Drop Column ที่มีอยู่เพียงเพื่อ Run Migration ซ้ำ

Migration เพิ่ม UNIQUE KEY แล้ว Error เพราะอะไร

Existing Data อาจมีค่าซ้ำที่ขัดกับ Constraint ใหม่ เพราะ MariaDB Constraints สามารถบังคับความไม่ซ้ำของข้อมูลได้.

DROP COLUMN ย้อนกลับได้ไหม

สามารถสร้าง Column ชื่อเดิมกลับได้ แต่ข้อมูลที่ถูก Drop ไปแล้วไม่ได้กลับมาเอง จึงต้องอาศัย Backup หากต้องการข้อมูลเดิม

Migration ต้องทำตอนปิด Server ไหม

Schema Change สำคัญควรทำใน Maintenance Window หากเป็นไปได้ เพราะผลกระทบของ DDL ขึ้นกับ Operation, Table Size, Storage Engine และ MariaDB Version.

oxmysql ทำ Migration ให้อัตโนมัติไหม

oxmysql เป็น Database Wrapper และให้ Query APIs/Connection Integration ส่วน Schema Migration ของ Gameplay Tables ขึ้นกับ Resource ที่เป็นเจ้าของข้อมูลนั้น.

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

FiveM Database Migration ควรคิดเป็นกระบวนการ:

Resource Version ใหม่
↓
ตรวจ Migration
↓
Backup
↓
Test Database
↓
ALTER / CREATE / INDEX
↓
Verify Schema
↓
Start Resource
↓
Test Read / Write
↓
Monitor

อย่าใช้วิธี:

Script Error
↓
DROP Database
↓
Import ใหม่

กับ Server ที่มีข้อมูลจริง

MariaDB รองรับการปรับ Table ด้วย ALTER TABLE, การสร้าง Tables และ Indexes และมีเครื่องมือ Backup/Restore สำหรับป้องกันข้อมูลก่อน Schema Changes.

จุดที่สำคัญที่สุดคือ Code Version และ Schema Version ต้องไปด้วยกัน เพราะ Resource ใหม่อาจต้องใช้ Table, Column หรือ Index ที่ Database เก่ายังไม่มี ขณะที่การ Run Migration ผิด Version หรือซ้ำหลายครั้งก็สามารถสร้าง Error อีกแบบได้

สำหรับผู้อ่าน comsiam ให้จำสูตร “Backup → Migration → Verify → Test → Production” และ comsiam แนะนำว่าเมื่ออัปเดต FiveM Script อย่า Copy Files ทับแล้ว Restart ทันที ให้ตรวจ SQL/Migration ของ Version นั้นก่อนทุกครั้ง โดยเฉพาะ Server ที่มี Character และข้อมูลผู้เล่นจริง เพราะการเสียเวลา Backup และทดสอบก่อนเพียงเล็กน้อย ปลอดภัยกว่าการกู้ Database หลัง Migration ผิดอย่างมาก