مولّد UUID v7

لسنوات، اضطرت فرق الهندسة التي أرادت مقاومة تصادم UUID لكن الترتيب الصديق للفهرس لعدد صحيح متسلسل لبناء هجينها الخاص غير القياسي — عادةً بإضافة طابع زمني مُنشأ يدويًا قبل UUID عشوائي، نهج استُخدِم بأشكال مختلفة بواسطة شركات أنظمة موزَّعة معروفة عديدة قبل وجود أي معيار رسمي لذلك. أضفى RFC 9562 الطابع الرسمي على ذلك النمط في إصدار رسمي من UUID تحديدًا حتى تستطيع التطبيقات عبر لغات وقواعد بيانات مختلفة إنتاج والتعرف على نفس البنية المُرتَّبة زمنيًا دون أن يُعيد كل فريق ابتكار متغير مختلف قليلًا وغير متوافق من نفس الفكرة بشكل مستقل.

تُرمِّز الـ48 بتًا الأولى من UUID v7 طابعًا زمنيًا لـUnix بالميلي ثانية، وهذا ما يمنح القيمة ترتيب فرزها — مقارنة UUID v7 اثنين كسلسلتين عاديتين تعكس بشكل صحيح أيهما أُنشئ أولًا، بما أن جزء الطابع الزمني يهيمن على المقارنة. تبقى البتات المتبقية مملوءة ببيانات عشوائية تشفيريًا، بالضبط كما في v4، لذا القيمة مقاومة للتخمين بقدر ما سيكون UUID عشوائي تمامًا؛ يتغير فقط سلوك ترتيبها، لا عدم قابليتها للتنبؤ.

إلى جانب سرعة الإدراج الخام، لمفتاح أساسي مُرتَّب زمنيًا فائدة عملية ثانية تهم يوميًا: تعود الصفوف طبيعيًا بترتيب الإنشاء من استعلام بسيط `ORDER BY id`، دون حاجة لعمود `created_at` منفصل وفهرس إضافي عليه فقط لترتيب السجلات زمنيًا. لجدول يُستعلَم عنه بكثرة بـ"الأحدث أولًا" — سجل نشاط، قائمة انتظار، أثر تدقيق — يمنح مفتاح أساسي v7 ذلك الترتيب مجانًا كتأثير جانبي للمعرِّف نفسه، بدلًا من تكلفة منفصلة يجب الحفاظ عليها.