FiveM MySQL Duplicate Entry Error 1062 แก้อย่างไร? วิธีแก้ Duplicate Key, Primary Key และ Unique Index โดยไม่ทำข้อมูลพัง

August 17, 2026

ปัญหา FiveM MySQL/MariaDB Duplicate Entry มักเกิดตอน Resource พยายาม INSERT ข้อมูลใหม่ลง Database แต่ค่าบางอย่างที่กำหนดให้ต้องไม่ซ้ำกลับมีอยู่แล้ว เช่น Character ID, License, Plate, Phone Number, Business ID หรือ Primary Key

ข้อความที่พบได้บ่อย เช่น:

ERROR 1062 (23000): Duplicate entry '123' for key 'PRIMARY'

Duplicate entry 'ABC123' for key 'plate'

ER_DUP_ENTRY

MariaDB กำหนด Error 1062 เป็น ER_DUP_ENTRY และใช้ SQLSTATE 23000 โดย Error จะเกิดเมื่อค่าที่กำลัง Insert ชนกับ PRIMARY KEY หรือ UNIQUE key ที่กำหนดว่าค่านั้นต้องไม่ซ้ำกัน

สำหรับ FiveM ปัญหานี้อาจเกิดกับระบบ เช่น:

Character
Inventory
Garage
Vehicle Ownership
Phone
Business
Banking
Billing
Housing
Job
Whitelist
Ban
Logs

หลักสำคัญคือ อย่าแก้ Duplicate Entry ด้วยการลบ Unique Key หรือ Primary Key ทันที เพราะ Constraint เหล่านี้มักมีหน้าที่ป้องกันข้อมูลซ้ำตั้งแต่ต้น

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

อ่านข้อความ Error → หา Table → หา Key → ตรวจค่าที่ซ้ำ → หาว่าทำไม Resource กำลัง Insert ซ้ำ → แก้ Logic หรือ Data ที่ต้นเหตุ

① FiveM Duplicate Entry คืออะไร

คือ Database ได้รับคำสั่งประมาณ:

INSERT INTO ...

แต่ค่าของ Column ที่ต้อง Unique มีอยู่ใน Table แล้ว

② Error 1062 คืออะไร

MariaDB ใช้ Error 1062 สำหรับกรณี Duplicate Entry บน key ที่ต้องไม่ซ้ำ เช่น Primary Key หรือ Unique Key

③ ตัวอย่าง

มีข้อมูลอยู่แล้ว:

id = 100

Resource พยายาม Insert ใหม่:

id = 100

ถ้า id เป็น Primary Key:

Database จะ Reject

④ PRIMARY KEY คืออะไร

Primary Key คือ Column หรือชุด Columns ที่ใช้ระบุแต่ละ Row แบบไม่ซ้ำ และหนึ่ง Table มี Primary Key ได้เพียงชุดเดียว

⑤ UNIQUE KEY คืออะไร

Unique Key หรือ Unique Index ใช้บังคับไม่ให้ค่าซ้ำใน Column หรือชุด Columns ที่กำหนด

⑥ PRIMARY KEY กับ UNIQUE ต่างกันอย่างไรแบบง่าย

PRIMARY KEY

ใช้ระบุ Row หลัก

UNIQUE

ใช้ป้องกันค่าซ้ำเพิ่มเติม

Table หนึ่งอาจมี:

Primary Key 1 ชุด
Unique Index หลายชุด

⑦ ตัวอย่าง FiveM

Table รถอาจมี:

id
plate
owner
vehicle

โดย:

id = PRIMARY KEY
plate = UNIQUE

ดังนั้นรถสองคันอาจมี id ต่างกัน แต่ถ้า plate ซ้ำก็ยัง Error ได้

⑧ อ่าน Error ให้ครบ

ตัวอย่าง:

Duplicate entry 'ABC123' for key 'plate'

ข้อมูลสำคัญคือ:

ABC123

และ:

plate

⑨ ถ้า Error บอก `PRIMARY`

เช่น:

Duplicate entry '100' for key 'PRIMARY'

ให้ตรวจ Primary Key ของ Table นั้น

⑩ ถ้า Errorบอกชื่อ Key

เช่น:

Duplicate entry '5551234' for key 'phone_number'

ให้ตรวจ Unique Index ที่เกี่ยวข้องกับ Phone Number

⑪ Duplicate Entry ไม่ใช่ Connection Error

ถ้า MariaDB ตอบ Error 1062 ได้ แสดงว่า Query ไปถึง Database แล้ว

จึงไม่ควรเริ่มแก้:

Host
Port
Password

โดยไม่มีเหตุผล

⑫ Duplicate Entry ไม่ใช่ Table Missing

Table มีอยู่และ Databaseกำลังตรวจ Constraint ของ Table นั้น

⑬ Duplicate Entry มักเป็น Data หรือ Application Logic

เช่น:

Resource Insert Row ซ้ำ
ID Generatorสร้างค่าซ้ำ
Migration Importข้อมูลเดิมซ้ำ
Retry Queryแล้ว Insertซ้ำ

⑭ สาเหตุอันดับแรก — Resource INSERT ซ้ำ

ตัวอย่าง:

Playerหนึ่งสร้าง Character

Resource Insert:

citizenid = ABC001

สำเร็จแล้ว

แต่ Code เรียก Insertอีกครั้งด้วยค่าเดิม

จึง Error

⑮ ทำไม Resourceอาจ Insertสองครั้ง

เช่น:

Eventถูกเรียกซ้ำ
Callbackทำงานสองครั้ง
Playerกด Submitซ้ำ
Retry Logicผิด
Resourceถูกออกแบบไม่ Idempotent

⑯ Double Click ทำให้ Duplicate ได้ไหม

ได้ในบาง UI

เช่น Playerกด:

Create Character

สองครั้งก่อน Buttonถูก Disable

⑰ Server Lag อาจทำให้ Playerกดซ้ำ

Playerคิดว่า:

ครั้งแรกไม่ทำงาน

จึงกดอีกครั้ง

แต่ Requestแรกอาจกำลังประมวลผลอยู่

⑱ UI ควร Disable Button หลัง Submit

ช่วยลด Duplicate Request

แต่ Database Unique Constraintยังควรอยู่เป็น Protectionชั้นสุดท้าย

⑲ อย่าลบ Unique Constraintเพียงเพราะ UIกดซ้ำ

เพราะจะทำให้ Databaseยอมรับข้อมูลซ้ำจริง

⑳ สาเหตุ — Import SQL ซ้ำ

ถ้า Dumpมี:

INSERT INTO ...

และ Importซ้ำบน Databaseที่มีข้อมูลอยู่แล้ว

อาจชน Unique Keyทันที

㉑ Restore Backup ซ้ำได้ไหม

ถ้า Restoreเข้าฐานข้อมูลที่มี Rowsเดิม:

Duplicate Entryเกิดได้

㉒ วิธีป้องกัน

ก่อน Restoreต้องรู้ว่า Databaseปลายทาง:

ว่าง
มีข้อมูลอยู่
จะ Merge

แบบไหน

㉓ MigrationกับRestoreไม่เหมือนกัน

Migration:

เปลี่ยน Schema/Dataตาม Version

Restore:

นำ Backupกลับมา

อย่าสับสน

㉔ Import Fresh Dataทับ Productionเสี่ยงมาก

อาจทำให้:

Duplicate IDs
Duplicate Players
Duplicate Vehicles

㉕ สาเหตุ — AUTO_INCREMENT ผิด

Tableบางตัวใช้ AUTO_INCREMENT สำหรับ ID

MariaDB ระบุว่าสามารถกำหนดค่าให้ AUTO_INCREMENT โดยตรงได้ แต่ถ้า Column นั้นเป็น Primary/Unique ค่าที่กำหนดต้องไม่ชนกับค่าที่มีอยู่

㉖ AUTO_INCREMENT คืออะไร

ระบบสร้างเลข ID ต่อเนื่องโดย Database

เช่น:

㉗ Resourceควร Insert IDเองไหม

ถ้า Columnถูกออกแบบเป็น AUTO_INCREMENT:

โดยทั่วไปไม่จำเป็นต้องกำหนด IDเอง

㉘ ตัวอย่าง

ไม่ควร Hardcode:

INSERT INTO logs (id, message)
VALUES (1, 'test');

ทุกครั้ง

เพราะ id = 1 จะซ้ำ

㉙ ให้ Databaseสร้าง ID

ถ้า Schemaออกแบบแบบนั้น

Resourceอาจ Insertเฉพาะ:

message

แล้วให้ AUTO_INCREMENTสร้าง ID

㉚ AUTO_INCREMENT Value ต่ำกว่าข้อมูลจริง

อาจต้องตรวจว่า Sequence/Counterสัมพันธ์กับข้อมูลหรือไม่

แต่ไม่ควรแก้ค่า Counterแบบสุ่ม

㉛ ข้อมูลถูก Importด้วย IDเดิมอาจมีผล

หลัง Migration/Restoreควรตรวจ:

Max ID
Auto Increment State

ถ้าเกิด Duplicate PRIMARYจาก IDsใหม่

㉜ สาเหตุ — Character Identifier ซ้ำ

เช่นระบบกำหนด:

citizenid
identifier
charid

เป็น Unique

แต่ Generatorสร้างค่าซ้ำ

㉝ Random Generatorไม่ได้แปลว่าจะไม่ซ้ำ

ถ้า Designไม่มี Collision Check:

สุ่มซ้ำได้

โดยเฉพาะ Identifierสั้น

㉞ Generatorควรตรวจ Collision

ก่อนใช้ IDใหม่ควรมี Logicป้องกันค่าที่มีอยู่

㉟ UUID คืออะไร

บางระบบใช้ Identifierที่ออกแบบให้มีโอกาสซ้ำต่ำมาก

แต่ Serverไม่จำเป็นต้องเปลี่ยนเป็น UUIDเพียงเพราะเจอ Errorครั้งเดียว

㊱ Plate ซ้ำเป็น Caseยอดนิยมใน Garage

Vehicle Resourceอาจ Generate License Plate

แต่ Plateที่สร้างมีอยู่แล้ว

㊲ Vehicle Plateควร Uniqueไหม

ใน Serverจำนวนมาก Plateใช้เป็น Identifierสำคัญของรถ

จึงมักต้องไม่ซ้ำ

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

㊳ Errorตัวอย่าง

Duplicate entry 'XYZ999' for key 'plate'

ให้ตรวจว่า:

Plateมีอยู่จริงไหม
Generatorตรวจ Plateก่อนหรือไม่

㊴ อย่าลบรถเดิมทันที

เพราะรถเดิมอาจเป็น Owned Vehicleที่ถูกต้อง

ต้องหาเหตุผลว่าทำไมรถใหม่ได้ Plateเดิม

㊵ เปลี่ยน Unique Plateเป็น Non-Uniqueดีไหม

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

เพราะ Systemsเช่น:

Garage
Police
Keys

อาจใช้ Plateระบุรถ

㊶ Phone Number ซ้ำ

Phone Resourceอาจ Generate Numberที่ต้อง Unique

ถ้า Generator Collision:

Characterใหม่อาจสร้างไม่ได้

㊷ Phone Numberควรตรวจ Existingก่อน Assign

ถ้าระบบกำหนด Unique

㊸ Business ID ซ้ำ

Business Scriptอาจสร้าง:

business_id

ด้วยชื่อหรือ IDที่ชนของเดิม

㊹ Business Nameเป็นUniqueเสมอไหม

ไม่จำเป็น

บาง Serverอนุญาตชื่อคล้าย/ซ้ำ

ต้องดู Schema

㊺ Slug/Codeอาจ Uniqueแทน Name

เช่น:

mechanic_bennys

เป็น Internal Identifier

㊻ Job Name ซ้ำ

ตอน Import Job SQLซ้ำอาจเจอ Duplicate Key

เช่น Jobเดิมมีอยู่แล้ว

㊼ Import Scriptใหม่แต่ Jobเดิมมี

ควรดู SQLว่า:

INSERTใหม่
UPDATE existing

แบบไหน

㊽ ไม่ควร Importซ้ำจน “ผ่าน”

เพราะอาจสร้างข้อมูลครึ่งเก่าครึ่งใหม่

㊾ INSERT คืออะไร

MariaDBใช้ INSERT เพื่อเพิ่ม Rowใหม่ และหาก Unique Keyชน ค่า Duplicateสามารถทำให้ Statementล้มเหลวตามปกติ

㊿ INSERT IGNORE คืออะไร

INSERT IGNORE สามารถเปลี่ยน Errorsบางประเภทให้เป็น Warnings และ Rowsที่ผิดอาจถูกข้ามหรือค่าบางอย่างถูกปรับตามชนิด Error

51. ใช้ INSERT IGNORE แก้ Duplicate ดีไหม

ไม่ควรใช้แบบอัตโนมัติ

เพราะมันอาจทำให้คุณมองไม่เห็นว่า:

Resourceกำลังสร้างข้อมูลซ้ำจริง

52. ตัวอย่าง

ถ้าคุณต้องสร้าง Characterใหม่ แต่ citizenid ซ้ำ

การใช้:

INSERT IGNORE

อาจทำให้ Character Rowไม่ถูก Insertเลย

แต่ Codeคิดว่ากระบวนการเดินต่อได้

53. ผลลัพธ์คือข้อมูลครึ่งเดียว

เช่น:

Characterไม่มี Row
Inventoryถูกสร้าง
Phoneถูกสร้าง

กลายเป็น Data Inconsistency

54. ON DUPLICATE KEY UPDATE คืออะไร

MariaDBรองรับ:

INSERT ... ON DUPLICATE KEY UPDATE

ถ้า Insertชน Primary/Unique Key ระบบจะเปลี่ยนไปทำ UPDATE Rowเดิมแทนตามคำสั่งที่กำหนด

55. เรียกว่า Upsert

แนวคิด:

ไม่มี Row → Insert
มี Row → Update

56. Upsertเหมาะกับอะไร

เหมาะเมื่อ Business Logicตั้งใจจริงว่า Recordหนึ่งควร:

มีหนึ่ง Row
ถ้ามีแล้วให้ Update

57. ตัวอย่าง Settings

เช่น Save Player Setting:

player_id + setting

ถ้ามี Rowแล้ว:

Update

อาจสมเหตุสมผล

58. Upsertไม่เหมาะกับอะไร

ไม่ควรใช้แก้ปัญหาที่จริง ๆ ต้องสร้าง Entityใหม่

เช่น:

Vehicleใหม่
Characterใหม่

แต่ ID Generatorกลับสร้าง IDซ้ำ

59. เพราะ Upsertอาจเขียนทับของเดิม

อันตรายมาก

60. ON DUPLICATE KEY UPDATE กับหลาย Unique Index

MariaDB documentation เตือนว่า หากมี Unique Indexมากกว่าหนึ่งชุดและมากกว่าหนึ่งชุดชนกัน ระบบจะ Updateตาม keyที่ matchแรก ดังนั้นจึงไม่ควรใช้รูปแบบนี้แบบไม่คิดใน Tableที่มีหลาย Unique Constraints

61. REPLACE คืออะไร

MariaDBมี REPLACE ซึ่งเมื่อชน Primary/Unique Key จะลบ Rowเดิมแล้ว Insert Rowใหม่

62. REPLACE ไม่ใช่ UPDATEธรรมดา

สำคัญมาก

เพราะ Behaviorคือ:

DELETE old row → INSERT new row

63. REPLACEเสี่ยงกับ FiveMไหม

มากถ้า Rowมี:

Foreign Relationships
Metadata
Created Date

เพราะ Rowเดิมถูกลบ

64. อย่าใช้ REPLACEแก้ Duplicate Character

โดยไม่เข้าใจผลกระทบ

65. เปรียบเทียบสามวิธี

INSERT

ซ้ำ → Error

INSERT ... ON DUPLICATE KEY UPDATE

ซ้ำ → Update

REPLACE

ซ้ำ → Deleteเดิมแล้ว Insertใหม่

MariaDB documentationแยก Behaviorเหล่านี้ไว้ชัดเจน

66. วิธีไหนดีที่สุด

ขึ้นอยู่กับ Business Logic

ไม่ใช่ Error Messageอย่างเดียว

67. Constraintมีไว้ทำอะไร

ป้องกัน Database Stateที่ไม่สมเหตุสมผล

เช่น:

Vehicle Plateเดียวกันหลาย Row
Character IDซ้ำ

68. การลบ Constraint คือการเอาระบบป้องกันออก

อาจทำให้ Errorหาย แต่ Dataเสียแทน

69. Duplicate Entryจึงเป็นสัญญาณ

Databaseกำลังบอก:

Applicationกำลังพยายามสร้างสิ่งที่ควรไม่ซ้ำ

70. ต้องหาคำตอบว่า “ทำไม”

ไม่ใช่เพียง “ทำอย่างไรให้ Errorหาย”

71. ขั้นแรก — ดู Errorเต็ม

ตัวอย่าง:

Duplicate entry 'ABC123' for key 'plate'

72. ขั้นสอง — หา Table

ดู Queryหรือ Stackว่ากำลัง Insert Tableไหน

73. ขั้นสาม — ดู Indexes

สามารถตรวจ Indexของ Tableผ่าน Database Tools หรือ SQL เช่น:

SHOW INDEX FROM your_table;

MariaDBรองรับ Primary, Unique และ Indexชนิดต่าง ๆ สำหรับการกำหนดและค้นข้อมูล

74. ขั้นสี่ — หา Rowเดิม

เช่นถ้า Keyคือ:

plate = ABC123

ตรวจ Rowที่มีค่านี้อยู่แล้ว

75. ใช้ SELECTก่อนแก้

เช่นแนวคิด:

SELECT *
FROM owned_vehicles
WHERE plate = 'ABC123';

เปลี่ยนชื่อ Table/Columnให้ตรง Serverจริง

76. อย่าลบ Rowทันที

ต้องรู้ว่า Rowเดิม:

ถูกต้อง
เสีย
Duplicateจาก Migration

อย่างไหน

77. ถ้า Rowเดิมถูกต้อง

ต้องแก้ Resourceไม่ให้สร้าง IDเดิม

78. ถ้า Rowเดิมเป็นข้อมูลเสีย

ค่อยวางแผน Cleanupหลัง Backup

79. ถ้ามี Duplicateจริงหลาย Rowsได้อย่างไรถ้ามี Unique Key

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

Constraintถูกเพิ่มภายหลัง
Dataมาจาก Tableอื่น
Unique Keyเคยถูกลบ
Valuesต่างกันในรายละเอียด

ต้องตรวจ Schemaจริง

80. Spaceต่างกันอาจถือเหมือนหรือต่าง

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

Column Type
Collation
Data Normalization

จึงควร Inspectค่าจริง

81. Uppercase/Lowercaseอาจมีผล

ขึ้นกับ Collation

เช่น:

ABC123
abc123

อาจถูกมองเท่ากันในบาง Collations

82. Plate Generatorควร Normalize Case

ถ้า Serverต้องการ Plateแบบมาตรฐานเดียว

83. Trim Spaceสำคัญ

Input:

ABC123

กับ:

ABC123

อาจสร้างปัญหา Comparison/Formatting

Applicationควร Normalize Input

84. Phone Numberก็เช่นกัน

ควร Normalize:

Prefix
Separator

ตาม Server Design

85. Duplicate Entryหลัง Database Migration

อาจเกิดเมื่อ Mergeข้อมูลจากสอง Server/Database

ทั้งสองมี:

id = 100

86. Mergeไม่ควร Copy Primary IDsตรง ๆ เสมอ

ต้องวาง Migration Strategy

87. Character IDsชนตอน Merge

อาจต้อง:

Remap IDs
Update Foreign References

นี่เป็นงานที่ควรทำอย่างระวัง

88. เปลี่ยน IDใน Tableเดียวไม่พอ

ถ้า Tablesอื่นอ้างถึง Character IDเดิม:

Relationshipsจะขาด

89. Foreign Referencesคืออะไร

ข้อมูล Tableอื่นที่อ้าง Entityหลัก

เช่น:

Character
→ Vehicles
→ Houses
→ Phone

90. Database Mergeจึงซับซ้อน

ไม่ควรแก้ Duplicateด้วย:

DELETE duplicate row

แบบสุ่ม

91. Duplicate Entryหลัง Import Jobs

อาจไม่ร้ายแรงเท่า Character Merge

แต่ต้องรู้ว่า SQLกำลัง:

Seed Data

ซ้ำ

92. Seed Data คืออะไร

ข้อมูลเริ่มต้น เช่น:

Jobs
Items
Grades

93. Seed Scriptควร Handle Existing Data

Developerอาจเลือก:

Ignore
Update
Delete/Recreate

ตาม Design

94. Resource Installerที่ดีควร Idempotentไหม

ถ้า Installerถูกออกแบบให้ Runซ้ำได้:

ควรไม่สร้าง Duplicate State

แต่ไม่ใช่ทุก Scriptทำแบบนั้น

95. Idempotent คืออะไร

ทำ Actionเดิมซ้ำแล้วผลสุดท้ายไม่เปลี่ยนเกินที่ตั้งใจ

96. FiveM Payment Systemsควรระวัง Idempotencyมาก

เพราะ Retryซ้ำอาจ:

Chargeสองครั้ง
Create Invoiceสองใบ

97. Duplicate Billing

ถ้า Invoice IDถูก Unique:

Errorอาจช่วยหยุด Duplicate

แต่ Root Causeยังต้องแก้

98. Duplicate Transaction ID

Banking Systemอาจใช้ Unique Transaction Reference

ถ้า Generatorซ้ำ:

Insert Fail

99. Transaction Referenceควร Unique

เพื่อแยกแต่ละ Transactionออกจากกัน

100. Duplicate Reward

ถ้า Reward Tableใช้ Unique Claim ID:

Constraintสามารถช่วยป้องกันรับ Rewardซ้ำ

101. Unique Constraintจึงมีประโยชน์ต่อ Economy

ช่วยป้องกัน Duplicateจาก Bugบางประเภท

102. เอา Unique Keyออกอาจเปิด Economy Exploit

เช่น Claim Rewardเดิมซ้ำได้หลาย Row

103. Duplication Exploitต่างจาก SQL Duplicate Error

SQL Duplicate Error

Databaseปฏิเสธ Recordซ้ำ

Item Dupe Exploit

Gameplayสร้าง Assetซ้ำผิดปกติ

แต่ทั้งสองอาจเชื่อมกันถ้า Script Logicไม่ดี

104. Error 1062อาจเป็นสิ่งที่ป้องกัน Dupe

บางกรณี Constraintกำลังทำงานถูกต้อง

105. อย่าแก้ด้วยการ Disable Protection

ควรแก้ Request Logic

106. Duplicate Entryจาก Concurrent Requests

Playerสอง Requestเกิดใกล้กันมาก

ทั้งสองตรวจ:

ไม่มี Row

พร้อมกัน

แล้วทั้งสองพยายาม Insert

107. Race Condition คืออะไร

หลาย Operationsเกิดพร้อมกันและแข่งขันกับข้อมูลเดียวกัน

108. Unique Constraintช่วย Race Condition

แม้ Applicationตรวจว่าไม่มี Record แต่ Databaseยังป้องกัน Insertซ้ำได้

109. Check-then-insertอย่างเดียวไม่พอ

แนวคิด:

SELECT exists?
↓
No
↓
INSERT

ยังมี Race Window

110. Database Constraintยังควรอยู่

เพื่อเป็น Source of Truthสุดท้าย

111. Developerควร Handle Duplicate Error

เช่น:

Retryด้วย IDใหม่
Return Already Exists
Updateตาม Business Logic

แทน Crash

112. Character Creation ตัวอย่าง

Generatorสร้าง:

ABC001

Databaseตอบ Duplicate

Codeควร Generate IDใหม่ถ้า Designเหมาะ

ไม่ควรลบ Characterเดิม

113. Vehicle Plate Generatorเหมือนกัน

หาก Plateชน:

Generateใหม่

อาจเหมาะกว่าเปลี่ยน Unique Constraint

114. Phone Number Generatorก็คล้ายกัน

ต้องรับมือ Collision

115. Unique Code Generatorควรมี Spaceเพียงพอ

ถ้า Codeสั้นเกินและ Playerเยอะ:

Collisionเพิ่มขึ้น

116. จำนวน Possibilitiesสำคัญ

เช่น Code 3หลักมีค่าที่เป็นไปได้จำกัด

Serverโตมากอาจชนง่าย

117. อย่าเพิ่ม Random Lengthแบบสุ่มใน Production

เพราะ UI/Schemaอาจจำกัด Length

118. VARCHAR Lengthต้องรองรับ IDใหม่

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

119. Migrationอาจต้องใช้ถ้าขยาย Identifier

Resourceทุกตัวที่ใช้ Identifierต้องรองรับด้วย

120. Error Duplicate Key Nameต่างจาก Duplicate Entryไหม

ต่างกัน

MariaDBมี Error 1061 สำหรับ Duplicate key name และ Error 1062 สำหรับ Duplicate entry

121. Duplicate Key Name คืออะไร

เกิดตอน Schemaพยายามสร้าง Indexชื่อที่มีอยู่แล้ว

เช่น Migration Runซ้ำ

122. Duplicate Entry คือข้อมูลชน

ส่วน Duplicate Key Nameคือ:

Schema Objectชื่อซ้ำ

123. Error 1060 ล่ะ

MariaDB Error 1060คือ:

Duplicate column name

มักเกิดตอน Migrationพยายามเพิ่ม Columnที่มีอยู่แล้ว

124. Error 1068

คือ Multiple Primary Key Defined

เกิดเมื่อ Tableพยายามกำหนด Primary Keyเกินหนึ่งชุด

125. จึงต้องแยก Duplicateแต่ละชนิด

Error	ความหมายหลัก
1060	Duplicate Column Name
1061	Duplicate Key Name
1062	Duplicate Entry
1068	Multiple Primary Key

MariaDBระบุ Codesเหล่านี้แยกกันใน Error Reference

126. Error 1022 คืออะไร

MariaDBมี Error 1022:

Can't write; duplicate key in table

ซึ่งเกี่ยวกับ Duplicate Keyอีกกรณีหนึ่ง

127. FiveM Server Ownerควรจำทุก Error Numberไหม

ไม่จำเป็น

อ่านข้อความเต็มสำคัญกว่า

128. Duplicate Entryตอน Resource Start

อาจเป็น Seed/Migration Scriptพยายาม Insertข้อมูลที่มีอยู่

129. Duplicate Entryตอน Player Login

ตรวจ:

Session Record
Player Record
Identifier

130. Duplicate Entryตอน Character Creation

ตรวจ:

Character ID
Phone
Account Mapping

131. Duplicate Entryตอนซื้อรถ

ตรวจ:

Vehicle ID
Plate
Ownership Record

132. Duplicate Entryตอนซื้อบ้าน

ตรวจ:

Property ID
Ownership Mapping

133. Duplicate Entryตอนสร้าง Business

ตรวจ:

Business ID
Internal Code

134. Duplicate Entryตอนส่ง Billing

ตรวจ:

Invoice/Reference ID

ถ้า Systemใช้ Unique Reference

135. Duplicate Entryตอน Claim Reward

ตรวจ:

Claim ID
Player Reward Record

136. Duplicate Entryตอน Register Job

อาจ Seed Jobเดิมซ้ำ

137. Duplicate Entryตอน Server Restart

ถ้า Startup Script Insertค่า Defaultทุกครั้งโดยไม่ตรวจ

138. Example Config Seed

Resource Start:

INSERT default settings

ทุก Restart

ถ้า Key Unique:

Errorทุกครั้งหลัง Restartครั้งแรก

139. วิธีแก้

Installer/Seederควรออกแบบให้:

Insertเฉพาะไม่มี
หรือ Upsertถ้า Logicต้อง Update

140. ไม่ควรลบ Default Rowก่อนทุก Restart

เพราะ Settings Player/Adminอาจหาย

141. Duplicate Entryใน Logs Tableควรมีไหม

Logsมักควรมี Unique IDต่อ Event

ถ้า ID Generatorผิดจะ Error

142. AUTO_INCREMENTเหมาะกับ Log ID

ในหลาย Design

เพราะไม่ต้อง Generateเอง

143. UUIDก็ใช้ได้

ขึ้นกับ Architecture

แต่ไม่ต้องเปลี่ยน Database Modelถ้าไม่มีเหตุผล

144. Primary Key Composite คืออะไร

Primary Keyที่ประกอบด้วยหลาย Columns

เช่น:

player_id + reward_id

เพื่อให้ Playerหนึ่ง Claim Rewardหนึ่งครั้ง

145. Duplicate Entryแบบ Composite

Error Valueอาจแสดงค่าหลายส่วนรวมกัน

ต้องดู Key Definition

146. Composite Uniqueมีประโยชน์ FiveM

เช่น:

Player + Item Slot
Player + Reward
Business + Employee

ตาม Data Model

147. ถ้า Duplicate Compositeเกิดขึ้น

ไม่ได้แปลว่าแต่ละ Columnซ้ำผิด

แต่ Combinationทั้งหมดซ้ำ

148. ตัวอย่าง

มีอยู่แล้ว:

player = 10
reward = daily

Insertซ้ำ Combinationเดิม:

Error

149. นี่อาจเป็น Protectionที่ตั้งใจ

ป้องกัน Daily Rewardซ้ำ

150. อย่าแก้ Unique Constraintโดยไม่รู้ Business Rule

เพราะมันอาจมีไว้ป้องกัน Abuseโดยตรง

151. วิธีดู Primary/Unique Keys

ใช้:

SHOW CREATE TABLE your_table;

หรือ:

SHOW INDEX FROM your_table;

152. SHOW CREATE TABLEสำคัญ

เพราะเห็น:

Primary Key
Unique Keys
Column Types

พร้อมกัน

153. ถ้า Keyชื่อ `PRIMARY`

ดู Definitionของ Primary Key

154. ถ้า Keyชื่อ Custom

เช่น:

unique_plate

ดูว่า Indexใช้ Columnใด

155. Keyอาจประกอบหลาย Columns

อย่าดูชื่อ Errorแล้วเดาเพียง Columnเดียว

156. Backupก่อน DELETE Duplicate Data

จำเป็น

157. วิธีลบ Duplicate Rowต้องรู้ว่า Rowไหนถูก

อย่าทำ:

DELETE ...

ก่อนตรวจ Ownership/Relations

158. Data Cleanupควรเริ่มจาก SELECT

หา Rowsก่อน

159. Export Rowsที่กำลังจะแก้

ช่วย Recoveryถ้าตัดสินใจผิด

160. Production Duplicate Cleanupต้องระวัง Relationships

เช่น Vehicle Rowอาจเชื่อม:

Keys
Finance
Garage

161. ลบรถ Duplicateหนึ่ง Rowอาจทำ Key Recordsกำพร้า

เรียกว่า Orphan Data

162. Orphan Data คืออะไร

Recordใน Tableรองที่อ้าง Entityหลักซึ่งไม่มีแล้ว

163. Database Constraint Foreign Keyช่วยได้ไหม

บาง Schemasใช้ Foreign Keysเพื่อป้องกันบางกรณี

แต่ FiveM Resourcesไม่ได้ใช้เหมือนกันทั้งหมด

164. ตรวจ Resource Relationsก่อน Cleanup

สำคัญกว่าแก้ Errorเร็ว ๆ

165. ถ้า Duplicateเกิดจาก Test Data

อาจ Cleanได้ง่ายกว่า Production Player Data

แต่ Backupยังควรมี

166. อย่าใช้ Production Tableเป็นสนามทดลอง

ใช้:

Staging
Backup Copy

ถ้าเป็น Migrationใหญ่

167. Duplicate Entryหลัง Clone Database

ถ้า Test Serverเชื่อม Production Databaseโดยผิดพลาด:

อาจสร้างข้อมูลชนได้

168. Test Serverควรใช้ Databaseแยก

โดยเฉพาะ Character/Vehicle IDs

169. Development Resourceยิง Queryเข้า Productionอันตรายมาก

อาจ:

Create
Update
Duplicate

ข้อมูลจริง

170. ตรวจ Connection Stringของ Dev/Test

ก่อนเปิด Serverทดสอบ

171. Duplicate Entryอาจช่วยเตือนว่าคุณต่อ DBผิดตัว

เช่น Test Character IDชน Production Character

172. Server Migration Checklist

Backup
Databaseปลายทางถูก
IDsไม่ชน
Resourcesตรง Version
Migrationsครบ

173. Database Mergeต้องมี Planเฉพาะ

อย่าเพียง:

Import A
Import B

เข้าตารางเดียว

174. Merge Player IDs

ต้องตรวจ:

Account Mapping
Character IDs
Foreign Data

ทั้งหมด

175. Server Ownerมือใหม่ไม่ควร Mergeฐานข้อมูลใหญ่เองถ้าไม่เข้าใจ Relations

เพราะ Error 1062อาจเป็นเพียงปัญหาแรก

176. Duplicate Entryหลัง Migrationอาจเกิดหลาย Tables

เพราะ IDชนกันเป็น Chain

177. Fix Tableแรกแล้ว Tableต่อไปอาจชน

จึงต้องวาง ID Remappingทั้งระบบ

178. ID Remapping คืออะไร

เปลี่ยน IDsพร้อม Update Referencesทั้งหมด

179. ไม่ใช่แค่ `id + 1000`

ถ้ามี Referencesหลาย Tableต้อง Updateตาม

180. Resourceใช้ String Identifierอาจ Mergeง่าย/ยากต่างกัน

ขึ้นกับ Data Model

181. Duplicate Entryจาก Plateมักแก้ง่ายกว่า Character ID Merge

เพราะ Scopeอาจเล็กกว่า

แต่ก็ต้องตรวจ Keys/Ownership

182. Plate Changeควรทำผ่าน Official Vehicle Systemถ้ามี

เพื่อให้ Related Tables Sync

183. Manual UPDATE Plateอาจทำข้อมูลอื่นไม่ตรง

เช่น:

Vehicle Keys
Impound
Finance

ถ้า Tablesเหล่านั้นเก็บ Plate

184. Phone Number Changeก็เหมือนกัน

Phone Resourceอาจมี:

Contacts
Messages
Calls

เชื่อมกับ Number

185. อย่าแก้ Unique Identifierเพียง Tableเดียวโดยไม่รู้ Relations

หลักเดียวกันใช้กับ:

Business ID
Character ID

186. Duplicate Character Nameต่างจาก Character ID

ชื่อ Characterอาจซ้ำได้หรือไม่ได้ตาม Server Design

อย่าคิดว่าต้อง Uniqueเสมอ

187. Database Constraintเป็น Source of Truth

ถ้า Schemaไม่ได้ตั้ง Character Name Unique:

Duplicate Namesอาจได้รับอนุญาต

188. Email/Discord Identifierใน OOC Table

อาจถูกตั้ง Uniqueเพื่อป้องกัน Accountซ้ำ

แต่ต้องดู Resource

189. Whitelist Duplicate

Playerอาจถูก Add Whitelistซ้ำ

ถ้า Identifier Unique:

Error

190. Seederควร Update Existingแทน Insertใหม่ในบางกรณี

เช่น Whitelist Statusของคนเดิม

191. Ban Table Duplicate

บาง Systemsอาจอนุญาตหลาย Ban Recordsต่อ Playerเพื่อ History

ดังนั้น Identifierไม่ควร Uniqueเสมอไป

192. ถ้า Developerตั้ง Uniqueผิด

ก็เป็น Schema Design Bugได้

แต่ต้องพิสูจน์จาก Resource Logic

193. อย่าเอา Constraintออกเพราะ “คิดว่า” Developerผิด

ตรวจ Documentation/Codeก่อน

194. Duplicate Entryอาจเกิดจาก Migrationสร้าง Unique Indexบน Dataที่มีซ้ำ

เช่นก่อนหน้า Tableอนุญาต Plateซ้ำ

Versionใหม่ Add:

UNIQUE plate

Migrationอาจ Failเพราะ Dataเก่ามี Plateซ้ำ

195. ต้อง Clean Dataก่อน Add Unique

นี่เป็น Migration Problem

196. Errorใน Caseนี้อาจไม่ใช่ INSERT

อาจเกิดตอน:

ALTER TABLE

เพิ่ม Unique Constraint

197. Errorข้อความยังบอก Duplicate Entryได้

เพราะ Existing Dataขัดกับ Constraintใหม่

198. วิธีแก้

หา Duplicate Values
ตัดสินว่า Rowไหนถูก
Remap/Removeอย่างปลอดภัย
ค่อยเพิ่ม Constraint

199. อย่าลบ Constraintใหม่เพราะ Migration Failทันที

ถ้า Constraintมีเหตุผลด้าน Data Integrity

200. Find Duplicate Valuesอย่างไรเชิงแนวคิด

ใช้:

SELECT column_name, COUNT(*)
FROM table_name
GROUP BY column_name
HAVING COUNT(*) > 1;

เปลี่ยน Table/Columnให้ตรงระบบจริง

201. Queryนี้ใช้ตรวจ

ไม่แก้ Data

จึงเหมาะกับ Diagnosis

202. Composite Duplicateก็ตรวจหลาย Columns

เช่น:

GROUP BY player_id, reward_id

ตาม Keyจริง

203. Data Cleanupต้องมี Business Decision

ถ้าพบ Plateซ้ำสองคัน:

รถไหนควรเปลี่ยน Plate?
รถไหนเป็น Legacy?
Ownershipถูกไหม?

ไม่ใช่ SQL Decisionอย่างเดียว

204. Staff/Ownerอาจต้องตรวจ Logs

เพื่อรู้ว่า Rowใดสร้างก่อน/หลัง

205. created_atมีประโยชน์

ถ้ามี Timestampถูกต้อง

ช่วยดู History

206. แต่ Oldestไม่ได้แปลว่าถูกเสมอ

อาจเป็น Rowเก่าที่ Bugสร้าง

ต้องดู Context

207. Duplicate Keyใน Character Dataอาจร้ายแรง

อย่าลบ Player Rowโดยไม่มี Backup

208. Duplicate Keyใน Seed Tableอาจง่ายกว่า

แต่ยังต้องดูว่า Resourceต้องการ Updateหรือ Replace

209. INSERT IGNOREกับ Seed Dataอาจเหมาะบางกรณี

ถ้า Developerตั้งใจว่า Existing Rowให้คงเดิม

แต่ต้องเป็น Designที่ชัดเจน ไม่ใช่ Patchสุ่ม

210. Upsertกับ Config Tableอาจเหมาะ

เช่น:

setting_name = unique

ถ้ามีแล้ว:

Update Value

211. REPLACEควรระวังมากที่สุด

เพราะ MariaDBระบุว่า Rowเดิมจะถูกลบก่อน Insert Rowใหม่เมื่อชน Unique/Primary Key

212. Foreign Keysอาจทำ REPLACEมี Side Effects

เพราะ Deleteสามารถกระทบ Relationsตาม Constraints

213. Application Hooksอาจต่าง

ถ้ามี Triggers/Logs

Delete+Insertไม่เท่ากับ Update

214. FiveM Server Ownerไม่ควรเปลี่ยน INSERTเป็นREPLACEทั้ง Resource

เพียงเพื่อหยุด Error

215. Error Handlingที่ดีควร Specific

ถ้า Duplicate Character ID:

Generateใหม่

ถ้า Duplicate Setting:

Update

ถ้า Duplicate Claim:

Rejectเป็น Already Claimed

216. Business Logicสำคัญกว่า Syntax

SQLมีหลายวิธีจัดการ Duplicate แต่ต้องเลือกให้ตรงความหมายข้อมูล

217. Duplicate Rewardควร Reject

ไม่ควร Upsertแล้วให้ Rewardซ้ำ

218. Duplicate Session Recordอาจ Update

ขึ้นอยู่กับ Session Design

219. Duplicate Player Preferencesอาจ Update

เหมาะกับ One-row-per-player settings

220. Duplicate Vehicleควรไม่ Updateรถเดิมด้วยข้อมูลรถใหม่

อันตราย

221. Duplicate Invoice Referenceควร Generate Referenceใหม่

มากกว่าจะ Update Invoiceเก่า

222. Duplicate Transaction Referenceก็เช่นกัน

อย่าเขียนทับ Transactionเดิม

223. Duplicate Phone Numberควร Generateใหม่

ถ้า Phone Numberต้อง Unique

224. Duplicate Character IDควร Generateใหม่

หากเกิด Collisionตอนสร้าง Character

225. Duplicate Business Internal IDอาจ Generateใหม่

แต่ Business Display Nameอาจยังเหมือนกันได้ถ้า Rulesอนุญาต

226. Duplicate Entryจาก Player Retryหลัง Timeout

สถานการณ์:

Requestแรกสำเร็จ
Clientไม่ได้รับ Response
Client Retry
Databaseตอบ Duplicate

227. นี่ไม่ได้หมายความว่า Requestแรกล้มเหลว

สำคัญมาก

228. Clientควรตรวจ Existing Result

แทนสร้างซ้ำ

229. Idempotency Keyช่วยได้ไหม

ในระบบ Transactionสมัยใหม่สามารถใช้ Unique Request IDป้องกัน Retryสร้างผลซ้ำ

FiveM Custom Resourceก็สามารถออกแบบแนวคิดนี้ได้

230. Database Unique Keyเหมาะเป็น Idempotency Guard

เช่น:

request_id

Unique

Retryเดิมจึงไม่สร้าง Paymentใหม่

231. Errorอาจถูก Handleเป็น Successของ Requestเดิม

แต่ต้องพิสูจน์ว่า Recordเดิมคือ Requestเดียวกันจริง

232. อย่า Treatทุก Duplicateเป็น Success

เพราะอาจชน Recordของคนอื่นจริง

233. Duplicate Errorต้องมี Context

Keyอะไร
Valueอะไร
Operationอะไร

234. Loggingควรบันทึก Context

เช่น:

Resource
Action
Character

โดยไม่เปิดเผยข้อมูลลับเกินจำเป็น

235. SQL Error Logช่วย Debug

แต่ Password/Connection Stringไม่ควร Log Public

236. Resource Error Stackช่วยหา Source

ค้น:

File
Line
Query

237. ถ้าเป็น Closed-source Resource

ใช้:

Official Support
Documentation
SQL Files

แทนการเดา

238. อย่า Patch Databaseรุนแรงเพื่อ Resourceเดียว

ถ้า Resourceมี Versionผิด

Update/Replace Resourceอาจเหมาะกว่า

239. Duplicate Entryหลัง Resource Update

ตรวจ:

Migration
New Unique Constraints
Seeder Changes

240. Duplicate Entryหลัง Framework Update

ตรวจ Compatibilityของ Resourcesที่เขียน Dataลง Core Tables

241. Duplicate Entryหลัง Database Restore

ตรวจว่ากำลัง Restoreทับ Databaseเดิมหรือเปล่า

242. Duplicate Entryหลัง Server Clone

ตรวจว่า Cloneทั้งสอง Serverกำลังใช้ Databaseเดียวกันหรือไม่

243. สอง FiveM Serversใช้ DBเดียวกันได้ไหม

ทาง Technicalอาจทำได้ในบาง Architecture

แต่ถ้า Resourcesไม่ได้ออกแบบ Multi-server:

ID Collisions
Shared State Problems

อาจเกิด

244. Server A กับ Server B Generate IDเหมือนกัน

ถ้าเขียน Tableเดียวกัน:

Duplicate Entry

เกิดได้

245. Multi-server Architectureต้องมี ID Strategy

เช่น Unique IDsที่ไม่ชนข้าม Instances

246. Server Ownerทั่วไปไม่ควร Share Core Databaseโดยไม่ได้ออกแบบ

โดยเฉพาะ:

Character
Vehicles
Transactions

247. AUTO_INCREMENTใน Multi-server Databaseเดียว

ถ้าทั้งสองใช้ Database Tableเดียวกันจริง Databaseสามารถจัด Counterกลางได้

แต่ถ้าแต่ละ Serverมี Local DBแล้ว Mergeภายหลัง IDsอาจชน

248. Mergeภายหลังยากกว่าการออกแบบตั้งแต่ต้น

ดังนั้นควรวาง Data Strategyก่อน

249. Error 1062ไม่ควรถูก Ignoreใน Production Logs

แม้ Gameplayดูปกติ

เพราะอาจบอก:

Retry Bug
Data Collision

250. Errorเกิดครั้งเดียวหลัง Import

อาจเป็น Migrationเฉพาะกิจ

แต่ต้องรู้ว่าอะไรถูกข้าม

251. Errorเกิดทุก Player Join

เป็น Bugถาวร

ต้องแก้ทันที

252. Errorเกิดทุก Restart

Startup Seed/Migrationอาจ Runซ้ำ

253. Errorเกิดทุกซื้อรถ

Plate/ID Generatorน่าสงสัย

254. Errorเกิดทุกสร้าง Character

Identifier Generator/Schemaน่าสงสัย

255. Errorเกิดบางครั้งเท่านั้น

อาจเป็น:

Random Collision
Race Condition
Retry

256. Random Collisionจะเกิดยากแค่ไหน

ขึ้นกับ Identifier Spaceและจำนวน Records

ไม่มีค่ากลาง

257. อย่าคิดว่า “สุ่ม 6หลักไม่มีทางซ้ำ”

ยังมีความเป็นไปได้

Databaseควรตรวจสุดท้าย

258. Collision Retryควรมีจำนวนจำกัด

ไม่ควร Loopไม่สิ้นสุด

259. หาก ID Spaceเต็ม

Generateใหม่ก็จะชนบ่อย

ต้องขยาย Design

260. Phone Number Poolเต็มได้ไหม

ถ้า Serverใช้ช่วงหมายเลขเล็กและ Playersมาก:

ได้

261. Plate Spaceก็มี Limitเชิง Combination

แม้โดยทั่วไปอาจใหญ่พอ

แต่ Custom Formatสั้นมากเพิ่มโอกาสชน

262. Unique Constraintช่วยบอกว่า Poolเริ่มมีปัญหา

ดู Collision Rate

263. Monitoring Duplicate Errorsมีประโยชน์

ถ้า Errorเพิ่มขึ้น:

Generatorอาจต้องปรับ

264. Error Rateเป็น Signal

ไม่จำเป็นต้องรอ Playerแจ้งก่อน

265. Database Metricsไม่ต้องซับซ้อนสำหรับ Serverเล็ก

อย่างน้อยอ่าน Console/Logsเป็นประจำ

266. Duplicate Errorกับ Exploit Attempt

ถ้า Playerส่ง Requestซ้ำจำนวนมาก:

อาจเป็น Abuse
หรือ UI Bug

อย่ารีบกล่าวหาโดยไม่มี Evidence

267. Rate Limitช่วยได้

ป้องกัน Requestซ้ำเร็วเกิน

แต่ไม่แทน Unique Constraint

268. Server-side Validationสำคัญ

อย่าเชื่อ Clientว่า IDนั้น Unique

Database/Serverควรตรวจ

269. Client-generated IDใช้ได้ไหม

ใช้ได้ในบาง Design แต่ต้องมี Collision Handling

270. Server-generated IDมักควบคุมง่ายกว่า

สำหรับบาง Entity

แต่ Architectureเป็นผู้กำหนด

271. Duplicate Entry Troubleshooting Flow

Error 1062
↓
Read duplicate value
↓
Read key name
↓
Identify table
↓
SHOW CREATE TABLE / SHOW INDEX
↓
SELECT existing row
↓
Find insert source
↓
Determine intended behavior
↓
Fix generator/retry/migration
↓
Test

272. Checklistก่อนแก้

Backup Database
Capture Errorเต็ม
รู้ Resource
รู้ Table
รู้ Key
รู้ Duplicate Value

273. Checklistถ้าเป็น Primary Key

AUTO_INCREMENTไหม
Resourceส่ง IDเองไหม
Import/Restoreซ้ำไหม
Multi-server Mergeไหม

274. Checklistถ้าเป็น Unique Plate

Plateมีอยู่จริงไหม
Generatorตรวจ Collisionไหม
Resourceถูกเรียกสองครั้งไหม

275. Checklistถ้าเป็น Phone Number

Number Generator
Existing Character
Migration
Duplicate Account Creation

276. Checklistถ้าเป็น Seed/Jobs

SQLเคย Importแล้วหรือยัง
Scriptควร Update existingหรือไม่

277. Checklistหลัง Migration

Unique Indexใหม่
Existing Duplicates
Partial Migration
Resource Version

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

ลบ Primary Key
ลบ Unique Index
DELETE Rowแบบสุ่ม
ใช้ REPLACEทุก Query
INSERT IGNOREทั้ง Resource
Reset Databaseทันที

279. ทำไมไม่ควรลบ Primary Key

Primary Keyมีหน้าที่หลักในการระบุ Rowและรักษาความเป็นเอกลักษณ์ของ Record

280. ทำไมไม่ควรลบ Unique Index

มันอาจเป็น Business Constraintสำคัญ เช่น:

Plateต้องไม่ซ้ำ
Phoneต้องไม่ซ้ำ

281. ทำไมไม่ควรใช้ INSERT IGNOREทุกจุด

MariaDBระบุว่า IGNORE สามารถเปลี่ยน Errorsเป็น Warnings และทำให้ Rowsที่เกิด Errorsถูกข้ามหรือค่าบางชนิดถูกปรับ ซึ่งอาจซ่อนต้นเหตุของข้อมูลผิดได้

282. ทำไมไม่ควรใช้ REPLACEทุกจุด

เพราะ REPLACEสามารถลบ Rowเดิมเมื่อ Unique Keyชนแล้ว Insert Rowใหม่ ซึ่งไม่เท่ากับ Updateธรรมดา

283. ทำไม Upsertก็ต้องระวัง

เพราะถ้า Collisionไม่ใช่ Entityเดียวกันจริง:

คุณอาจ Updateข้อมูลของคนอื่น

284. Fixที่ดีที่สุด

ขึ้นอยู่กับ Intent:

Entityใหม่แต่IDซ้ำ

Generate IDใหม่

RecordเดิมควรถูกUpdate

ใช้ Update/Upsertที่เหมาะ

RequestเดิมถูกRetry

ใช้ Idempotency

MigrationมีDataซ้ำ

Clean/Migrate Data

285. Data Integrityมาก่อน Consoleสวย

อย่าแก้เพียงให้ข้อความแดงหาย

286. FiveM Economyเสียได้จาก Duplicate Handlingผิด

เช่น:

รถถูกเขียนทับ
Paymentซ้ำ
Rewardซ้ำ

287. Character Dataก็เสียได้

ถ้า Upsert Rowผิด Character

288. Backupก่อนแก้ Production

โดยเฉพาะก่อน:

DELETE
UPDATE IDs
DROP INDEX
ALTER TABLE

289. SELECTเป็นขั้นแรกที่ปลอดภัยกว่า

ตรวจ Rowและ Indexก่อนเปลี่ยน Data

290. SHOW CREATE TABLEช่วยยืนยัน Schema

อย่าเดา Keyจากชื่อ Columnเพียงอย่างเดียว

291. Error 1062 FAQ

FiveM Duplicate Entry Error 1062 คืออะไร

MariaDBปฏิเสธค่าที่ซ้ำกับ Primary Keyหรือ Unique Keyที่มีอยู่แล้ว

`Duplicate entry '1' for key 'PRIMARY'` คืออะไร

ค่าของ Primary Key 1 มีอยู่แล้ว แต่ Queryพยายาม Insertอีก Rowด้วยค่าเดียวกัน

ต้องลบ Rowเก่าไหม

ไม่ควรทันที ต้องตรวจว่า Rowเก่าถูกต้องหรือเป็นข้อมูลเสีย

ต้องลบ Primary Keyไหม

ไม่แนะนำ เพราะจะทำลายข้อจำกัดสำคัญของ Table

ต้องลบ Unique Indexไหม

ไม่ควรเว้นแต่พิสูจน์แล้วว่า Schema Designผิดจริง

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

ตรวจ Vehicle Rowเดิมและแก้ Plate Generator/Collision Handling

Duplicate Phone Numberแก้อย่างไร

ตรวจ Number Generatorและ Existing Characterก่อนแก้ข้อมูล

Duplicate Character IDแก้อย่างไร

ต้องแก้ ID Generatorหรือ Migration ไม่ควรเขียนทับ Characterเดิม

AUTO_INCREMENTเกี่ยวไหม

เกี่ยวได้ หาก Applicationกำหนด IDเองหรือ Sequence/ข้อมูลหลัง Importไม่สอดคล้องกัน; MariaDBอนุญาตการกำหนดค่า AUTO_INCREMENTโดยตรง แต่ค่าที่เป็น Primary/Uniqueต้องไม่ซ้ำ

`INSERT IGNORE` แก้ได้ไหม

อาจข้าม Duplicate Errorได้ในบางกรณี แต่ไม่ควรใช้เป็น Fixทั่วไป เพราะอาจซ่อนปัญหา Data/Logic

`ON DUPLICATE KEY UPDATE` ใช้ได้ไหม

ได้เมื่อ Logicต้องการ Update Recordเดิมจริง ๆ เมื่อ Unique/Primary Keyชน

`REPLACE` ใช้ได้ไหม

มีได้ แต่ต้องระวังเพราะ Rowเดิมอาจถูก Deleteแล้ว Insertใหม่

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

ตรวจว่า Importข้อมูลเดิมซ้ำหรือกำลัง Run Seed/Migrationซ้ำ

Errorเกิดหลัง Restore Backup

ตรวจว่า Restoreทับ Databaseที่มีข้อมูลเดิมหรือไม่

Errorเกิดหลัง Update Resource

ตรวจ Migrationและ Unique Constraintsใหม่

Errorเกิดเฉพาะบางครั้ง

อาจเป็น Random Collision, Concurrent Requestsหรือ Retry

Errorทุก Restart

ตรวจ Startup Seeder/Installerที่ Insertค่าเดิมซ้ำ

Errorทุกครั้งที่ซื้อรถ

ตรวจ Vehicle IDหรือ Plate Generator

Errorทุกครั้งที่สร้าง Character

ตรวจ Character Identifier Generatorและ Account Mapping

Errorทุกครั้งที่ Claim Reward

Unique Constraintอาจกำลังป้องกันการ Claimซ้ำ หรือ Resourceอาจสร้าง Claim Recordซ้ำผิด Logic

Clear FiveM Cacheช่วยไหม

โดยทั่วไปไม่ใช่ Fixของ Database Duplicate Entry

Restart MariaDBช่วยไหม

ไม่ ถ้า Queryยัง Insertค่าซ้ำเดิม Errorจะกลับมา

Reinstall Databaseช่วยไหม

ไม่ควรทำ และเสี่ยง Data Lossโดยไม่แก้ Root Cause

สรุป FiveM MySQL Duplicate Entry Error 1062

FiveM MySQL/MariaDB Duplicate Entry Error 1062 เกิดเมื่อ Resource พยายาม Insert ค่าที่ชนกับ PRIMARY KEY หรือ UNIQUE key ที่มีอยู่แล้ว โดย MariaDB กำหนด Error นี้เป็น ER_DUP_ENTRY และ SQLSTATE 23000

สาเหตุที่พบบ่อยคือ:

Resource Insertซ้ำ → Playerกด Actionซ้ำ → Retry Logicผิด → ID/Plate/Phone Generatorชน → Import SQLซ้ำ → Restoreทับข้อมูลเดิม → Migrationเพิ่ม Unique Constraintบนข้อมูลที่มี Duplicateอยู่แล้ว

สิ่งที่ comsiam แนะนำคือเมื่อพบ Error 1062 อย่าเริ่มจากการลบ PRIMARY KEY หรือ UNIQUE INDEX เพราะ Constraintเหล่านี้อาจกำลังช่วยป้องกัน Character, Vehicle, Transaction หรือ Reward ซ้ำอยู่ ให้ตรวจ Duplicate Value, Key Name, Existing Row และ Queryต้นทางก่อน แล้วแก้ Logicให้ตรงกับความหมายของข้อมูลจริง

อีกหลักที่ comsiam แนะนำคืออย่าใช้ INSERT IGNORE, REPLACE หรือ ON DUPLICATE KEY UPDATE เป็นยาครอบจักรวาล แม้ MariaDBจะมีเครื่องมือเหล่านี้สำหรับจัดการ Duplicate แต่แต่ละคำสั่งมี Behaviorต่างกันอย่างมาก: IGNORE สามารถข้าม Error, ON DUPLICATE KEY UPDATE เปลี่ยนไป Update Recordเดิม และ REPLACE อาจลบ Rowเดิมแล้ว Insertใหม่ ดังนั้นต้องเลือกตาม Business Logicของ Resource ไม่ใช่เลือกเพียงเพราะทำให้ Consoleหยุดขึ้น Error