Mysql
 sql >> база данни >  >> RDS >> Mysql

Производителност на MySQL BIGINT(20) срещу Varchar(31).

Това наистина трябва да се измери, можем да направим някои „предположения“ въз основа на това, което знаем и това, което предполагаме, но това са само предположения.

Не споменавате дали тази таблица е InnoDB, или MyISAM с динамични редове, или MyISAM с редове с фиксирана дължина. Това ще има някаква разлика.

Но за стойности като тази, която публикувахте, '961637593864109_412954765521130' (31 знака), ако приемем, че използвате еднобайтов набор от знаци (напр. latin1) или набор от знаци, който кодира тези конкретни знаци в един байт (напр. utf8)...

За InnoDB и MyISAM динамичен формат това са 31+1-8=24 допълнителни байта за този ред. (BIGINT се побира в 8 байта, стойност на VARCHAR(31) от 31 знака ще използва 32 байта.)

За таблица MyISAM с редове с фиксирана дължина, това би било разлика от 23 байта на ред. (Мястото е запазено за всичките 31 знака и дължината не трябва да се съхранява.)

Тази стойност на първичния ключ също ще се повтаря във всеки индекс, така че има и увеличено пространство с всеки индекс.

Ако приемем, че редовете на вашата таблица са 120 байта с помощта на BIGINT, а редовете са 144 байта с VARCHAR, това е 20% нараства. Колкото по-големи са вашите редове, толкова по-малко е процентното увеличение и обратното.

За 1 000 000 реда (много ми се иска да кажа „един меелюн ред“ по същия начин, по който д-р Евил поставя малкия си пръст в ъгъла на тази уста и казва „един милион долара“), тези допълнителни 24 байта на ред възлизат общо на около 24 MB.

Но всъщност не е толкова лесно. От гледна точка на InnoDB пространството, въпросът е как редовете могат да се "поберат" в блок. Колкото по-голям е средният размер на реда, толкова по-голямо количество свободно пространство ще има в блок.

Ако не правите нищо с редовете, освен да ги съхранявате на диск, тогава това наистина е просто увеличение на дисковото пространство и допълнително време и пространство за архивиране.

Ако същият брой редове от „144 байта“ се побират в блок като редове от „120 байта“, тогава няма да видите разлика в пространството. Но ако по-малко редове се побират в един блок, това означава повече блокове, повече място в InnoDB буферния пул, повече i/o и т.н.

За заявки на един ред, или чрез стойност на първичен ключ, или чрез някакво друго уникално търсене на индекс, разликата ще бъде незначителна.

Ако имате работа с по-големи набори от резултати, тогава това е допълнителна памет за подготовка на набора от резултати и допълнителни байтове за прехвърляне към клиента и т.н.

Ако ключът VARCHAR е проектиран по такъв начин, че "групи" от редове, които са достъпни заедно, имат една и съща водеща част от стойността на ключа, тогава с InnoDB може действително да има известно подобрение на производителността. Това е така, защото първичният ключ е ключът на клъстера... много по-голям шанс редовете, необходими за удовлетворяване на заявка, са в един и същ блок, вместо да бъдат разпръснати в куп блокове.

Обратното е, че ако има извършени вмъквания и изтривания, ще има повече свободно място в някои блокове. (С изтриванията пространството за изтритите редове остава в блока; за да го използвате повторно, трябва да вмъкнете ред, който има същата стойност на ключ (или поне стойност на ключ, достатъчно близка, за да попадне в същия блок .) И с произволни вмъквания ще получим разделяне на блокове.




  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как да заредите данни в таблицата на mysql, но да игнорирате празните редове

  2. Как да ВМЕСИТЕ запис или АКТУАЛИЗИРАТЕ, ако вече съществува?

  3. Алтернатива на много булеви стойности в MySQL?

  4. Има ли начин да се намери най-голям брой десетични знаци в Excel

  5. Многоезичен тип данни в MYSQL