MySQL varchar (2000) против текста?

Question

Мне нужно хранить в среднем абзац текста, который в базе данных будет около ~ 800 символов.В некоторых редких случаях оно может доходить до 2000-2500 символов.Я прочитал руководство и знаю, что многие из этих вопросов уже есть, но я прочитал более 10+ вопросов по stackoverflow, и мне все еще трудно понять, должен ли я просто использовать текст или что-то вроде varchar (2000).Половина, похоже, использует varchar, а другая половина - текст.Некоторые люди говорят, что всегда используйте текст, если у вас более 255 символов (да, это было после 5.0.3, что позволило varchar до 65k).Но потом я подумал, что если я буду использовать текст каждый раз, когда число символов превышает 255, то почему mysql вообще не стал увеличивать размер, если это всегда лучший вариант?

Они оба имеют переменный размер впамять, которую я прочитал, так что не будет никакой разницы в моей ситуации?Лично я склонялся к varchar (2000), затем прочитал, что varchar хранит данные встроенными, а текст - нет.Означает ли это, что если я постоянно выберу этот столбец, лучше будет сохранить данные как varchar, и, наоборот, если я редко выберу этот столбец, лучше использовать текст?Если это так, я думаю, что теперь я бы выбрал текстовый столбец, так как я не буду выбирать этот столбец много раз, когда запускаю запрос к таблице.Если это имеет значение, к этой таблице также часто присоединяются (но не будут выбирать столбец), будет ли это также способствовать преимуществам использования текста?

Верны ли мои предположения, что я должен идти с текстомв этом случае?

Answer 1

Если в таблице есть столбцы TEXT или BLOB, таблица не может быть сохранена в памяти. Это означает, что каждый запрос (который не попадает в кэш) должен иметь доступ к файловой системе, которая на несколько порядков медленнее, чем память.

Поэтому вы должны хранить этот столбец TEXT в отдельной таблице, доступ к которой возможен только тогда, когда вам это действительно нужно. Таким образом, исходная таблица может быть сохранена в памяти и будет намного быстрее.

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

Вы ничего не зарабатываете, храня текст в нескольких таблицах. Вам все еще нужно получить доступ к файловой системе.

Извините, что я имел в виду, например, скрипт форума, в таблице сообщений они могут> хранить 20 столбцов данных сообщений, они также сохраняют фактическое сообщение в виде текстового поля в> той же таблице. Так что столбец сообщения должен быть выделен?

Да.

Кажется странным иметь таблицу с именем post, но фактическая запись там не хранится, может быть,> в другой таблице с именем "actual_post" не уверен, lol.

Вы можете попробовать (posts, post_text) или (post_details, posts) или что-то в этом роде.

У меня есть таблица тегов, в которой всего три поля: tag_id, tag и description. Так что> столбец описания также должен быть выделен? Итак, мне нужна таблица тегов и таблица> tags_description только для хранения 3 столбцов?

Если описание является столбцом TEXT и вы выполняете запросы к этой таблице, для которой описание не нужно, это, безусловно, будет предпочтительнее.

Answer 2

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