Có sự khác biệt hiệu năng THỰC SỰ giữa các khóa chính INT và VARCHAR không?

Có sự khác biệt hiệu suất có thể đo được giữa việc sử dụng INT so với VARCHAR làm khóa chính trong MySQL không? Tôi muốn sử dụng VARCHAR làm khóa chính cho danh sách tham chiếu (nghĩ rằng Hoa Kỳ, Mã quốc gia) và đồng nghiệp sẽ không nhúc nhích trên INT AUTO_INCREMENT làm khóa chính cho tất cả các bảng.

Lập luận của tôi, như chi tiết ở đây , là sự khác biệt về hiệu năng giữa INT và VARCHAR là không đáng kể, vì mỗi tham chiếu khóa ngoại INT sẽ yêu cầu THAM GIA để hiểu ý nghĩa của tham chiếu, khóa VARCHAR sẽ trực tiếp trình bày thông tin.

Vì vậy, có ai có kinh nghiệm với trường hợp sử dụng cụ thể này và các mối quan tâm về hiệu suất liên quan đến nó không?

Bạn nêu rõ rằng bạn có thể tránh được một số truy vấn đã tham gia bằng cách sử dụng khóa được gọi là khóa tự nhiên thay vì khóa thay thế . Chỉ bạn mới có thể đánh giá xem lợi ích của việc này có ý nghĩa trong ứng dụng của bạn hay không.

Đó là, bạn có thể đo các truy vấn trong ứng dụng quan trọng nhất để được nhanh chóng, bởi vì chúng hoạt động với khối lượng dữ liệu lớn hoặc chúng được thực hiện rất thường xuyên. Nếu các truy vấn này có lợi từ việc loại bỏ một phép nối và không bị ảnh hưởng bởi việc sử dụng khóa chính varchar, thì hãy thực hiện nó.

Không sử dụng một trong hai chiến lược cho tất cả các bảng trong cơ sở dữ liệu của bạn. Có thể trong một số trường hợp, khóa tự nhiên sẽ tốt hơn, nhưng trong những trường hợp khác, khóa thay thế sẽ tốt hơn.

Những người khác đưa ra một điểm tốt là trong thực tế, rất hiếm khi một khóa tự nhiên không bao giờ thay đổi hoặc có các bản sao, vì vậy các khóa thay thế thường đáng giá.

Đó không phải là về hiệu suất. Đó là về những gì làm cho một khóa chính tốt. Độc đáo và không thay đổi theo thời gian. Bạn có thể nghĩ rằng một thực thể như mã quốc gia không bao giờ thay đổi theo thời gian và sẽ là một ứng cử viên tốt cho khóa chính. Nhưng kinh nghiệm cay đắng là hiếm khi như vậy.

INT AUTO_INCREMENT đáp ứng điều kiện "duy nhất và không thay đổi theo thời gian". Do đó ưu tiên.

Tôi đã có một chút khó chịu vì thiếu điểm chuẩn cho trực tuyến này, vì vậy tôi đã tự mình chạy thử.

Lưu ý rằng mặc dù tôi không làm điều đó một cách cơ bản thường xuyên, vì vậy vui lòng kiểm tra thiết lập và các bước của tôi để biết bất kỳ yếu tố nào có thể ảnh hưởng đến kết quả ngoài ý muốn và gửi những lo ngại của bạn trong các bình luận.

Các thiết lập như sau:

• CPU Intel® Core ™ i7-7500U @ 2.70GHz × 4
• RAM 15,6 GiB, trong đó tôi đảm bảo khoảng 8 GB là miễn phí trong quá trình thử nghiệm.
• Ổ SSD 148,6 GB, có nhiều dung lượng trống.
• Ubuntu 16.04 64-bit
• MySQL Ver 14,14 Phân phối 5.7.20, cho Linux (x86_64)

Những cái bàn:

create table jan_int (data1 varchar(255), data2 int(10), myindex tinyint(4)) ENGINE=InnoDB;
create table jan_int_index (data1 varchar(255), data2 int(10), myindex tinyint(4), INDEX (myindex)) ENGINE=InnoDB;
create table jan_char (data1 varchar(255), data2 int(10), myindex char(6)) ENGINE=InnoDB;
create table jan_char_index (data1 varchar(255), data2 int(10), myindex char(6), INDEX (myindex)) ENGINE=InnoDB;
create table jan_varchar (data1 varchar(255), data2 int(10), myindex varchar(63)) ENGINE=InnoDB;
create table jan_varchar_index (data1 varchar(255), data2 int(10), myindex varchar(63), INDEX (myindex)) ENGINE=InnoDB;

Sau đó, tôi đã lấp đầy 10 triệu hàng trong mỗi bảng bằng một tập lệnh PHP có bản chất là như thế này:

$pdo = get_pdo();

$keys = [ 'alabam', 'massac', 'newyor', 'newham', 'delawa', 'califo', 'nevada', 'texas_', 'florid', 'ohio__' ];

for ($k = 0; $k < 10; $k++) {
    for ($j = 0; $j < 1000; $j++) {
        $val = '';
        for ($i = 0; $i < 1000; $i++) {
            $val .= '("' . generate_random_string() . '", ' . rand (0, 10000) . ', "' . ($keys[rand(0, 9)]) . '"),';
        }
        $val = rtrim($val, ',');
        $pdo->query('INSERT INTO jan_char VALUES ' . $val);
    }
    echo "\n" . ($k + 1) . ' millon(s) rows inserted.';
}

Đối với intcác bảng, bit ($keys[rand(0, 9)])được thay thế bằng chỉ rand(0, 9)và đối với varcharcác bảng, tôi đã sử dụng tên trạng thái đầy đủ của Hoa Kỳ mà không cắt hoặc mở rộng chúng thành 6 ký tự. generate_random_string()tạo ra một chuỗi ngẫu nhiên gồm 10 ký tự.

Sau đó, tôi chạy trong MySQL:

• SET SESSION query_cache_type=0;
• Đối với jan_intbảng:
  • SELECT count(*) FROM jan_int WHERE myindex = 5;
  • SELECT BENCHMARK(1000000000, (SELECT count(*) FROM jan_int WHERE myindex = 5));
• Đối với các bảng khác, tương tự như trên, với myindex = 'califo'cho charbảng và myindex = 'california'cho varcharbảng.

Thời gian của BENCHMARKtruy vấn trên mỗi bảng:

• jan_int: 21.30 giây
• jan_int_index: 18,79 giây
• jan_char: 21,70 giây
• jan_char_index: 18,85 giây
• tháng một: 21,76 giây
• jan_varchar_index: 18,86 giây

Về kích thước bảng và chỉ mục, đây là đầu ra của show table status from janperformancetest;(w / một vài cột không được hiển thị):

|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Name              | Engine | Version | Row_format | Rows    | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Collation              |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| jan_int           | InnoDB |      10 | Dynamic    | 9739094 |             43 |   422510592 |               0 |            0 |   4194304 |           NULL | utf8mb4_unicode_520_ci |  
| jan_int_index     | InnoDB |      10 | Dynamic    | 9740329 |             43 |   420413440 |               0 |    132857856 |   7340032 |           NULL | utf8mb4_unicode_520_ci |   
| jan_char          | InnoDB |      10 | Dynamic    | 9726613 |             51 |   500170752 |               0 |            0 |   5242880 |           NULL | utf8mb4_unicode_520_ci |  
| jan_char_index    | InnoDB |      10 | Dynamic    | 9719059 |             52 |   513802240 |               0 |    202342400 |   5242880 |           NULL | utf8mb4_unicode_520_ci |  
| jan_varchar       | InnoDB |      10 | Dynamic    | 9722049 |             53 |   521142272 |               0 |            0 |   7340032 |           NULL | utf8mb4_unicode_520_ci |   
| jan_varchar_index | InnoDB |      10 | Dynamic    | 9738381 |             49 |   486539264 |               0 |    202375168 |   7340032 |           NULL | utf8mb4_unicode_520_ci | 
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

Kết luận của tôi là không có sự khác biệt về hiệu năng cho trường hợp sử dụng cụ thể này.

Phụ thuộc vào độ dài .. Nếu varchar sẽ có 20 ký tự và int là 4, thì nếu bạn sử dụng int, chỉ mục của bạn sẽ có FIVE gấp nhiều lần trên mỗi trang của không gian chỉ mục trên đĩa ... Điều đó có nghĩa là đi qua chỉ mục sẽ yêu cầu 1/5 số lần đọc vật lý và / hoặc logic ..

Vì vậy, nếu hiệu suất là một vấn đề, nếu có cơ hội, hãy luôn sử dụng khóa không có ý nghĩa tích hợp (được gọi là thay thế) cho các bảng của bạn và cho Khóa ngoài tham chiếu các hàng trong các bảng này ...

Đồng thời , để đảm bảo tính nhất quán của dữ liệu, mỗi bảng có vấn đề cũng cần có khóa thay thế không phải là số có ý nghĩa, (hoặc Chỉ mục duy nhất) để đảm bảo rằng các hàng trùng lặp không thể được chèn (trùng lặp dựa trên các thuộc tính bảng có ý nghĩa).

Đối với mục đích sử dụng cụ thể mà bạn đang nói đến (như tra cứu trạng thái) thực sự không có vấn đề gì vì kích thước của bảng quá nhỏ .. Nói chung, không có tác động nào đến hiệu suất từ ​​các chỉ số trên các bảng có ít hơn vài nghìn hàng. ..

Tuyệt đối không.

Tôi đã thực hiện một số ... một vài ... kiểm tra hiệu suất giữa INT, VARCHAR và CHAR.

Bảng kỷ lục 10 triệu với KHÓA CHÍNH (duy nhất và được nhóm) có cùng tốc độ và hiệu suất (và chi phí phụ) cho dù tôi sử dụng loại nào trong ba loại.

Điều đó đang được nói ... sử dụng bất cứ điều gì là tốt nhất cho ứng dụng của bạn. Đừng lo lắng về hiệu suất.

Đối với các mã ngắn, có lẽ không có sự khác biệt. Điều này đặc biệt đúng vì bảng chứa các mã này có thể rất nhỏ (nhiều nhất là vài nghìn hàng) và không thay đổi thường xuyên (lần cuối cùng chúng tôi đã thêm một Tiểu bang mới của Hoa Kỳ).

Đối với các bảng lớn hơn với biến thể rộng hơn giữa các phím, điều này có thể nguy hiểm. Ví dụ, hãy suy nghĩ về việc sử dụng địa chỉ email / tên người dùng từ bảng Người dùng. Điều gì xảy ra khi bạn có một vài triệu người dùng và một số người dùng đó có tên dài hoặc địa chỉ email. Bây giờ bất cứ khi nào bạn cần tham gia bảng này bằng phím đó, nó sẽ trở nên đắt hơn nhiều.

Đối với Khóa chính, bất kỳ nội dung nào làm cho một hàng duy nhất phải được xác định là khóa chính.

Đối với tham chiếu là khóa ngoại, sử dụng số nguyên tăng tự động làm đại diện thay thế là một ý tưởng hay vì hai lý do chính.
- Đầu tiên, thường có ít chi phí phát sinh trong việc tham gia thường xuyên.
- Thứ hai, nếu bạn cần cập nhật bảng chứa varchar duy nhất thì bản cập nhật phải xếp tầng xuống tất cả các bảng con và cập nhật tất cả chúng cũng như các chỉ mục, trong khi với int thay thế, nó chỉ phải cập nhật bảng tổng thể và nó là chỉ mục.

Hạn chế của việc sử dụng người thay thế là bạn có thể cho phép thay đổi ý nghĩa của người thay thế:

ex.
id value
1 A
2 B
3 C

Update 3 to D
id value
1 A
2 B
3 D

Update 2 to C
id value
1 A
2 C
3 D

Update 3 to B
id value
1 A
2 C
3 B

Tất cả phụ thuộc vào những gì bạn thực sự cần phải lo lắng trong cấu trúc của bạn và những gì có nghĩa nhất.

Các trường hợp phổ biến khi người thay thế bị AUTO_INCREMENTtổn thương:

Một mẫu lược đồ phổ biến là ánh xạ nhiều-nhiều :

CREATE TABLE map (
    id ... AUTO_INCREMENT,
    foo_id ...,
    bar_id ...,
    PRIMARY KEY(id),
    UNIQUE(foo_id, bar_id),
    INDEX(bar_id) );

Hiệu suất của mẫu này tốt hơn nhiều, đặc biệt là khi sử dụng InnoDB:

CREATE TABLE map (
    # No surrogate
    foo_id ...,
    bar_id ...,
    PRIMARY KEY(foo_id, bar_id),
    INDEX      (bar_id, foo_id) );

Tại sao?

• Khóa phụ InnoDB cần tra cứu thêm; bằng cách di chuyển cặp vào PK, điều đó tránh được một hướng.
• Chỉ số phụ là "bao phủ", vì vậy nó không cần tra cứu thêm.
• Bảng này nhỏ hơn vì loại bỏ idvà một chỉ mục.

Một trường hợp khác ( quốc gia ):

country_id INT ...
-- versus
country_code CHAR(2) CHARACTER SET ascii

Tất cả quá thường xuyên, người mới bình thường hóa country_code thành 4 byte INTthay vì sử dụng chuỗi 2 byte 'tự nhiên', gần như không thay đổi. Nhanh hơn, nhỏ hơn, ít THAM GIA hơn, dễ đọc hơn.

Tại HauteLook, chúng tôi đã thay đổi nhiều bảng để sử dụng các phím tự nhiên. Chúng tôi đã trải nghiệm sự gia tăng hiệu suất trong thế giới thực. Như bạn đã đề cập, nhiều truy vấn của chúng tôi hiện sử dụng ít tham gia hơn, điều này làm cho các truy vấn trở nên hiệu quả hơn. Chúng tôi thậm chí sẽ sử dụng khóa chính tổng hợp nếu nó có ý nghĩa. Điều đó đang được nói, một số bảng chỉ dễ làm việc hơn nếu chúng có khóa thay thế.

Ngoài ra, nếu bạn cho phép mọi người viết giao diện vào cơ sở dữ liệu của mình, khóa thay thế có thể hữu ích. Bên thứ 3 có thể dựa vào thực tế là khóa thay thế sẽ chỉ thay đổi trong những trường hợp rất hiếm.

Tôi phải đối mặt với tình trạng khó xử tương tự. Tôi đã tạo một DW (lược đồ chòm sao) với 3 bảng thực tế, Tai nạn đường bộ, Phương tiện gặp tai nạn và Thương vong trong Tai nạn. Dữ liệu bao gồm tất cả các vụ tai nạn được ghi nhận tại Vương quốc Anh từ năm 1979 đến năm 2012 và bảng 60 chiều. Tất cả cùng nhau, khoảng 20 triệu hồ sơ.

Các mối quan hệ bảng thực tế:

+----------+          +---------+
| Accident |>--------<| Vehicle |
+-----v----+ 1      * +----v----+
     1|                    |1
      |    +----------+    |
      +---<| Casualty |>---+
         * +----------+ *

RDMS: MySQL 5.6

Về cơ bản, chỉ số Tai nạn là một varchar (số và chữ), có 15 chữ số. Tôi đã cố gắng không có chìa khóa thay thế, một khi các chỉ số tai nạn sẽ không bao giờ thay đổi. Trong máy tính i7 (8 lõi), DW trở nên quá chậm để truy vấn sau 12 triệu bản ghi tải tùy thuộc vào kích thước. Sau rất nhiều lần làm việc lại và thêm các khóa thay thế bigint, tôi đã tăng hiệu suất tốc độ trung bình 20%. Tuy nhiên để đạt được hiệu suất thấp, nhưng thử hợp lệ. Tôi đang làm việc trong điều chỉnh và phân cụm MySQL.

Câu hỏi là về MySQL vì vậy tôi nói có một sự khác biệt đáng kể. Nếu đó là về Oracle (nơi lưu trữ các số dưới dạng chuỗi - vâng, tôi không thể tin vào lúc đầu) thì không có nhiều khác biệt.

Lưu trữ trong bảng không phải là vấn đề nhưng cập nhật và đề cập đến chỉ mục là. Các truy vấn liên quan đến việc tìm kiếm một bản ghi dựa trên khóa chính của nó là thường xuyên - bạn muốn chúng xảy ra nhanh nhất có thể vì chúng xảy ra quá thường xuyên.

Điều này là một CPU xử lý các số nguyên 4 byte và 8 byte một cách tự nhiên, bằng silicon . Thật sự rất nhanh để nó so sánh hai số nguyên - nó xảy ra trong một hoặc hai chu kỳ đồng hồ.

Bây giờ hãy nhìn vào một chuỗi - nó được tạo thành từ rất nhiều ký tự (nhiều hơn một byte cho mỗi ký tự ngày nay). So sánh hai chuỗi ưu tiên không thể được thực hiện trong một hoặc hai chu kỳ. Thay vào đó, các ký tự của chuỗi phải được lặp lại cho đến khi tìm thấy sự khác biệt. Tôi chắc chắn có những thủ thuật để làm cho nó nhanh hơn trong một số cơ sở dữ liệu nhưng điều đó không liên quan ở đây vì một phép so sánh int được thực hiện một cách tự nhiên và nhanh như chớp trong silicon bởi CPU.

Quy tắc chung của tôi - mọi khóa chính phải là INT tự động tăng cường, đặc biệt là trong các ứng dụng OO sử dụng ORM (Hibernate, Datanucleus, bất cứ điều gì) trong đó có rất nhiều mối quan hệ giữa các đối tượng - chúng thường sẽ luôn được triển khai như một FK đơn giản và khả năng cho DB để giải quyết những vấn đề nhanh đó rất quan trọng đối với khả năng phản hồi của ứng dụng.

Không chắc chắn về ý nghĩa hiệu suất, nhưng có vẻ như một sự thỏa hiệp có thể, ít nhất là trong quá trình phát triển, sẽ bao gồm cả khóa "thay thế số nguyên" tự động, cũng như khóa "tự nhiên" duy nhất, dự định của bạn. Điều này sẽ cung cấp cho bạn cơ hội để đánh giá hiệu suất, cũng như các vấn đề khác có thể xảy ra, bao gồm cả khả năng thay đổi của các phím tự nhiên.

Như thường lệ, không có câu trả lời chăn. 'Nó phụ thuộc!' và tôi không phải là người lãnh đạm Sự hiểu biết của tôi về câu hỏi ban đầu là về các khóa trên các bảng nhỏ - như Quốc gia (mã số nguyên hoặc mã char / varchar) là một khóa ngoại đối với một bảng có khả năng lớn như bảng địa chỉ / liên hệ.

Có hai kịch bản ở đây khi bạn muốn lấy lại dữ liệu từ DB. Đầu tiên là một loại truy vấn danh sách / tìm kiếm nơi bạn muốn liệt kê tất cả các liên hệ với mã hoặc tên quốc gia và quốc gia (id sẽ không giúp đỡ và do đó sẽ cần tra cứu). Cái còn lại là một kịch bản get trên khóa chính hiển thị một bản ghi liên hệ duy nhất trong đó tên của tiểu bang, quốc gia cần được hiển thị.

Đối với lần nhận sau, có lẽ không có vấn đề gì về FK dựa trên vì chúng ta tập hợp các bảng cho một bản ghi hoặc một vài bản ghi và trên các lần đọc chính. Kịch bản trước đây (tìm kiếm hoặc danh sách) có thể bị ảnh hưởng bởi sự lựa chọn của chúng tôi. Vì bắt buộc phải hiển thị quốc gia (ít nhất là mã có thể nhận biết và thậm chí chính tìm kiếm đó bao gồm mã quốc gia), nên không phải tham gia bảng khác thông qua khóa thay thế có thể xảy ra (tôi chỉ thận trọng ở đây vì tôi chưa thực sự kiểm tra điều này, nhưng dường như rất có thể) cải thiện hiệu suất; mặc dù thực tế là nó chắc chắn sẽ giúp tìm kiếm.

Vì các mã có kích thước nhỏ - thường không quá 3 ký tự cho quốc gia và tiểu bang, nên có thể sử dụng các khóa tự nhiên làm khóa ngoại trong kịch bản này.

Kịch bản khác trong đó các khóa phụ thuộc vào các giá trị varchar dài hơn và có lẽ trên các bảng lớn hơn; chìa khóa thay thế có lẽ có lợi thế.

Cho phép tôi nói có, chắc chắn có sự khác biệt, có tính đến phạm vi hoạt động (Định nghĩa ngoài hộp):

1- Sử dụng thay thế int nhanh hơn trong ứng dụng vì bạn không cần sử dụng ToUpper (), ToLower (), ToUpperInvarient () hoặc ToLowerInvarient () trong mã của bạn hoặc trong truy vấn của bạn và 4 hàm này có các điểm chuẩn hiệu suất khác nhau. Xem quy tắc hiệu suất của Microsoft về điều này. (hiệu suất của ứng dụng)

2- Sử dụng thay thế int đảm bảo không thay đổi khóa theo thời gian. Ngay cả mã quốc gia cũng có thể thay đổi, hãy xem Wikipedia cách mã ISO thay đổi theo thời gian. Điều đó sẽ mất rất nhiều thời gian để thay đổi khóa chính cho các cây con. (hiệu suất bảo trì dữ liệu)

3- Dường như có vấn đề với các giải pháp ORM, chẳng hạn như NHibernate khi PK / FK không phải là int. (hiệu suất của nhà phát triển)