UUID v1 เทียบกับ v4 เทียบกับ v5: ควรเลือกเวอร์ชันใด?
ตอบด่วน
ใช้ UUID v4 (random) เป็น default —ไม่ต้องประสานงาน และความเสี่ยง collision น้อย ใช้ v1 (time-based) เมื่อต้อง ID ที่เรียงตามเวลา ใช้ v5 (namespace+name) สำหรับ ID deterministic สร้างเวอร์ชันใดๆ ด้วย UUID Generator ฟรีของเรา
การแนะนำ
UUID (Universally Unique Identifier) คือ identifier 128-bit แสดงเป็น 36 อักขระในกลุ่ม hex 8-4-4-4-12 เช่น 123e4567-e89b-12d3-a456-426614174000 RFC 9562 กำหนดหลายเวอร์ชัน; สามที่พบบ่อยคือ v1 (time + MAC), v4 (random) และ v5 (namespace + name, SHA-1) แต่ละเวอร์ชัน trade-off ต่างกัน
ทีละขั้นตอน
-
UUID v1 —ตามเวลาและโหนด
v1 เข้ารหัสการประทับเวลา 60 บิตปัจจุบัน (ช่วงเวลา 100-ns ตั้งแต่ปี 1582-10-15) และ ID โหนด 48 บิต (โดยปกติจะเป็นที่อยู่ MAC) รหัสที่สร้างบนโหนดเดียวกันจะเพิ่มขึ้นแบบซ้ำซากจำเจและสามารถจัดเรียงเวลาได้ ความเสี่ยง: ที่อยู่ MAC ทำให้ข้อมูลระบุตัวตนของฮาร์ดแวร์รั่วไหล และการเอียงของสัญญาณนาฬิกาข้ามโหนดอาจทำให้ลำดับเสียหายได้
-
UUID v4 —สุ่ม
v4 ใช้ 122 บิตสุ่ม (6 บิตได้รับการแก้ไขสำหรับเวอร์ชัน/ตัวแปร) ด้วยบิตสุ่ม 122 บิต ความน่าจะเป็นของการชนกันระหว่าง 2.71 ล้านล้าน ID คือ 50% สำหรับปริมาณงานที่สมจริง โอกาสจะเป็นศูนย์ v4 ไม่ต้องการการประสานงานและไม่เปิดเผยข้อมูลโฮสต์ ทำให้เป็นค่าเริ่มต้นที่ปลอดภัยที่สุด
-
UUID v5 —เนมสเปซและชื่อ (SHA-1)
v5 แฮชเนมสเปซ UUID และสตริงชื่อที่มี SHA-1 เพื่อสร้าง ID 128 บิตที่กำหนดขึ้น คู่เดียวกัน (เนมสเปซ ชื่อ) จะให้ผล UUID เดียวกันเสมอ ซึ่งเหมาะสำหรับการขจัดข้อมูลซ้ำซ้อนและ ID ที่เสถียรที่ได้มาจากคีย์ธรรมชาติ v3 เป็นแนวคิดเดียวกัน แต่ใช้ MD5 (หลีกเลี่ยง)
-
เปรียบเทียบข้อแลกเปลี่ยน
v1 สามารถจัดเรียงได้ แต่ MAC รั่วไหลและจำเป็นต้องซิงค์นาฬิกา v4 เป็นการสุ่มและเป็นส่วนตัว แต่ไม่สามารถเรียงลำดับได้ v5 นั้นถูกกำหนดไว้และขจัดข้อมูลที่ซ้ำกันออกไป แต่จะไม่สุ่ม — การเดาชื่อจะช่วยให้ผู้โจมตีสร้าง UUID ได้ เลือกโดยพิจารณาว่าคุณต้องการลำดับ การสุ่ม หรือระดับที่กำหนด
-
เลือกเวอร์ชันที่เหมาะสมสำหรับกรณีของคุณ
คีย์หลักของฐานข้อมูล: v4 (หรือ v7 ในระบบที่ใหม่กว่าสำหรับความสามารถในการเรียงลำดับเวลา) ระบบแบบกระจายที่ไม่มีการประสานงาน: v4. รหัสกำหนดจากคีย์ธรรมชาติ (เช่น URL →UUID): v5. บันทึกการตรวจสอบที่ได้รับประโยชน์จากลำดับเวลา: v1 พร้อมด้วย ID โหนดแบบสุ่มที่ปลอดภัย
ตัวอย่าง
UUID v1 (ตามเวลา, จัดเรียงได้)
ป้อนข้อมูล: สร้างเมื่อ 2026-08-28T12:00:00Z บนโหนด 00:11:22:33:44:55
เอาท์พุต: 1ef7c1d0-2d3b-11f0-8000-001122334455 (หมายเลขเวอร์ชัน '1' เรียงลำดับเวลาได้)
UUID v4 (สุ่ม)
ป้อนข้อมูล: Random generation
เอาท์พุต: f47ac10b-58cc-4372-a567-0e02b2c3d479 (ตัวเลขเวอร์ชัน '4' บิตสุ่ม)
UUID v5 (กำหนดจากเนมสเปซ+ชื่อ)
ป้อนข้อมูล: เนมสเปซ DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8) + ชื่อ 'freeonlinetoolsgo.com'
เอาท์พุต: 74738ff5-5367-5958-9aeb-0c1f1f1f1f1f (อินพุตเดียวกันจะให้เอาต์พุตเดียวกันเสมอ)
ปัญหาทั่วไป
- การจัดเก็บ UUID เป็น VARCHAR(36) แทนที่จะเป็นประเภท BINARY/UUID ขนาด 16 ไบต์: ทำให้สิ้นเปลืองพื้นที่จัดเก็บ 2 เท่าและทำให้ประสิทธิภาพของดัชนีลดลง ใช้ประเภทคอลัมน์ UUID ดั้งเดิม หากมี
- การใช้ v1 โดยไม่รักษาความปลอดภัย ID โหนด: ที่อยู่ MAC เริ่มต้นจะทำให้ข้อมูลระบุตัวตนของฮาร์ดแวร์รั่วไหลและเป็นข้อกังวลด้านความเป็นส่วนตัว แทนที่ด้วยค่า 48 บิตแบบสุ่มแบบเข้ารหัสต่อโหนด
- สมมติว่าการชนกันของ v4 เป็นไปไม่ได้ แต่ไม่ได้เป็นเช่นนั้น เพียงแต่ไม่น่าจะเป็นไปได้ในทางดาราศาสตร์เท่านั้น ด้วย 122 บิตสุ่ม คุณต้องมี ~2.71 ล้านล้าน ID เพื่อโอกาส 50% สำหรับ 1 พันล้าน ID โอกาสคือ ~0.0000000000000001
- การใช้ v3 (อิงจาก MD5) แทน v5 (อิงจาก SHA-1): MD5 ใช้งานไม่ได้ ดังนั้นจึงควรใช้ v5 ทั้งสองมีการกำหนดไว้ แต่ v5 มีความต้านทานการชนที่ดีกว่า
เคล็ดลับ
- ค่าเริ่มต้นเป็น v4 สำหรับกรณีการใช้งานเกือบทุกกรณี — เป็นแบบสุ่ม เป็นส่วนตัว และปลอดภัยต่อการชนกันโดยไม่มีการประสานงานใดๆ
- หากคุณต้องการ ID สุ่มที่เรียงลำดับเวลาได้ ให้ดูที่ UUID v7 (RFC 9562, 2024) ซึ่งรวมการประทับเวลา Unix เข้ากับบิตสุ่ม ดีกว่า v1 สำหรับฐานข้อมูลสมัยใหม่
- ใช้ v5 เพื่อสร้าง ID ที่เสถียรจากคีย์ธรรมชาติ (URLs ที่อยู่อีเมล) ดังนั้นอินพุตเดียวกันจะจับคู่กับ UUID เดียวกันเสมอ ซึ่งมีประโยชน์สำหรับการขจัดความซ้ำซ้อนและ idempotent APIs
- สร้าง UUID บนไคลเอนต์เมื่อเป็นไปได้เพื่อหลีกเลี่ยงการเดินทางไปกลับไปยังเซิร์ฟเวอร์ —ตัวสร้าง UUID ของเราทำงานทั้งหมดในเบราว์เซอร์ของคุณโดยใช้ crypto.getRandomValues()