Loại cột UUID hiệu quả nhất là gì

Để lưu trữ UUID 128 bit, có nhiều tùy chọn lưu trữ:

1. một cột [16]
2. hai cột bigint / dài (64 bit)
3. một cột CHAR (36) - 32 chữ số hex + 4 dấu gạch ngang.
4. một cột cụ thể của cơ sở dữ liệu UUID, nếu db hỗ trợ nó

Từ quan điểm lập chỉ mục nào trong số đó là hiệu quả nhất? Nếu db không hỗ trợ loại uuid chuyên dụng thì 1, 2, 3 là ứng cử viên tốt nhất?

Một uuidloại dành riêng là đặt cược tốt nhất của bạn cho PostgreSQL. Khó có thể nói với các DB khác - không ai có thể bắt chước một uuidloại được lưu trữ kém hiệu quả hơn một loại byte đơn giản.

Một lần nữa trong PostgreSQL, byteasẽ là một cách hợp lý để lưu trữ UUID nếu bạn không có uuidloại này. Đối với các DB khác, nó phụ thuộc vào cách họ lưu trữ dữ liệu nhị phân.

Nếu có thể tôi sẽ tránh sử dụng hex-with-dash. Đó là cách kém hiệu quả để so sánh, sắp xếp và lưu trữ.

Vì vậy, thực sự, "không (2) hoặc (3)". Không bao giờ. Sử dụng (4) khi được hỗ trợ, (1) nếu không.

Theo thứ tự ưu tiên: 4,1,2,3 Không sử dụng UUID làm khóa phân cụm nếu sử dụng máy chủ SQL, không chỉ phân mảnh xấu, khóa phân cụm được sử dụng trong tất cả các chỉ mục không được phân cụm và bạn sẽ thêm các byte đó vào mỗi hàng chỉ số. Sự phân mảnh có thể được giảm thiểu bằng cách sử dụng NEWSEQUENTIALID nhưng thường thích nhận dạng bingint cho Khóa cụm của bạn hơn GUID để ngăn chặn sự phình to trong các chỉ mục khác.

Sự khác biệt giữa việc chọn 1 trên 2 sẽ phụ thuộc vào mức độ hiệu quả của cơ sở dữ liệu xử lý hai cột kiểu cơ bản trên một mảng cố định một cột. Nó phải đủ dễ dàng để kiểm tra với dữ liệu giả. Nhìn vào tốc độ truy vấn của bạn cũng như kích thước của các chỉ mục và dữ liệu. Nhỏ + nhanh là tốt nhất!

Người ta sẽ phải giả sử rằng bất kỳ loại dữ liệu được hỗ trợ hữu cơ nào sẽ được tối ưu hóa tốt hơn trong sản phẩm so với bất kỳ thứ gì có thể được đặt cùng nhau với tư cách là khách hàng của sản phẩm đó. Sau đó, bất cứ thứ gì có số byte nhỏ nhất để bạn có được các hàng tối đa trên mỗi trang.