[Anders Larsson]

Söker efter en bra guide som förklarar hur mySQL fungerar med olika teckenkodningar, Latin1 och UTF8, hur man konfigurerar och konverterar, vad som är bra att tänka på osv.

Något bra länktips?

[martine]

Det finns bara en teckenkodning att rekommendera: utf8. Den räcker för alla teckenbehov nu och i framtiden.

Se till att du sätter teckenkodningen som standard för hela databasen:
CREATE/ALTER DATABASE db_name CHARACTER SET utf8 COLLATE utf8_swedish_ci;

Och att du deklarerar att den skall användas i kommunikationen med MySQL:
SET NAMES utf8;

(Sedan bör du förstås genomgående använda utf-8 på dina websidor)

Läs: http://www.mysql.se/doc/refman/5.1/en/charset.html

[JLE]

Och rekommenderat är även att lägga till följande rad i din mysql konfiggfil:

default-character-set = utf8

[kullervo]

Originally posted by martine@Oct 16 2007, 15:09
Det finns bara en teckenkodning att rekommendera: utf8. Den räcker för alla teckenbehov nu och i framtiden.

Förutom alla undantagen och nackdelarna. För övrigt har inte MySQL fullt stöd för UTF8. Dock står det i manualen att MySQL har stöd för tecken på upp till 3 byte sedan 4.1 men jag har hör att dom bara hade stöd för 2 byte per tecken tidigare.

[martine]

Ursprungligen postat av kullervo

Förutom alla undantagen och nackdelarna. För övrigt har inte MySQL fullt stöd för UTF8. Dock står det i manualen att MySQL har stöd för tecken på upp till 3 byte sedan 4.1 men jag har hör att dom bara hade stöd för 2 byte per tecken tidigare.

Undantag och nackdelar? Här får du nog upplysa oss om vad du syftar på.

Bristande stöd? Så vitt jag vet så stöds utf-8 och ucs-2 fullt ut endast med undantaget att MySQL inte kan returnera ren Unicode (ucs-2) och en sorteringsbugg för turkiska vilket gör att turkiska i med eller utan prick inte sorteras rätt i ucs-2. Men det påverkar ju inte utf-8. MySQL stöder för närvarande inte utf-8-tecken med 4 bytes (RFC 3629) men jag har svårt att se något problem med detta - det har väl knappast några praktiska effekter?

Om det är några brister så är det i tidigare versioner (3:an eller 4:an) men det finns ju ingen anledning att inte köra MySQL 5 som är enormt mycket kapablare än tidigare versioner. Nu är visst 6:an på väg dessutom. Tidigare versioner än 4.1 är verkligen inte att rekommendera.

[SimonP]

Storleken på databasen kan fördubblas om man kör UTF-8 (och har textfält i databasen), använder man Dynamic row format så packas det iofs ihop rätt bra men kör man Fixed row format blir textfält alltid dubbelt så stora med UTF-8. Har man Memory/Heap baserade tabeller kommer det naturligtvis att kräva dubbelt så mkt RAM minne. Har man extremt mkt rader bör man överväga om man behöver UTF8, men för dom flesta är det säkrast att köra UTF-8.

[martine]

Originally posted by SimonP@Oct 17 2007, 12:08
Storleken på databasen kan fördubblas om man kör UTF-8 (och har textfält i databasen), använder man Dynamic row format så packas det iofs ihop rätt bra men kör man Fixed row format blir textfält alltid dubbelt så stora med UTF-8. Har man Memory/Heap baserade tabeller kommer det naturligtvis att kräva dubbelt så mkt RAM minne. Har man extremt mkt rader bör man överväga om man behöver UTF8, men för dom flesta är det säkrast att köra UTF-8.

Om man använder utf-8 så fördubblas inte storleken om man kör med CHAR utan tredubblas – men det går generellt precis lika bra att använda VARCHAR och då blir inte databasen nämnvärt större, några procent på sin höjd. Ytterst marginellt med tanke på skalbarheten vad det gäller möjligheten att använda tecken.

Det kräver alltså inte alls dubbelt så mycket minne med utf-8 utan kanske några procent mer (för svenska och andra europeiska språk). Däremot kräver ucs2 dubbelt så mycket som t.ex. latin1 vilket kan vara en anledning att undvika ucs2.

Fördelen att använda utf-8 (med eventuellt några procent mer kb) är verkligen enorm om man jämför att eventuellt senare bygga om en applikation med konverteringar mellan latin1 och latin2 för visning i utf-8 på websidan t.ex.

[SimonP]

Originally posted by martine@Oct 17 2007, 13:18
Om man använder utf-8 så fördubblas inte storleken om man kör med CHAR utan tredubblas – men det går generellt precis lika bra att använda VARCHAR och då blir inte databasen nämnvärt större, några procent på sin höjd. Ytterst marginellt med tanke på skalbarheten vad det gäller möjligheten att använda tecken.

Det kräver alltså inte alls dubbelt så mycket minne med utf-8 utan kanske några procent mer (för svenska och andra europeiska språk). Däremot kräver ucs2 dubbelt så mycket som t.ex. latin1 vilket kan vara en anledning att undvika ucs2.

Fördelen att använda utf-8 (med eventuellt några procent mer kb) är verkligen enorm om man jämför att eventuellt senare bygga om en applikation med konverteringar mellan latin1 och latin2 för visning i utf-8 på websidan t.ex.

Du har missat vad jag skrev:
"...men kör man Fixed row format blir textfält alltid dubbelt så stora med UTF-8"

Jag har testat med en databas med 400 000 records med 3 fält: varchar(24), binary(16) & int(10)
36 MB med UTF-8, 18 MB med Latin1, index-storleken påverkas dock inte av UTF-8.

[martine]

Originally posted by SimonP@Oct 17 2007, 14:31
Du har missat vad jag skrev:
"...men kör man Fixed row format blir textfält alltid dubbelt så stora med UTF-8"

Jag har testat med en databas med 400 000 records med 3 fält: varchar(24), binary(16) & int(10)
36 MB med UTF-8, 18 MB med Latin1, index-storleken påverkas dock inte av UTF-8.

Okej, jag ger mig på den punkten. Det förbryllar mig ändå att databasen blir dubbelt så stor eftersom uft-8 kräver 3 bytes när den är lagrad som CHAR. Men jag antar att det beror på att du avser hela tabellens storlek (inklusive index).

Vad du i praktiken gör när du sätter "fixed row" är ju att tvinga VARCHAR att bli CHAR eftersom den annars inte kan vara av statisk längd. Frågan är förstås om det verkligen är nödvändigt att ha fast storlek på tabellraderna.

CHAR eller VARCHAR med forced fixed row tar ju alltid upp mer plats än nödvändigt (bortsett från det ovanliga fallet när precis alla strängar är exakt lika långa). Frågan är väl snarare om prestandavinsten av att ha fastlängdssträngar är värda de extra MB som det kostar över huvud taget. Jag använder det sällan eftersom strängarna oftast är av så varierande längd att det skulle kosta otrevligt mycket utrymme i förhållande till prestanda.

[SimonP]

Jag håller på med ett "språkprojekt" med enormt mkt rader, runt 20 miljarder, så jag labbar med olika row formats`, teckentabeller m.m, jag misstänker att Dynamic row format kräver lite mer CPU-kraft medans Fixed kräver mkt mer diskutrymme, får se om jag hittar nån bra lösning. Sen slipper man köra Optimize på fixed row formats, men det är iofs bara viktigt om man raderar rader ofta.

BTW, nån som vet vilka språk i Europa som kräver UTF-8 för att man skall kunna se hela deras alfabet?