Enkelt sätt för ett litet företag:dumpa din databas till SQL och lägg till den i ditt arkiv. Sedan varje gång du ändrar något, lägg till ändringarna i dumpfilen.
Du kan sedan använda diff för att se ändringar mellan versioner, för att inte tala om kommentarer som förklarar dina ändringar. Detta kommer också att göra dig praktiskt taget immun mot MySQL-uppgraderingar.
Den enda nackdelen jag har sett med detta är att du måste komma ihåg att manuellt lägga till SQL till din dumpfil. Du kan träna dig själv att alltid komma ihåg, men var försiktig om du arbetar med andra. Att missa en uppdatering kan vara jobbigt senare.
Detta kan mildras genom att skapa ett utarbetat manus för att göra det åt dig när du skickar in till subversion, men det är lite mycket för en enmansshow.
Redigera: Under året som har gått sedan detta svar har jag varit tvungen att implementera ett versionsschema för MySQL för ett litet team. Att manuellt lägga till varje ändring sågs som en besvärlig lösning, ungefär som det nämndes i kommentarerna, så vi gick med att dumpa databasen och lägga till den filen i versionskontrollen.
Vad vi upptäckte var att testdata hamnade på soptippen och gjorde det ganska svårt att ta reda på vad som hade förändrats. Detta kunde lösas genom att endast dumpa schemat, men detta var omöjligt för våra projekt eftersom våra applikationer var beroende av viss data i databasen för att fungera. Så småningom återgick vi till att manuellt lägga till ändringar i databasdumpen.
Detta var inte bara den enklaste lösningen, utan det löste också vissa problem som vissa versioner av MySQL har med export/import. Normalt skulle vi behöva dumpa utvecklingsdatabasen, ta bort eventuella testdata, logga poster, etc, ta bort/ändra vissa namn där så är tillämpligt och först då kunna skapa produktionsdatabasen. Genom att manuellt lägga till ändringar kunde vi kontrollera exakt vad som skulle hamna i produktionen, lite i taget, så att allt i slutändan var klart och att flytta till produktionsmiljön gick så smärtfritt som möjligt.