Това зависи изцяло от използваната СУБД машина. Самият SQL не изисква как нещата да се съхраняват физически, а просто как се виждат логически.
Например, вашата СУБД може да разпредели място в реда за максимален размер, плюс някои допълнителни байтове за съхраняване на дължината. В този случай ще има голяма разлика между varchar(10) и varchar(1000) тъй като ще загубите доста място на ред.
Като алтернатива може да използва буферен пул за varchar данни и съхранявайте само дължината и "началния адрес" на буферния пул в реда. В този случай всеки отделен ред ще съхранява информация с идентичен размер за varchar колона, независимо от нейния размер, но ще има добавена стъпка за извличане на действителните данни в тази колона (следвайки връзката към буферния пул).
Причината да използвате varchar точно затова е наречен varchar . Позволява ви да съхранявате елементи от данни с променлив размер. Обикновено char(10) ви дава десет знака, независимо от всичко, допълвайки го с интервали, ако вмъкнете нещо по-кратко. Можете да отрежете крайните интервали, докато ги извличате, но това няма да работи толкова добре, ако данните, които искате да съхраните, всъщност са "hello " , с крайно пространство, което искате да запазите.
Приличен СУБД може да реши да направи компромис в зависимост от максималния размер на varchar колона. За къси, може просто да го съхранява в ред в реда и да консумира допълнителните байтове за размера.
По-дълъг varchar колоните могат да бъдат "изнесени" към отделен пул за буфери, за да се гарантира, че четенето на редове се поддържа ефективно (поне докато не не трябва големият varchar колона, така или иначе).
Това, което трябва да направите, е да зададете отново въпроса за вашата конкретна СУБД, за да получите по-целенасочен отговор.
Или, честно казано, проектирайте вашата база данни така, че да съхранява само максималния размер. Ако знаете, че е 10, тогава varchar(1000) е отпадък. Ако в бъдеще трябва да увеличите колоната, това е моментът да го направите, а не сега (вижте YAGNI
).
За MySQL ще искате да разгледате Chapter 14 Storage Engines
на онлайн документацията.
Той обхваща различните механизми за съхранение (като InnoDB и MyISAM), които MySQL използва и, като погледнете достатъчно дълбоко, можете да видите как информацията се съхранява физически.
Например, в MyISAM, наличието на данни с променлива дължина в таблица (varchar включено) обикновено означава динамични таблици
. Това следва схема, приблизително аналогична на концепцията на буферния пул, който споменах по-горе, с предимството, че се губи по-малко място за колони с променлив размер и недостатъкът, че редовете могат да бъдат фрагментирани.
Другият формат за съхранение (с отстъпка от компресирания формат, тъй като наистина се използва само за таблици само за четене) е статичен , където данните се съхраняват в един физически ред.
Информация за физическите структури на InnoDB може да се намери тук . В зависимост от това дали използвате файловия формат Antilope или Barracuda, в крайна сметка получавате ситуацията „цялата информация е физически ред“ или „буферен пул“, подобно на разграничението на MyISAM между динамичен и статичен.
