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

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

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

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

Ответ 1

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

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

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

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

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

Да.

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

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

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

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

Ответ 2

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