How much of a difference does using tinyint
or smallint
(when applicable) instead of just int
do? Or restricting a char
field to the minimum characters needed?
Do these choices affect performance or just allocated space?
How much of a difference does using tinyint
or smallint
(when applicable) instead of just int
do? Or restricting a char
field to the minimum characters needed?
Do these choices affect performance or just allocated space?
Yes it affects performance too.
If the indexes are larger, it takes longer to read them from disk, and less can be cached in memory.
Both, in some cases. But imo, it's more of a question of design than performance and storage considerations. The reason you don't make everything varchar(...)
is because that doesn't accurately reflect what sort of data should be stored there, and it reduces your data's integrity and type-safety.
On an Indexed field with a significantly large table the size of your field can make a large affect on performance. On a nonindexed field its not nearly as important bit it still has to write the extra data.
That said, the downtime of a resize of a large table can be several minutes or several hours even, so don't make them smaller than you'd imagine ever needing.
I've frequently seen these three schema design defects causing problems:
I've never seen a well intentioned (i.e. not just using varchar(255) for all cols) but conservative selection of the wrong data size cause a significant performance problems. By significant, I mean factor of 10. I regularly see algorithmic design flaws (missing indexes, sending too much data over the wire etc.) causing much bigger performance hits.