Is there any efficiency/security concerns over increasing the 8000 char content limit to 90,000?

Question

Following up wiht the post

http://www.question2answer.org/qa/34521/change-answer-8000-limit

do you guys see any efficency or security concerns if I increase the allowable maximum size of question contents from 8,000 (as is) to 88,000 ?

--- added later---

Whe I practiced that in phpMyAdmin here is what happneded:

in practice the type changed to mediumtext!

 

Answer 1

Short answer: You can't. The limit of a VARCHAR is 65535. You could use fields in the TEXT data type family if you need such an amount. Assuming 65535 is ok for you I'll continue with the answer.

Now, 65535 might not be possible either because that value might exceed the maximum amount of size per table row too. This is the error you could get:

ERROR 1118 (42000): Row size too large. The maximum row size for the
used table type, not counting BLOBs, is 65535. You have to change some
columns to TEXT or BLOBs

So you should decrease that value until you succeed in the creation of the field.

Assuming you have finally found that number... there is no security issue to be concerned about, that's for sure.

Regarding efficency... I would advice you to reach to an answer yourself empirically. I've been looking for an answer myself and I couldn't find it. Documentation says nothing about it so everything points to the fact that there is no performance decrement... except this post: http://stackoverflow.com/a/205472/268273

I've found that answer many times in SO but always that user mentioned that. If it is true or not I don't know and, as you can see, the origin seems to be nothing but gossip. Best thing you can do is give it a try :)

Comments

Thank you for your answer Debian
I edited my question and appended some interesting stuff .Please see after "--- added later---"

---

Well, definitely a different approach than increasing a VARCHAR column. TEXT fields store data in a different place rather than the table itself (internally, when it comes to querying it, it is the same) so you won't face the row size limit. However, documentation states that, in general, TEXT fields are slower than VARCHAR. This does have some official sources:
http://dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html
In this case MySQL generates temporary tables in disk rather than in memory.
This is a related and interesting post too: http://dba.stackexchange.com/questions/386

PS: Debian is the operative system I use (http://www.debian.org)

---

Thank you, helpful notes pupi.
As for debian, sorry my bad, i know what debian is but thought you picked something random like what I did and picked the company's name used to work for.

---

Benchmark on VARCHAR vs. TEXT: http://stackoverflow.com/a/24156661/1066234

I remember having the same issue, someone warned me about updates that might set varchar=8000 again, which would kill your content.

---

Thank you Kai,
In practice I could increase the content size to 20,000. So how did you solve your issue?

---

It will definitely be better to stick with VARCHAR. Running updates when saving more than 8k characters on that field will obviously take more time than just saving 8k. However, saving 8k or less in that field should take the same time, regardless of the max size. What I mean is: you don't save the full size of a VARCHAR (that happens with the CHAR only).

Anyway, if it takes a few extra milliseconds when running an update but you're allowing them to store more data, nobody will complain about it.

Regarding TEXT it makes sense it takes more time... I wouldn't have expected it to take 3 times what it takes with a VARCHAR but probably that would depend on the query run.

---

@Waterfr Villa: I sticked to Varchar(8000) and am forcing my users now (few that post long text), to split the text in two parts (one in question, one in comment) OR (one in question, one in anohter question).