Comments on: TEXT vs. VARCHAR

By: Nate Haug

Nate Haug — Thu, 24 Nov 2011 02:06:22 +0000

If the VARCHAR is the only row in the table, and does not allow NULL values, the maximum length allowed for VARCHAR is 65,532 bytes.

This sentence is incorrect. It should be “If the VARCHAR is the only COLUMN in the table”, not “row”. If you have multiple varchar columns, you should assume 65,532/(varchar columns) max per row.

By: khalid mahmood

khalid mahmood — Mon, 31 Oct 2011 10:21:51 +0000

So what about storing texts like abstracts or mails, that have 10 000 to 30 000 characters. Should one use VARCHAR(30000) or TEXT ? The most important thing for me is performance, full-text search performance. What column type would be faster? For example i have the ‘articles’ table, with columns: title (1000 chars), abstract (30000 chars), and i want to quickly find particular article(s) in a table like 20 000 000 rows using full-text search.

By: OnLine

OnLine — Sun, 30 Oct 2011 16:32:35 +0000

Hi,
From what i read on other websites, TINYTEXT uses less memory, but in long run request can fragment it.
‘i don’t know if its something better.

By: xerxes

xerxes — Mon, 28 Feb 2011 14:14:53 +0000

Since MEMORY engine (think temp tables) maps variable-width types as appropriate fixed-width counterparts, those are obliviously padded to the maximum width of the original column. Does using NULL effectively rule out padding for specific rows thus saving memory or the value still gets padded *with* the flag included?

I assume no padding occurs in case of NULL, and that’s why DEFAULT ” on variable-width types is generally considered bad practice. Am I correct?

By: Sheeri Cabral

Sheeri Cabral — Mon, 14 Jun 2010 18:18:58 +0000

Michael — the “Conclusions” section of the blog post should be pretty clear about that.

Conclusions
Because of the storage implications, it is preferable to use VARCHAR instead of TINYTEXT.

Of course, that’s if that’s possible, you may run into other size limitations (such as row size, or size if you are using a multi-byte character set).

Make sure you are aware of the effects of a multi-byte character set. VARCHAR(255) stores 255 characters, which may be more than 255 bytes.

I will also add that the answer to “would there be an overall performance benefit” is almost always “I can tell you for a general case but the best way to do it would be to get benchmarks for a system with load, then try the change out and take benchmarks again.” I cannot stress having a testing environment enough in these cases.

That being said, I would expect better performance with VARCHAR than with TINYTEXT. However, depending on what you’re doing, the best solution might be something completely different, such as having a different storage engine or putting the text in a different application. (MySQL’s FULLTEXT search isn’t as good as other solutions such as Sphinx and Lucene)

By: Michael Oleksak

Michael Oleksak — Mon, 14 Jun 2010 17:08:32 +0000

Thank you Sheeri, I thought about it right after I typed it. What is your opinion on setting the VARCHAR size to 30000 – which in our case should suffice, considering the number of characters being input to that particular field?

Would there be an overall performance benefit?

By: Sheeri Cabral

Sheeri Cabral — Mon, 14 Jun 2010 12:38:35 +0000

Michael,

You cannot create a varchar field with no size declaration.

By: Michael Oleksak

Michael Oleksak — Sun, 13 Jun 2010 02:43:10 +0000

I have a table that contains a description field set as TEXT in which my clients enter descriptive text in the CMS.

It can contain regular text, and html markup.

My first consideration is to perform a vetical partition on the table so the description field is in a separate table,

My question is, would I benefit (overall site performance ) by converting this field to varchar with no size declaration?

By: Sheeri Cabral

Sheeri Cabral — Tue, 20 Apr 2010 17:36:36 +0000

I would use TEXT – the maximum theoretical size of varchar is 65,536 bytes and in practice it’s shorter….so if you have VARCHAR(30000) and the character set is utf-8, you won’t be able to create that column. If you’re using a character set that is 1 or 2 bytes per character, you can create it, but I wouldn’t limit myself like that in case you want to convert in the future.

If you want fast fulltext search, using MySQL’s FULLTEXT search is not the best tool — consider using Sphinx or Lucene.

By: Janusz

Janusz — Fri, 16 Apr 2010 11:35:24 +0000