So instead of varchar(255) if i create it as varchar(2000) does it effects the performance ?
It rather depends. While the system can accomodate this, consider the following table:
create table example (
id int NOT NULL AUTOINCREMENT,
smallstr VARCHAR(20),
anumber mediumint(6) DEFAULT 0,
bigstr (2000)
PRIMARY KEY (id)
KEY lookup (anumber, smallstr)
)
As others have said, the size of each row will vary - lets say there's an average of 1kbytes, and a million rows. But if your queries are mostly NOT looking at that big varchar field, then the structure is very inefficient - it still has to be read off the disk each time, even though it never gets to the result set. So you need to read at least a gigabyte of data. But if you split this:
create table example2 (
id int NOT NULL AUTOINCREMENT,
smallstr VARCHAR(20),
anumber mediumint(6) DEFAULT 0
PRIMARY KEY (id)
KEY lookup (anumber, smallstr)
);
create table example2_sub (
ex2_id int NOT NULL,
bigstr (2000)
PRIMARY_KEY (ex2_id)
);
The average row size would drop to around 25 bytes - i.e. 1/40th of that using a consolidated table. OTOH, when you do need to perform a bulk query on example2 and example2_sub it will be slower than the consolidated table (I would expect that it would slow down by something of the order of 30% - but I've not tested it).
(note that you should restrict the size of HTML input fields to the corresponding database attributes wherever possible).
HTH
C.