Есть ли разница для скорости работы БД при установке типа text, а не varchar 128?

Question

[Ispanec1998]

Есть ли разница для скорости работы БД при установке типа text, а не varchar 128?
Столкнулся с ситуацией, что 128 символов для одной колонки стало недостаточно
Есть ли смысл так разграничивать типы колонок по типу varchar, а не text?
Или можно везде ставить text и не париться?

Comments

[Ипатьев]

вы специально что ли поставили эти теги?
чтобы модератор побыстрее вопрос удалил?

[Виктор Таран]

Нее не парься это придумали идиоты чтоб тебе просто позабавиться, конечно оно ниначе не влияет. ведь.
Естественно разница есть. Но порой она незначительна.
99% что в твоем случае это не повлияет ни на что
но есть процент отличный от нуля что скорость упадет, это зависит от структуры запросов размера таблиц и тд и тп.
Если у тебя там не гигабайты таблицы и не по 300 джойнов, думаю что разницу ты не увидешь

[Ispanec1998]

Ипатьев, какие надо было ставить?
Я в бд новенький

[Ispanec1998]

Виктор Таран, если поставить длину varchar 256, а не 255 это что-то изменит в худшую сторону или там не длинны по байтам и скорость зависит исключительно от числового диапазона вроде 100, 200, 300?

[Ипатьев]

Ispanec1998, настолько новенький, что не можете даже сказать, какая у вас БД?

[Виктор Таран]

Ispanec1998,

если поставить длину varchar 256, а не 255

Технически да но, не уверен что даже при синтетическом замере найдете разницу особенно на вашей бд, если разговор идет о во истину гигантских базах возможно разинца и будет видна но не настолько чтоб вам задавая такие простые вопросы нужнобыло этим париться.
Просто соблюдайте на данном этапе достаточность " текст как текст" число как число, даты датами.
Суммарно этот дает профит. Если же выверять до байта в данный момент вам это ничего не даст.
Посколку на текущем этапе вам нужно заняться оптимизацией самих запросов в бд, это даст куда более серьезный профит. Если опять еж он вам уже нужен

[Ispanec1998]

Ипатьев, MySQL

[Ипатьев]

А это ничего, что почти все ответы здесь про POSTGRESQL?

[Ispanec1998]

Ипатьев, я думал они почти одно и то же, только постгрес чутка получше в функционале

[Ипатьев]

да хоть не чутка. КАКОЙ СМЫСЛ задавать вопрос про базу, которой вы не пользуетесь?

[Дмитрий]

Ispanec1998, мягко говоря не чутка. Особенно в плане того как они хранят данные.

Answer 1

[Дмитрий]

Don't use varchar(n) by default

З.Ы. Однако наверное стоит не забывать про Toast

Comments

[Ispanec1998]

Т.е. всегда указывать тип text, а varchar ставить лишь тогда, когда я сам хочу ограничить какуето колонку по длине текста во избежание умышленного засорения злоумышленными пользователями?

[Дмитрий]

Ispanec1998, именно. ибо если оно вылезет за пределы не вспомню какого размера, постгрес будет класть его в отдельное место в сжатом виде - Toast. И доставать его оттуда - это + к накладным расходам.

[Дмитрий]

typically 8KB

Answer 2

[rPman]

varchar/text/bytea в postgres используют одну и ту же технологию хранения и производительность будет напрямую зависеть от реального размера строк и от оптимизаций
https://habr.com/ru/company/tensor/blog/498292/

Answer 3

[mayton2019]

Лимиты на текстовые поля - это архаизм и пережитки старины далёкой. Они имели большой смысл для DBase, Clipper, FoxPro но для современных БД практически уже неактуальны. Можно брать text.
Даже Oracle вобщем-то снял лимит 4000 байт на строку и настройками системных параметров можно его растянуть хотя-бы в 32 килобайта.

Тем более что в поля все чаще кладут semi-structured информацию (JSON/XML e.t.c).

Но вы можете их использовать просто как констрейнт чтобы акцентировать внимание что поле имеет особый вид строки. Например хеш SHA-256 или какой-то ключ или UUID.

Поддерживаю Дмитрия в наблюдении за oversized attribute.

Answer 4

[Константин Цветков]

Столкнулся с ситуацией, что 128 символов для одной колонки стало недостаточно

VARCHAR(255) — скорость не изменится.

Comments

[Ispanec1998]

Почему 255, а не 256?

[SagePtr]

Ispanec1998, 255 помещается в один байт, 256 уже нет

[Ispanec1998]

SagePtr, получается 128 бессмысленная запись и минимальная должна быть всегда 255?

[SagePtr]

Ispanec1998, тут этот вопрос поднимался: https://dba.stackexchange.com/questions/76469/mysq...

[Ипатьев]

SagePtr, там стандартное бормотание чувака, который очень хочет показаться очень умным. Но по делу там ни слова.

[mayton2019]

Я думаю что length prefix автору будет безразличен. И не стоит вообще в такие дебри залезать. Звучал вопрос про скорость. На скорость работы БД в MySQL влияет очень много факторов. Это железо. Выбор table engine. Организация блока или страницы для ДАННОЙ таблицы. А тогда надо обсуждать другие колонки. Наличие индекса и прочее. И где-то далекоо... на 100-м месте у нас будет стоять length prefix чорт бы его побрал. И зачем вообще обсуждать 255 или 256 это никак не помогает автору а только его запутывает.