Chỉ mục tra cứu sẽ nhanh hơn đáng kể với char vs varchar khi tất cả các giá trị là 36 ký tự

Tôi có một lược đồ kế thừa (từ chối trách nhiệm!) Sử dụng id được tạo dựa trên hàm băm cho khóa chính cho tất cả các bảng (có rất nhiều). Một ví dụ về id như vậy là:

922475bb-ad93-43ee-9487-d2671b886479

Không có hy vọng có thể thay đổi cách tiếp cận này, tuy nhiên hiệu suất với truy cập chỉ mục là kém. Đặt ra vô số lý do có thể xảy ra, có một điều tôi nhận thấy rằng dường như ít hơn tối ưu - mặc dù tất cả các giá trị id trong tất cả các bảng có độ dài chính xác 36 ký tự, nhưng kiểu cột varchar(36)thì không char(36) .

Việc thay đổi các loại cột thành độ dài cố định char(36)sẽ cung cấp bất kỳ lợi ích hiệu suất chỉ mục đáng kể nào , ngoài việc tăng rất ít số lượng mục trên mỗi trang chỉ mục, v.v.?

Tức là postgres thực hiện nhanh hơn nhiều khi xử lý các loại có độ dài cố định so với các loại có độ dài thay đổi?

Vui lòng không đề cập đến việc tiết kiệm lưu trữ cực nhỏ - điều đó sẽ không thành vấn đề so với phẫu thuật cần thiết để thực hiện thay đổi cho các cột.

Không . Không có lợi ích gì cả . Hướng dẫn nêu rõ :

Mẹo: Không có sự khác biệt về hiệu suất giữa ba loại này , ngoài không gian lưu trữ tăng lên khi sử dụng loại đệm trống và một vài chu kỳ CPU bổ sung để kiểm tra độ dài khi lưu trữ vào cột bị giới hạn độ dài. Mặc dù character(n)có lợi thế về hiệu năng trong một số hệ thống cơ sở dữ liệu khác, nhưng PostgreSQL không có lợi thế như vậy; trong thực tế character(n)thường là chậm nhất trong ba vì chi phí lưu trữ bổ sung của nó. Trong hầu hết các tình huống text hoặc character varyingnên được sử dụng thay thế .

Nhấn mạnh đậm của tôi.

char(n)là một loại phần lớn lỗi thời, vô dụng. Gắn bó với varchar(n). Nếu bạn không cần phải thực thi độ dài, varcharhoặc textsẽ nhanh hơn một chút. Bạn sẽ không thể đo lường sự khác biệt.

Ngoài ra, nếu tất cả các chuỗi có độ dài chính xác 36 ký tự, thì không có cách lưu trữ nào cả, thậm chí không phải là một chuỗi rất nhỏ. Cả hai đều có cùng kích thước trên đĩa và trong RAM. Bạn có thể kiểm tra với pg_column_size()(trên một biểu thức và trên cột bảng).

Liên quan:

• Bất kỳ nhược điểm nào của việc sử dụng kiểu dữ liệu văn bản trên máy tính để lưu trữ chuỗi?

Bạn đã không yêu cầu các tùy chọn khác , nhưng tôi sẽ đề cập đến hai:

1. COLLATION- trừ khi bạn đang chạy DB của mình với đối chiếu "C" . Đối chiếu thường bị bỏ qua và có thể đắt tiền. Vì các chuỗi của bạn dường như không có ý nghĩa trong ngôn ngữ tự nhiên, có lẽ không có điểm nào trong các COLLATIONquy tắc sau . Liên quan:

   • Làm thế nào để tôi có hiệu quả "hàng tương ứng gần đây nhất"?
   • EXECUTE trong chức năng không sử dụng chỉ mục?

   So sánh điểm chuẩn mở rộng (trong số khác) ảnh hưởng của COLLATE "C"hiệu suất:

   • Thứ tự truy vấn chậm theo một cột trong bảng đã tham gia

2. UUID , rõ ràng. Chuỗi của bạn trông đáng ngờ giống như một UUID (32 chữ số hex cộng với 4 dấu phân cách). Sẽ hiệu quả hơn nhiều nếu lưu trữ chúng dưới dạnguuiddữ liệuthực tế, nhanh hơn theo nhiều cách và chỉ chiếm 16 byte - trái ngược với 37 byte trong RAM cho mộtchar(36)hoặcvarchar(36)(được lưu trữ mà không có dấu phân cách, chỉ là 32 định nghĩa char) hoặc 33 byte trên đĩa. Nhưng phần đệm căn chỉnh sẽ dẫn đến 40 byte trong cả hai trường hợp.) CũngCOLLATIONkhông liên quan đếnuuidkiểu dữ liệu.

   SELECT '922475bb-ad93-43ee-9487-d2671b886479'::uuid

   Điều này có thể hữu ích (chương cuối):

   • Chuyển đổi hex trong biểu diễn văn bản thành số thập phân

   Xem thêm:

   • Chi phí cho varchar (n) là gì?
   • Kiểu dữ liệu tối ưu cho trường MD5 là gì?