I seriously doubt that it ever held true for InnoDB. Even for MyISAM (which really can have
FIXED length rows) it was rarely true.
Roughly speaking, this is the order (most overhead first)
- Disk hit(s).
- Locate the record(s).
- Parse the record (split it into columns).
- Apply functions and evaluate expressions.
If the data is bigger (as in
CHAR being padded), the #1 is impacted. The rest pales into insignificance.
Note: There are 4 flavors of InnoDB
CHAR(100) CHARACTER SET utf8mb4 always takes 400 bytes.
DYNAMIC, it takes between 100 and 400 bytes.
COMPRESSED, the padding spaces are highly compressible, but still take some space.
Allegedly, the "fixed" size of a
CHAR (which, is not all that fixed), tends to prevent block splits. But I kinda doubt it.
My Rule of Thumb:
CHAR should almost always be restricted to truly fixed length strings, and most of them are hex or ascii:
country_code CHAR(2) CHARACTER SET ascii
british_postal_code CHAR(6) CHARACTER SET ascii
zip5 CHAR(5) CHARACTER SET ascii
md5 CHAR(32) CHARACTER SET ascii -- UNHEX() into BINARY(16) is tighter
base64 CHAR(?) CHARACTER SET ascii COLLATION ascii_bin -- need case-significance
Note: latin1 works equally well as ascii, the 8.0 default of utf8mb4 does not.
(See also my answer to the first link. It starts "Most of the answers in this thread are 5 years old, written before InnoDB and utf8 were defaults. So, let me start over..")