Tôi đã gặp phải vấn đề này rất chính trong cuộc sống nghề nghiệp của mình. Chúng tôi đã sử dụng dấu thời gian + số ngẫu nhiên và gặp phải sự cố nghiêm trọng khi ứng dụng của chúng tôi mở rộng quy mô (nhiều máy khách hơn, nhiều máy chủ hơn, nhiều yêu cầu hơn). Đúng là chúng tôi (thật ngu ngốc) chỉ sử dụng 4 chữ số và sau đó thay đổi thành 6, nhưng bạn sẽ ngạc nhiên về tần suất lỗi vẫn xảy ra.
Trong một khoảng thời gian đủ dài, bạn được đảm bảo để nhận được các lỗi chính trùng lặp. Ứng dụng của chúng tôi là nhiệm vụ quan trọng, và do đó, ngay cả cơ hội nhỏ nhất mà nó có thể không xảy ra do hành vi ngẫu nhiên vốn có là không thể chấp nhận được. Chúng tôi đã bắt đầu sử dụng UUID để tránh vấn đề này và quản lý cẩn thận việc tạo ra chúng.
Sử dụng UUID, kích thước chỉ mục của bạn sẽ tăng lên và chỉ mục lớn hơn sẽ dẫn đến hiệu suất kém hơn (có lẽ không đáng chú ý, nhưng kém hơn không kém). Tuy nhiên, MySQL hỗ trợ một loại UUID gốc (không bao giờ sử dụng varchar làm khóa chính !!) và có thể xử lý lập chỉ mục, tìm kiếm, v.v. khá hiệu quả ngay cả so với bigint. Hiệu suất lớn nhất ảnh hưởng đến chỉ mục của bạn hầu như luôn luôn là số hàng được lập chỉ mục, thay vì kích thước của mục được lập chỉ mục (trừ khi bạn muốn lập chỉ mục trên văn bản dài hoặc thứ gì đó vô lý như vậy).
Để trả lời câu hỏi của bạn:Bigint (với các số ngẫu nhiên đính kèm) sẽ ổn nếu bạn không có kế hoạch mở rộng ứng dụng / dịch vụ của mình một cách đáng kể. Nếu mã của bạn có thể xử lý thay đổi mà không cần thay đổi nhiều và ứng dụng của bạn sẽ không phát nổ nếu xảy ra lỗi khóa trùng lặp, hãy tiếp tục. Nếu không, hãy cắn và chọn tùy chọn quan trọng hơn.
Bạn luôn có thể triển khai một thay đổi lớn hơn sau này, chẳng hạn như chuyển sang một chương trình phụ trợ hoàn toàn khác (mà chúng ta hiện đang phải đối mặt ...:P)
