Чи є РЕАЛЬНА різниця в роботі між первинними ключами INT і VARCHAR?

Чи є вимірювана різниця в продуктивності між використанням INT проти VARCHAR в якості основного ключа в MySQL? Я хотів би використовувати VARCHAR як основний ключ для довідкових списків (думаю, штати США, коди країн), а колега не зміщуватиметься на INT AUTO_INCREMENT як первинний ключ для всіх таблиць.

Мій аргумент, докладно описаний тут , полягає в тому, що різниця в продуктивності між INT і VARCHAR незначна, оскільки для кожного посилання на зовнішній ключ INT потрібна ПРИЄДНАЙТЕ, щоб мати сенс посилання, ключ VARCHAR буде безпосередньо представляти інформацію.

Отже, хтось має досвід роботи з цим конкретним випадком використання та пов'язаними з ним ефективністю?

Ви добре зазначаєте, що можете уникнути деякої кількості об'єднаних запитів, використовуючи природний ключ замість сурогатного ключа . Тільки ви можете оцінити, чи користь від цього значна у вашій заявці.

Тобто ви можете виміряти запити у вашій програмі, які є найважливішими для швидкої роботи, оскільки вони працюють з великими обсягами даних або виконуються дуже часто. Якщо ці запити виграють від усунення приєднання і не страждають за допомогою первинного ключа varchar, виконайте це.

Не використовуйте жодної стратегії для всіх таблиць у вашій базі даних. Цілком ймовірно, що в деяких випадках природний ключ краще, але в інших випадках сурогатний ключ.

Інші люди добре підкреслюють, що на практиці рідко природний ключ ніколи не змінюється чи не має дублікатів, тому сурогатні ключі зазвичай варті.

Справа не в продуктивності. Йдеться про те, що робить хороший первинний ключ. Унікальний і незмінний з часом. Ви можете подумати, що така організація, як код країни, ніколи не змінюється з часом і була б хорошим кандидатом на первинний ключ. Але гіркий досвід - це рідко так.

INT AUTO_INCREMENT відповідає умові "унікального та незмінного у часі". Звідси перевага.

Мене трохи роздратувала відсутність орієнтирів для цього в Інтернеті, тому я сам пройшов тест.

Зауважте, що я не роблю це регулярно, тому, будь ласка, перевірте мої налаштування та дії, щоб виявити будь-які фактори, які могли б ненавмисно вплинути на результати, та залиште свої занепокоєння у коментарях.

Установка була такою:

• Процесор Intel® Core ™ i7-7500U при 2,70 ГГц × 4
• 15,6 Гб оперативної пам’яті, з яких я гарантував, що близько 8 ГБ було вільним під час тесту.
• SSD накопичувач 148,6 ГБ, з великою кількістю вільного місця.
• 64-розрядний Ubuntu 16.04
• MySQL Ver 14.14 Distrib 5.7.20, для Linux (x86_64)

Таблиці:

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;

Потім я заповнив 10 мільйонів рядків у кожній таблиці сценарієм PHP, суть якого така:

$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.';
}

Для intтаблиць біт ($keys[rand(0, 9)])було замінено на просто rand(0, 9), а для varcharтаблиць я використав повні імена штатів США, не розрізаючи і не поширюючи їх на 6 символів. generate_random_string()генерує 10-символьну випадкову рядок.

Потім я побіг у MySQL:

• SET SESSION query_cache_type=0;
• Для jan_intстолу:
  • SELECT count(*) FROM jan_int WHERE myindex = 5;
  • SELECT BENCHMARK(1000000000, (SELECT count(*) FROM jan_int WHERE myindex = 5));
• Для інших таблиць, як і вище, myindex = 'califo'для charтаблиць і myindex = 'california'для varcharтаблиць.

Часи BENCHMARKзапиту в кожній таблиці:

• січень: 21.30 сек
• jan_int_index: 18,79 сек
• січень: 21,70 сек
• jan_char_index: 18,85 сек
• січень: 21,76 сек
• jan_varchar_index: 18,86 сек

Що стосується розмірів таблиць та індексів, то тут виводиться результат show table status from janperformancetest;(без декількох стовпців не показано):

|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 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 | 
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

Мій висновок полягає в тому, що для цього конкретного випадку використання немає різниці в продуктивності.

Залежить від довжини .. Якщо варчар буде 20 символів, а int - 4, то, якщо ви використовуєте int, ваш індекс матиме П'ять разів більше вузлів на сторінці місця в індексі на диску ... Це означає, що обхід для індексу знадобиться п'ята частина більшої кількості фізичних та / або логічних читань.

Отже, якщо продуктивність - це проблема, надається можливість, завжди використовуйте цілісний несуттєвий ключ (який називається сурогатом) для ваших таблиць та для зовнішніх ключів, які посилаються на рядки в цих таблицях ...

У той же час , щоб гарантувати узгодженість даних, кожна таблиця, де це має значення, також повинна мати значущий нечисловий альтернативний ключ (або унікальний індекс), щоб забезпечити неможливість вставлення повторюваних рядків (дублікат на основі значущих атрибутів таблиці).

Для конкретного використання, про яке ви говорите (наприклад, пошук у державі), це насправді не має значення, оскільки розмір таблиці настільки малий. Загалом, на показники роботи на показниках на таблицях з меншими кількома тисячами рядків немає впливу. ..

Абсолютно не.

Я зробив кілька ... кілька ... перевірок працездатності між INT, VARCHAR і CHAR.

10-мільйонна таблиця записів з ПЕРВИЧНИМ КЛЮКОМ (унікальна та кластеризована) мала точно таку ж швидкість та продуктивність (і вартість піддерева) незалежно від того, який із трьох я використовував.

За словами ... використовуйте все, що найкраще для вашої програми. Не турбуйтеся про виступ.

Для коротких кодів, мабуть, різниці немає. Це особливо вірно, оскільки таблиця з цими кодами, ймовірно, буде дуже маленькою (максимум пару тисяч рядків) і не часто змінюється (коли востаннє ми додали новий штат США).

Для більших таблиць із більшою варіацією серед ключових це може бути небезпечно. Наприклад, подумайте про використання електронної пошти / імені користувача з таблиці користувача. Що відбувається, коли у вас є кілька мільйонів користувачів, а деякі з них мають довгі імена або адреси електронної пошти. Тепер, коли вам потрібно приєднатися до цієї таблиці за допомогою цього ключа, вона стає значно дорожчою.

Що стосується первинного ключа, те, що фізично робить рядок унікальним, слід визначати як первинний ключ.

Довідка як іноземний ключ, використання автоматичного приростаючого цілого числа в якості сурогата є приємною ідеєю з двох основних причин.
- По-перше, у з'єднанні зазвичай виникає менше накладних витрат.
- По-друге, якщо вам потрібно оновити таблицю, яка містить унікальний варчар, то оновлення має спускатися до всіх дочірніх таблиць і оновлювати їх усі, а також індекси, тоді як при сурогаті int воно має лише оновити оновлення головна таблиця та її індекси.

Недолік використання сурогату полягає в тому, що ви можете дозволити змінити значення сурогату:

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

Все залежить від того, про що ви дійсно повинні турбуватися у своїй структурі та що найбільше означає.

Поширені випадки, коли сурогат AUTO_INCREMENTболить:

Поширений шаблон схеми - це багато-багато-зіставлення :

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

Продуктивність цієї моделі значно краща, особливо при використанні InnoDB:

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

Чому?

• Вторинні ключі InnoDB потребують додаткового пошуку; переміщення пари в ПК, що уникається в одному напрямку.
• Вторинний індекс "охоплює", тому він не потребує додаткового пошуку.
• Ця таблиця менша через звільнення idта один індекс.

Інший випадок ( країна ):

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

Надто часто новачок нормалізує код країни в 4-байт INTзамість того, щоб використовувати "природний" 2-байтний, майже незмінний 2-байтний рядок. Швидше, менше, менша кількість ПРИЄДНАЙТЕСЬ, читабельніше.

У HauteLook ми змінили багато наших таблиць, щоб використовувати природні ключі. Ми відчули збільшення продуктивності в реальному світі. Як ви вже згадували, багато наших запитів зараз використовують менше приєднань, що робить запити більш ефективними. Ми навіть використовуватимемо складений первинний ключ, якщо це має сенс. Незважаючи на це, з деякими таблицями просто легше працювати, якщо у них є сурогатний ключ.

Крім того, якщо ви дозволяєте людям писати інтерфейси до вашої бази даних, сурогатний ключ може бути корисним. Третя сторона може розраховувати на те, що сурогатний ключ зміниться лише в дуже рідкісних обставинах.

Я зіткнувся з тією ж дилемою. Я зробив DW (схему сузір'я) з 3 таблицями фактів, дорожньо-транспортні пригоди, транспортні засоби при ДТП та ДТП. Дані включають усі нещасні випадки, зафіксовані у Великобританії з 1979 по 2012 роки, та 60 розмірних таблиць. Усього разом близько 20 мільйонів записів.

Стосунки таблиць фактів:

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

RDMS: MySQL 5.6

Рідно індекс ДТП - це вархар (цифри та літери) з 15 цифрами. Я намагався не мати сурогатних ключів, як тільки показники аварій ніколи не зміниться. У комп'ютері i7 (8 ядер) DW став надто повільним для запиту після 12 мільйонів записів навантаження залежно від габаритів. Після багатого переробітку та додавання сурогатних ключів bigint я отримав середнє підвищення швидкості роботи на 20%. І все-таки низький приріст продуктивності, але спробуйте. Я працюю в настройці та кластеризації MySQL.

Питання стосується MySQL, тому я кажу, що є суттєва різниця. Якщо мова йшла про Oracle (який зберігає числа як рядок - так, спершу я не міг повірити), то різниці не було.

Зберігання в таблиці не є проблемою, але оновлення та посилання на індекс є. Запити, пов'язані з пошуком запису на основі його основного ключа, є частими - ви хочете, щоб вони виникали якомога швидше, оскільки вони трапляються так часто.

Річ у тому, що процесор має 4 байтові та 8 байтові цілі числа, природно, у кремнію . Справді швидко порівняти два цілі числа - це відбувається за один або два тактових цикли.

Тепер погляньте на рядок - вона складається з безлічі символів (більше одного байта на символ в ці дні). Порівнювати два рядки за перевагою не можна за один або два цикли. Натомість символи рядків повинні бути повторені, поки не буде знайдена різниця. Я впевнений, що в деяких базах даних є прийоми, щоб зробити це швидше, але це не має значення, оскільки порівняння int відбувається природним чином і блискавично відбувається в силіконі процесором.

Моє загальне правило - кожен первинний ключ повинен бути автоматичним збільшенням INT, особливо в додатках OO, що використовують ORM (Hibernate, Datanucleus, будь-що інше), де між об'єктами існує велика кількість взаємозв'язків - вони завжди завжди реалізуються як простий FK та можливість для БД для вирішення цих швидких важливих для вашої програми.

Не впевнений у наслідках для продуктивності, але, мабуть, можливим компромісом, принаймні під час розробки, було б включити як автоматично збільшений, цілочисельний "сурогатний" ключ, так і ваш призначений, унікальний, "природний" ключ. Це дасть вам можливість оцінити продуктивність, а також інші можливі проблеми, включаючи зміну природних ключів.

Як завжди, бланкетних відповідей немає. 'Це залежить!' і я не ставлюсь до вибагливості. Моє розуміння первісного питання полягало в тому, що ключі на невеликих таблицях - наприклад, Country (цілий ідентифікатор або char / varchar-код), який є іноземним ключем до потенційно величезної таблиці, як-от адреса / таблиця контактів.

Тут є два сценарії, коли потрібно повернути дані з БД. По-перше, це список списку / пошукового запиту, де потрібно перелічити всі контакти з кодами штату та країни чи іменами (ідентифікатори не допоможуть, а значить, знадобиться пошук). Інший - сценарій отримання на первинному ключі, який показує єдину запис контактів, де має бути вказана назва держави, країни.

Для останнього отримання, мабуть, не має значення, на чому заснований ФК, оскільки ми об'єднуємо таблиці для одного запису або декількох записів і для ключових зчитувань. Наш вибір (пошук або список) може вплинути на наш вибір. Оскільки потрібно показати країну (принаймні, розпізнаваний код і, можливо, навіть сам пошук включає код країни), не потрібно приєднуватися до іншої таблиці через сурогатний ключ потенційно (я просто насторожений тут, тому що я насправді не перевіряв це, але здається дуже ймовірним) підвищення продуктивності; незважаючи на те, що це безумовно допомагає в пошуку.

Оскільки коди мають невеликі розміри - зазвичай не більше 3 символів для країни та штату, у цьому випадку може бути нормально використовувати природні ключі як зовнішні ключі.

Інший сценарій, коли клавіші залежать від більш довгих значень вархара та, можливо, від більших таблиць; сурогатний ключ, ймовірно, має перевагу.

Дозвольте сказати, що так, безумовно, є різниця, беручи до уваги масштаб продуктивності (Визначення з поля):

1- Використання сурогатного int швидше в застосуванні, оскільки вам не потрібно використовувати у своєму коді чи запиті ToUpper (), ToLower (), ToUpperInvarient () або ToLowerInvarient (), і ці 4 функції мають різні показники ефективності. Про це див. Правила продуктивності Microsoft. (виконання заявки)

2- Використання сурогатного int гарантує не змінювати ключ з часом. Навіть коди країн можуть змінюватися, дивіться у Вікіпедії, як змінилися коди ISO з часом. На це знадобиться багато часу, щоб змінити основний ключ для subtrees. (продуктивність обслуговування даних)

3- Здається, є проблеми з рішеннями ORM, наприклад, NHibernate, коли PK / FK не є int. (продуктивність розробника)