Hiệu suất MySQL của trường varchar duy nhất vs bigint duy nhất

Question

Tôi đang làm việc trên một ứng dụng sẽ triển khai giá trị hex dưới dạng khóa doanh nghiệp (ngoài trường tăng tự động làm khóa chính) tương tự với id URL được thấy trong Gmail . Tôi sẽ thêm một ràng buộc duy nhất cho cột và ban đầu nghĩ đến việc lưu trữ giá trị như một bigint để thoát khỏi việc tìm kiếm một trường varchar nhưng đã tự hỏi nếu điều đó là cần thiết nếu trường là duy nhất.

Kết nối nội bộ sẽ được thực hiện bằng trường tăng tự động và giá trị hex sẽ được sử dụng trong mệnh đề where để lọc.

Loại sắp xếp hiệu suất nào sẽ lưu trữ giá trị dưới dạng varchar (x) hoặc có thể là char (x) trên công việc bổ sung khi thực hiện chuyển đổi đến và từ hex để lưu trữ giá trị dưới dạng số nguyên trong cơ sở dữ liệu? Nó có đáng giá thêm phức tạp?

Tôi đã thực hiện kiểm tra nhanh trên một số hàng nhỏ (50k) và có thời gian kết quả tìm kiếm tương tự. Nếu có một vấn đề hiệu suất lớn, nó sẽ là tuyến tính, hoặc theo cấp số mũ?

Tôi đang sử dụng InnoDB làm công cụ.

Answer 1

Giá trị hex của bạn có phải là GUID không? Mặc dù tôi đã từng lo lắng về hiệu suất của các mục dài như chỉ mục, tôi đã thấy rằng trên cơ sở dữ liệu hiện đại, sự khác biệt về hiệu suất trên hàng triệu bản ghi là không đáng kể.

Một vấn đề tiềm ẩn lớn hơn là bộ nhớ mà chỉ mục tiêu thụ (ví dụ 16 byte so với 4 byte int), nhưng trên máy chủ mà tôi kiểm soát tôi có thể phân bổ cho điều đó. Miễn là chỉ mục có thể ở trong bộ nhớ, tôi thấy rằng có nhiều chi phí hơn từ các hoạt động khác mà kích thước của phần tử chỉ mục không tạo ra sự khác biệt đáng chú ý. Ngược lại, nếu bạn sử dụng GUID, bạn sẽ giành được độc lập máy chủ cho các bản ghi được tạo và linh hoạt hơn trong việc hợp nhất dữ liệu trên nhiều máy chủ (đó là điều tôi quan tâm, vì hệ thống của chúng tôi tổng hợp dữ liệu từ các hệ thống con).

Có một đồ thị về bài viết này mà dường như để sao lưu nghi ngờ của tôi: Myths, GUID vs Autoincrement

Answer 2

Giá trị hex được tạo ra từ một UUID (thực hiện của Java); nó được băm và cắt ngắn thành độ dài nhỏ hơn (có thể là 16 ký tự). Thuật toán vẫn đang được thảo luận (hiện tại là SHA). Một lợi thế mà tôi thấy khi lưu trữ giá trị trong hex vs integer là nếu chúng ta cần tăng kích thước (mà tôi không thấy xảy ra với ứng dụng này ở 16 char), chúng ta có thể tăng độ dài cắt ngắn và để lại các giá trị cũ mà không sợ va chạm. Chuyển đổi thành các giá trị số nguyên sẽ không hoạt động tốt như vậy.

Lý do cắt ngắn và đơn giản bằng cách sử dụng GUID/UUID đơn giản là làm cho URL và API (là nơi chúng sẽ được sử dụng) thân thiện hơn.

Answer 3

Mọi thứ khác bằng nhau, giữ cho dữ liệu nhỏ hơn sẽ làm cho dữ liệu chạy nhanh hơn. Chủ yếu là vì nó sẽ mất ít không gian, vì vậy ít đĩa i/o, ít bộ nhớ cần thiết để giữ chỉ mục, vv ... 50k hàng là không đủ để nhận thấy rằng mặc dù ...