สร้าง UUID (v4 สุ่ม v7 เรียงตามเวลา)

เมื่อใดควรใช้ v4 เทียบกับ v7

UUID v4 เป็นสุ่มล้วน — 122 bits สุ่มที่มี 2 bits เวอร์ชัน/ตัวแปร ให้ค่าที่เป็นไปได้ประมาณ 5.3 × 10³⁶ ค่า สองค่ารับประกันโดยพื้นฐานที่จะไม่ชนกันเลย ใช้ v4 ที่ใดก็ตามที่คุณไม่ต้องการการจัดเรียง เช่น ID คำขอ API หรือตัวระบุผู้ใช้ที่ไม่ระบุตัวตน

UUID v7 (RFC 9562 เผยแพร่ในปี 2024) เริ่มต้นด้วย timestamp Unix 48-bit มิลลิวินาที ตามด้วย 74 bits สุ่ม พวกมันเรียงลำดับตามคำศัพท์ในลำดับการสร้าง ซึ่งใหญ่สำหรับประสิทธิภาพฐานข้อมูล — คีย์หลักที่เรียงตามเวลาหมายความว่าการแทรกจะไปที่ปลายสุดของ B-tree เสมอ ไม่มีการแบ่งหน้าแบบสุ่ม ใช้ v7 สำหรับคีย์หลักฐานข้อมูลใหม่

เครื่องสร้างนี้ทำงานอย่างไร

ทั้ง v4 และ v7 ใช้ crypto.getRandomValues — แหล่งที่มาสุ่มที่ปลอดภัยของเบราว์เซอร์ พื้นฐานเดียวกับที่ HTTPS และตัวจัดการรหัสผ่านใช้ v4 เติม 122 bits สุ่ม v7 แยก 48 bits ของ timestamp + 74 bits สุ่มบวกเครื่องหมายเวอร์ชัน/ตัวแปรตาม RFC

การสร้างเกิดขึ้นในเบราว์เซอร์ของคุณ UUIDs ไม่ถูกเก็บหรือส่ง หากคุณสร้าง 100 v4 UUIDs โอกาสของการชนกันระหว่างพวกมันเล็กทางดาราศาสตร์ — ต่ำกว่าโอกาสของรังสีคอสมิกพลิก bits ใน CPU ของคุณมาก

ข้อผิดพลาด UUID ทั่วไป

UUIDs v4 เป็นคีย์หลักฐานข้อมูลทำร้ายประสิทธิภาพเมื่อเทียบกับจำนวนเต็มที่เพิ่มอัตโนมัติเพราะค่าสุ่มทำให้เกิดการแบ่งหน้า B-tree ระหว่างการแทรก v7 แก้ไขสิ่งนี้ — ใช้ v7 หากคุณต้องการประโยชน์ของ UUID โดยไม่มีความเจ็บปวดของดัชนี

อย่าเปิดเผย UUIDs ให้ผู้ใช้ที่ความสามารถในการเดามีความสำคัญ UUIDs v4 มี 122 bits entropy และเดาไม่ได้ UUIDs v7 รั่วเวลาสร้าง ซึ่งดีสำหรับการใช้งานส่วนใหญ่แต่ไม่ดีหากเวลาสร้างมีความละเอียดอ่อน

UUIDs เป็น 36 อักขระรวมเครื่องหมายขีดกลาง (32 hex + 4 เครื่องหมายขีดกลาง) พวกมันใช้ 16 bytes ไบนารีหรือ 36 bytes ข้อความ สำหรับคอลัมน์ cardinality สูงมาก พิจารณาเก็บเป็น BLOB ไบนารี / ประเภท UUID แบบเนทีฟแทน VARCHAR(36)