Not necessarily, no. It depends whether your column is variable width (varchar(n), for example), and if so what values are in the column (whether they take up the whole maximum width of the column). It also depends on what other columns are in the table, the fill factors on your indexes and what INSERT, UPDATE and DELETE activity occurs on the table. The wider your table as a whole is (adding up all of the columns), the fewer rows you can fit on an 8KB page and the more likely you are to have free space on a page.
John
Thanks John. So CHAR/VARCHAR need to be avoided as SQL would keep them fixed and load the memory with empty spaces ?
Not exactly. CHAR or NCHAR fields will always be fixed length and all of the field gets loaded everywhere it goes. VARCHAR or NVARCHAR fields have some overhead bytes, but also mean that what is stored in the row is the overhead plus only the string value, and not any empty spaces to fill out the length of the field. For example, if a field is defined as VARCHAR(255), that means that you have the overhead bytes plus only the characters in the field, which will likely be less than 255 characters. The number of characters can vary from 0 to 255, or you can have a NULL value. CHAR(255) on the other hand, will always have 255 characters stored in the row. That's why you rarely see CHAR fields of any sizable length.
It's super fun when a developer gives you an alter table statement for a large table and you don't realize they used a char(some large value) instead of varchar until after you run it in production :angry: