Mysql: Does field size/display width affect index performance?

Question

CREATE TABLE student(
`id` int(11) auto_increment PRIMARY KEY
`grade` int(11)
)

Let's say I want to add an index on grade column. Does it make a difference if it has a smaller display width, eg, int(4) ?

EDIT:

• By performance here I mean query time.

• Also, not clear whether column display width affects index size. We are concerning a very large table with at least millions of rows. It'd be great if the answer can shed lights on this.

Answer 1

First, display makes no difference in any case--it's just for how the field will be represented in the query responses. An int is still and int using 4 bytes, a bigint is a bigint using 8bytes etc...

From what aspect are you considering 'performance'? Overall request time, memory use needed to keep data and indexes loaded or cached? Disk space?

I'm guessing you're meaning, will it affect how fast the query responds back.

This question however is pretty broad, the real answer is, it depends. Does is your system 64 or 32 bit? How many records are we talking? Is the field part of a much larger composite index, but still a small portion of it?

(NOTE: need to be checked on this claim, like if CHARs are just hashed for indexes) Go from a or CHAR(4) to a CHAR(32) and sure you might find some non-negligible performance hit, but this is not due to complexity, but additional overhead of your OS and architecture dealing with these.

However, I'm going to go out on a limb and suggest, barring changing types (int to varchar) which may change the method for indexing or a massive change in storage size of your index, you'll probably not 'see' any difference. I doubt between different integer types you'd be able to easily show consistent slowdown.

Answer 2

Short answer: (4) means nothing for INT .

Loooong answer:

Column sizes impact the size of rows, which impacts the size of the table, which impacts the speed of queries. But...

If the table is 'small', there will be very little difference in performance.

If the table is bigger than can be cached in RAM, then the difference could be significant -- because you would probably be I/O-bound. In some situations, this is a ten-fold slowdown.

To shrink an INT , which is 4 bytes always , switch to TINYINT UNSIGNED (1 byte, range: 0..255), SMALLINT UNSIGNED (2 bytes, 0..65K), or MEDIUMINT UNSIGNED (3 bytes, 0..16M).

Assuming grade is 0..100, then TINYINT (signed or unsigned) is optimal.

Meanwhile, you could change your change your id .

The only purpose of INT(4) is in conjunction with ZEROFILL , where you want to display 12 as 0012 . That is extremely rare.

Don't use CHAR unless the strings are really fixed length strings . And then it probably should be explicitly declared CHARACTER SET ascii because it is hex, all digits, or a 2-letter country_code (etc). Anyway, utf8 is overkill.

Assuming you are using InnoDB, the 'secondary' INDEX(grade) will implicitly include the PRIMARY KEY(id) . So the size of each index entry is the size of grade plus the size of id plus a bunch of overhead. Assuming normal grades and never more than 65K students, you could use 3 bytes instead of your original 8. But the table is small, so you are unlikely to be I/O-bound. Hence small overhead for 8 instead of 3.