Att ställa den frågan om "MySQL" är inte till hjälp, eftersom MySQL förvisar lagring till lagringsmotorer och de implementerar lagring på väldigt olika sätt. Det är vettigt att ställa den här frågan för varje enskild lagringsmotor.
I MEMORY-motorn finns inte datatyper med variabel längd. En VARCHAR ändras tyst till en CHAR. I samband med din fråga:Det spelar ingen roll var i en tabelldefinition du placerar din VARCHAR.
I MyISAM-motorn, om en tabell inte har någon data med variabel längd (VARCHAR, VARBINARY eller någon typ av TEXT eller BLOB) är den av den FIXADE varianten av MyISAM, det vill säga poster har en fast bytelängd. Detta kan få prestandaimplikationer, särskilt om data raderas och infogas upprepade gånger (dvs tabellen är inte bara tillägg). Så snart en datatyp med variabel längd är en del av en tabelldefinition blir den den DYNAMISKA varianten av MyISAM, och MyISAM ändrar internt vilken som helst utom den kortaste CHAR-typen internt till VARCHAR. Återigen, position och till och med definition av CHAR/VARCHAR spelar ingen roll.
I InnoDB-motorn lagras data på sidor om 16 KB storlek. En sida har en sidfot med en kontrollsumma och en sidhuvud, med bland annat en sidkatalog. Sidkatalogen innehåller för varje rad förskjutningen av den raden i förhållande till början av sidan. En sida innehåller också ledigt utrymme, och all I/O görs på sidor.
Därför kan InnoDB, så länge det finns ledigt utrymme på en sida, odla VARCHAR på plats och flytta runt rader inuti en sida, utan att medföra ytterligare I/O. Dessutom, eftersom alla rader adresseras som (sidnummer, sidkatalogpost), är rörelsen av en rad inuti en sida lokaliserad till sidan och inte synlig från utsidan.
Det betyder också att även för InnoDB spelar ordningen på kolumner inuti en rad ingen roll.
Det här är de tre lagringsmotorerna som är vanligast med MySQL, och kolumnernas ordning spelar ingen roll för någon av dessa tre. Det kan vara så att det finns andra, mer exotiska lagringsmotorer för vilka detta inte är sant.