views:

138

answers:

4

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?

+5  A: 

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.

Mark Byers
A: 

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.

John Feminella
+7  A: 

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.

MindStalker
+2  A: 

I've frequently seen these three schema design defects causing problems:

  1. A varchar(n) field was created with n only big enough for the sample of data that the designer had pulled in, not the global population: fine in unit tests, silent truncations in the real world.
  2. A varchar(n) used where the data is fixed size. This masks data bugs.
  3. A char(n) used for variable length data. This provides performance improvements (by enabling the data to sit in-line in the row on disc, but all the client code (and various stored procs/views etc) need to cope with whitespace padding issues (and often they don't). Whitespace padding can be difficult to track down, because spaces don't show up too well, and various libraries/sql clients suppress them.

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.

phlip
varchar(255) should be exactly as effective as varchar(10) because the size, is just a max size. Mysql only use exactly the number of needed bytes to store the content. This is different from a char where mysql use exactly the given number of bytes.
Martin Tilsted