MariaDB'de Karakter Seti ve Collation: utf8mb4, Türkçe ve Doğru Ayarlar

Karakter seti ile collation arasındaki fark

Karakter seti bir harf kümesidir; collation o kümenin sıralama ve eşitlik kurallarıdır. Bir karakter setinin birden çok collation'ı olabilir, ama her collation yalnızca tek bir karakter setine aittir. MariaDB bu ilişkiyi adlandırmada da gösterir: collation adı her zaman ait olduğu karakter setinin adıyla başlar. Örneğin latin1_german1_ci yalnızca latin1 için geçerlidir. Her karakter setinin ayrıca bir varsayılan collation'ı vardır; latin1 için bu latin1_swedish_ci'dir.

Aynı harfler farklı dillerde farklı sırada dizilebildiği için collation seçimi yalnızca teknik bir ayrıntı değildir. Belgelerdeki örnekte y harfi varsayılan kurala göre x ile z arasına düşerken Litvanca kurala göre i ile k arasına yerleşir. Almancada telefon rehberi sıralaması ile sözlük sıralaması bile birbirinden ayrılır. Bu yüzden aynı karakter setini kullanan iki tablo, farklı collation'larla aynı sorguya farklı sırada sonuç döndürebilir.

Varsayılan kurallarla yapılan iki basit karşılaştırma, büyük-küçük harf duyarsızlığını gösterir. İlk sorguda A harfi Z'den küçüktür; ikinci sorguda ise A ile a eşit kabul edildiği için "küçüktür" sonucu 0, "eşittir" sonucu 1 döner:

SELECT "A" < "Z";
+-----------+
| "A" < "Z" |
+-----------+
|         1 |
+-----------+

SELECT "A" < "a", "A" = "a";
+-----------+-----------+
| "A" < "a" | "A" = "a" |
+-----------+-----------+
|         0 |         1 |
+-----------+-----------+

Sunucunuzda hangi karakter setlerinin bulunduğunu SHOW CHARACTER SET, hangi collation'ların bulunduğunu SHOW COLLATION ile listeleyebilirsiniz. Her ikisi de LIKE ve WHERE ile süzülebilir. Belgelerdeki örnek çıktıda Türkçe için tasarlanmış tek baytlık latin5 karakter seti de görünür:

SHOW CHARACTER SET LIKE 'latin%';
+---------+-----------------------------+-------------------+--------+
| Charset | Description                 | Default collation | Maxlen |
+---------+-----------------------------+-------------------+--------+
| latin1  | cp1252 West European        | latin1_swedish_ci |      1 |
| latin2  | ISO 8859-2 Central European | latin2_general_ci |      1 |
| latin5  | ISO 8859-9 Turkish          | latin5_turkish_ci |      1 |
| latin7  | ISO 8859-13 Baltic          | latin7_general_ci |      1 |
+---------+-----------------------------+-------------------+--------+

Collation adlarını okumak

Collation adının sonundaki ekler, karşılaştırmanın nasıl davranacağını özetler. Belgelere göre sonda ci varsa karşılaştırma büyük-küçük harfe duyarsızdır, cs varsa duyarlıdır. MariaDB 10.10 ile gelen aksan bayrağı _ai (aksana duyarsız) ve _as (aksana duyarlı) eklerini ekledi; aksana duyarsız bir collation, bir harfin aksanlı ve aksansız biçimlerini sıralama açısından aynı sayar. nopad içeren adlar ise sondaki boşlukları sıradan karakter gibi değerlendirir.

MariaDB 10.10 ile 184 adet UCA 14.0.0 collation eklendi. uca1400_ai_ci gibi karakter seti öneki taşımayan aile adları birden çok Unicode karakter setiyle kullanılabildiği için bilgi şemasında Charset ve Id sütunları NULL görünür. Hangi collation'ın hangi karakter setiyle birleşebildiğini information_schema.COLLATION_CHARACTER_SET_APPLICABILITY tablosu gösterir. MariaDB 11.4.5 ile MySQL 8.0 uyumluluğu için UCA 9.0.0 adları da geldi; bunlar aslında UCA 14.0.0 karşılıklarına bağlanan takma adlardır. Örneğin listede utf8mb4_tr_0900_ai_ci, utf8mb4_uca1400_turkish_nopad_ai_ci'nin takma adı olarak geçer.

utf8, utf8mb3 ve utf8mb4

MariaDB Unicode veriyi birkaç farklı karakter setiyle saklayabilir. Günlük kullanımda karşınıza en çok çıkan üçlü utf8, utf8mb3 ve utf8mb4'tür. utf8mb3 karakter başına bir ile üç bayt kullanır ve ek düzlemdeki karakterleri (emoji gibi) saklayamaz. utf8mb4 aynı kodlamayı kullanır ama bu ek karakterleri dört baytta tutar. Belgelere göre MariaDB 10.6.1'den beri utf8 adı varsayılan olarak utf8mb3'ün takma adıdır; bu davranış old_mode sistem değişkeniyle utf8mb4 anlamına gelecek şekilde değiştirilebilir.

Bu takma ad ilişkisi yüzünden şemalarınızda utf8 yerine her zaman açıkça utf8mb4 yazmanız en güvenli yoldur; böylece sunucu ayarı değişse bile tablonun ne sakladığı açık kalır. Belgelerdeki küçük bir örnek de bu ayrımın neden önemli olduğunu gösterir: N önekiyle yazılan "ulusal" dize sabiti MariaDB'de her zaman utf8 karakter setini alır ve sonuç utf8mb3 çıkar:

SELECT CHARSET(N'a string');
+----------------------+
| CHARSET(N'a string') |
+----------------------+
| utf8mb3              |
+----------------------+

Tam Unicode desteği istiyorsanız N'...' sabitlerine güvenmeyin; sütunlarınızı ve bağlantınızı utf8mb4 ile tanımlayın. Sütun tiplerinin bayt hesabı için MariaDB veri tipleri yazısına da bakabilirsiniz.

Türkçe içerik için collation seçenekleri

Belgelerdeki tam liste Türkçe için birkaç aile içerir: Unicode tarafında utf8mb4_turkish_ci, utf8mb3_turkish_ci, utf16_turkish_ci, utf32_turkish_ci ve ucs2_turkish_ci; UCA 14.0.0 ailesinde uca1400_turkish_ai_ci, uca1400_turkish_ai_cs, uca1400_turkish_as_ci, uca1400_turkish_as_cs ve bunların nopad biçimleri; tek baytlık tarafta ise latin5_turkish_ci. Sunucunuzda gerçekte hangilerinin derlenmiş olduğunu şöyle kontrol edebilirsiniz:

SHOW COLLATION LIKE '%turkish%';
SELECT collation_name, character_set_name, is_default
  FROM information_schema.COLLATIONS
 WHERE collation_name LIKE 'utf8mb4%turkish%';

Varsayılan utf8mb4_uca1400_ai_ci belirli bir dile bağlı olmayan genel ("root") Unicode kurallarını izler ve aksana duyarsızdır. Aksana duyarsız bir collation aksanlı ve aksansız harfleri eşit sayacağı için, Türkçede ayrı harf olarak kabul edilen karakterlerin aramalarda ve ORDER BY sonuçlarında nasıl davrandığını mutlaka kendi verinizle deneyin. Dile özgü turkish collation'lar bu dilin sıralama kurallarını izlemek için vardır; belgeler kuralların ayrıntısını tek tek listelemediğinden, karar vermeden önce tipik kelimelerinizle küçük bir test tablosu kurup karşılaştırmak en sağlıklı yoldur.

Ayar seviyeleri ve miras zinciri

Karakter seti ve collation dört seviyede belirlenebilir: sunucu, veritabanı, tablo ve sütun. Ayrıca istemci ile sunucu arasındaki bağlantının da kendi ayarları vardır. Değerler yukarıdan aşağı akar: collation belirtilmemiş bir sütun tablonun varsayılanına, tablo veritabanının varsayılanına, veritabanı da sunucunun varsayılanına bakar. Karakter setini değiştirip collation belirtmezseniz yeni karakter setinin varsayılan collation'ı kullanılır; yalnızca collation belirtirseniz, her collation tek bir karakter setine ait olduğundan karakter seti kendiliğinden seçilir.

Sunucu düzeyinde character_set_server ve collation_server sistem değişkenleri kullanılır; ikisi de başlangıçta ya da çalışırken SET ile ayarlanabilir. Veritabanı düzeyinde CREATE DATABASE ve ALTER DATABASE, tablo ve sütun düzeyinde CREATE TABLE ve ALTER TABLE isteğe bağlı CHARACTER SET ve COLLATE ifadelerini kabul eder. Belgeler, tablo düzeyindeki ifadenin standart SQL'e MariaDB ve MySQL eklentisi olduğunu, sütun düzeyindeki tanımın ise standart SQL olduğunu belirtir:

CREATE DATABASE blog
  CHARACTER SET = 'utf8mb4'
  COLLATE = 'utf8mb4_turkish_ci';

CREATE TABLE yazarlar (id INT, ad VARCHAR(60))
  CHARACTER SET 'utf8mb4'
  COLLATE 'utf8mb4_turkish_ci';

CREATE TABLE etiketler (
  ad VARCHAR(40) COLLATE 'utf8mb4_turkish_ci',
  kod VARCHAR(20) CHARACTER SET 'ascii');

character_set_database ve collation_database değişkenleri de vardır, ama belgeler bunların yalnızca sunucu tarafından ayarlanması gerektiğini söyler. USE db_name bu iki değişkeni yeni veritabanının değerlerine çeker, buna karşılık collation_connection'a dokunmaz. Sonuçları görmek için SHOW CREATE DATABASE, SHOW CREATE TABLE ya da INFORMATION_SCHEMA.SCHEMATA ve INFORMATION_SCHEMA.COLUMNS tablolarını kullanabilirsiniz. Tablo oluşturma sözdiziminin genel hâli için MariaDB veritabanı ve tablo oluşturma yazısına bakın.

CREATE TABLE t1 (id VARCHAR(24));                                -- veritabanının collation'ını miras alır
CREATE TABLE t2 (id VARCHAR(24)) DEFAULT CHARACTER SET utf8mb4;  -- character_set_collations haritasını kullanır

Belgelerdeki örneğe göre veritabanının varsayılanı utf8mb4_general_ci ise t1 bu collation'ı alır, t2 ise utf8mb4_uca1400_ai_ci olur. İkisini eşitlemek için ya açık bir COLLATE ekleyin ya da haritayı değiştirin.

character_set_collations haritası

MariaDB 11.2 ile gelen character_set_collations değişkeni, her karakter setinin varsayılan collation'ını virgülle ayrılmış bir eşleme listesiyle belirler. MariaDB 11.2 ile 11.5 arasında bu değişken boştu ve her karakter seti derlenmiş varsayılanını kullanıyordu. MariaDB 11.5'ten beri varsayılan değer her Unicode karakter setini bir UCA 14.0.0 collation'ına eşler; yani kimse dokunmamış olsa bile harita etkindir. Değişken açık bir COLLATE verilmeyen her durumda devreye girer: sütun, tablo ve veritabanı collation'ı, CONVERT(expr USING csname), CAST(expr AS CHAR CHARACTER SET csname), karakter seti önekli dize sabitleri ve COLLATE içermeyen bir SET NAMES sonrasındaki @@collation_connection bunlara örnektir.

Dikkat edilecek en önemli ayrıntı şudur: değişkene değer atamak haritanın tamamını değiştirir, mevcut değerle birleştirmez. Yalnızca utf8mb4 girdisini yazarsanız diğer Unicode karakter setleri derlenmiş varsayılanlarına döner. Diğerlerini korumak için hepsini listeleyin:

SELECT @@character_set_collations;

SET GLOBAL character_set_collations =
  'utf8mb3=uca1400_ai_ci,ucs2=uca1400_ai_ci,utf16=uca1400_ai_ci,utf32=uca1400_ai_ci,utf8mb4=utf8mb4_general_ci';

Değişikliği kalıcı yapmak için seçenek dosyasına yazın. SET GLOBAL yalnızca yeni bağlantıları etkiler; açık bağlantılar bağlandıkları andaki oturum değerini korur, bu yüzden uygulamanızı yeniden bağlamadan yeni haritaya güvenmeyin. Seçenek dosyalarının nerede okunduğunu MariaDB my.cnf yapılandırma dosyaları yazısında anlattık.

[mariadbd]
character-set-collations = utf8mb4=utf8mb4_general_ci

Bağlantı karakter seti ve SET NAMES

Sunucuya gönderdiğiniz sorgunun hangi kodlamada yorumlanacağı ve sonuçların size hangi kodlamada döneceği bağlantı değişkenlerine bağlıdır. SET NAMES, character_set_client, character_set_connection ve character_set_results oturum değişkenlerini verilen karakter setine, collation_connection'ı da dolaylı olarak ilgili collation'a ayarlar. Collation ifadesi isteğe bağlıdır; verilmezse ya da DEFAULT yazılırsa karakter setinin varsayılan collation'ı kullanılır. ucs2, utf16, utf16le ve utf32 istemci karakter seti olamayacakları için SET NAMES ile kullanılamaz. Belgelere göre MariaDB 11.8'den beri bu değişkenlerin varsayılanı utf8mb4'tür:

SET NAMES DEFAULT;

SELECT VARIABLE_NAME, SESSION_VALUE
    FROM INFORMATION_SCHEMA.SYSTEM_VARIABLES WHERE
    VARIABLE_NAME LIKE 'character_set_con%' OR
    VARIABLE_NAME LIKE 'character_set_cl%' OR
    VARIABLE_NAME LIKE 'character_set_re%' OR
    VARIABLE_NAME LIKE 'collation_c%';
+--------------------------+-----------------------+
| VARIABLE_NAME            | SESSION_VALUE         |
+--------------------------+-----------------------+
| CHARACTER_SET_RESULTS    | utf8mb4               |
| CHARACTER_SET_CONNECTION | utf8mb4               |
| CHARACTER_SET_CLIENT     | utf8mb4               |
| COLLATION_CONNECTION     | utf8mb4_uca1400_ai_ci |
+--------------------------+-----------------------+

Dize sabitleri bağlantının collation'ını alır, veritabanının collation'ını değil. Sabitler "zorlanabilir" (coercible) kabul edildiği için doğrudan bir sütunla karşılaştırıldığında sütunun collation'ına uyar. Ancak bir view tanımına, bir CASE sonucuna ya da bir saklı yordama gömülü sabitler, oluşturuldukları andaki bağlantı ayarını korur. Belgelere göre saklı bir programdaki sabitlerin karakter setini değiştirmek için programı silip yeniden oluşturmak gerekir. Uygulama tarafında bağlantı kodlamasını nasıl belirleyeceğinizi PHP PDO veritabanı bağlantısı yazısında bulabilirsiniz.

Mevcut tabloları utf8mb4'e dönüştürmek

Eski bir sunucudan gelen latin1 ya da utf8mb3 tablolarını dönüştürmenin iki yolu vardır. ALTER TABLE ... CONVERT TO CHARACTER SET tablonun ve içindeki tüm karakter sütunlarının karakter setini değiştirir; collation verilmezse yeni karakter setinin varsayılanı seçilir. VARCHAR ve TEXT sütunlarında bu komut, sütunun eskisi kadar karakter tutabilmesi için gerekirse veri tipini de büyütür. Belgelerdeki örnekte ASCII bir TEXT sütunu utf8mb4'e dönüştürülünce MEDIUMTEXT olur. Tip değişikliği istemiyorsanız sütunları tek tek MODIFY ile değiştirin:

ALTER TABLE yorumlar
  CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_turkish_ci;

ALTER TABLE yorumlar MODIFY metin TEXT CHARACTER SET utf8mb4;

CONVERT TO CHARACTER SET tabloyu yeniden inşa eder; büyük tablolarda bunun süre ve disk alanı gerektireceğini hesaba katın ve collation'ı açıkça yazın. CONVERT TO CHARACTER SET binary ise CHAR, VARCHAR ve TEXT sütunlarını BINARY, VARBINARY ve BLOB'a çevirir; bu sütunların artık karakter seti olmaz. Bir sütunun karakter setini değiştirirken verinin yeni kodlamaya uyduğundan emin olun; belgeler MariaDB'nin veriyi elinden geldiğince eşleyeceğini, ama dikkat edilmezse veri kaybı olabileceğini belirtir. ALTER işlemlerinin kilit ve algoritma seçenekleri için MariaDB ALTER TABLE yazısına bakın.

Dönüşümden önce ve sonra şemanızın durumunu kaydetmek için belgelerdeki denetim sorgusu çok işe yarar. Geçerli veritabanında, collation'ı veritabanı varsayılanından farklı olan her karakter sütununu listeler; boş sonuç her şeyin uyumlu olduğu anlamına gelir:

SELECT t.TABLE_NAME, t.TABLE_COLLATION,
       c.COLUMN_NAME, c.CHARACTER_SET_NAME, c.COLLATION_NAME
  FROM INFORMATION_SCHEMA.TABLES t
  JOIN INFORMATION_SCHEMA.COLUMNS c
    ON c.TABLE_SCHEMA = t.TABLE_SCHEMA
   AND c.TABLE_NAME   = t.TABLE_NAME
 WHERE t.TABLE_SCHEMA = DATABASE()
   AND t.TABLE_TYPE   = 'BASE TABLE'
   AND c.COLLATION_NAME IS NOT NULL
   AND c.COLLATION_NAME <> @@collation_database
 ORDER BY t.TABLE_NAME, c.ORDINAL_POSITION;

Error 1267: Illegal mix of collations

İki sütunu karşılaştırırken collation'ları farklıysa ve ikisi de aynı zorlanabilirlik düzeyindeyse (örneğin iki IMPLICIT sütun) sunucu hangisini seçeceğine karar veremez ve 1267 hatası döner. İşlemde üç işlenen varsa 1270, daha fazlası ya da bir UNION varsa 1271 kodlu benzer hata gelir. Belgeler, MariaDB 11.8 ve sonrasında yükseltme sonrası oluşturulan yeni tabloların bu hatanın tipik kaynağı olduğunu gösterir: CHARACTER SET utf8mb4 yazılıp COLLATE verilmeyen yeni sütun utf8mb4_uca1400_ai_ci alır, eski tablodaki sütun ise utf8mb4_general_ci'dir:

CREATE TABLE c2 (a VARCHAR(10) CHARACTER SET utf8mb4);
SELECT COUNT(*) FROM c1 JOIN c2 ON c1.a = c2.a;
ERROR 1267 (HY000): Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_uca1400_ai_ci,IMPLICIT) for operation '='

SELECT * FROM c1 WHERE a = b COLLATE utf8mb4_unicode_ci;

Kalıcı çözüm, sütunları aynı collation'a getirmektir (ALTER TABLE ... MODIFY ... COLLATE ...). Tek bir sorgu için ise işlenenlerden birine açık bir COLLATE ekleyebilirsiniz; açık COLLATE sütunun collation'ından önceliklidir. Bir ifadenin collation'ını ve zorlanabilirliğini COLLATION() ve COERCIBILITY() fonksiyonlarıyla görebilirsiniz. Diğer sık hatalar için MariaDB sık hatalar ve çözümleri yazısına bakın.

Eski sürümlerden gelenler için uyumluluk notları

Belgelere göre varsayılan karakter seti ve collation MariaDB 11.6'da, açıkça adı verilen bir Unicode karakter setine uygulanan varsayılan collation ise MariaDB 11.5'te değişti. Bu iki değişikliği içeren ilk uzun süreli destek sürümü MariaDB 11.8 olduğu için, 10.6 ya da 11.4 gibi eski bir LTS'ten yükseltirken ikisi birden devreye girer. Belgelerin saydığı başlıca etkiler şunlardır:

• CHAR(N) sütunlarında depolama belirgin biçimde artar: latin1 için kayıt başına N bayt ayrılırken utf8mb4 için N*4 bayt ayrılır. VARCHAR yalnızca gerçek veriyi sakladığı için bu artış orada pek hissedilmez; belgeler bu yüzden CHAR yerine VARCHAR'a geçmeyi düşünmeyi önerir.
• utf8mb4_uca1400_ai_ci eski sürümlerde bulunmadığı için MariaDB 11.8'den 10.6'ya replikasyon, sunucu eski varsayılanlarla yapılandırılmadıkça başarısız olur.
• Bazı karşılaştırmalar sabit genişlikli latin1_swedish_ci'ye göre daha yavaş olabilir.
• Bir latin1 sütunu her zaman ikili bir dizeyle karşılaştırılabilirken utf8mb4 sütunu her zaman karşılaştırılamaz, çünkü her ikili dize geçerli bir utf8mb4 dizesi değildir. Belgelerin önerdiği geçici çözüm, karşılaştırmadan önce sütunu BINARY'ye dönüştürmektir.

10.6 replikalarıyla uyum ya da eski performans davranışı gerekiyorsa belgeler eski varsayılanlara dönmek için şu ayarları verir. Bu ayarlarla veri dosyaları yeni UCA collation'larını tanımayan eski sürümlerle uyumlu kalır. Sürüm geçişinin bütün adımları için MariaDB sürüm yükseltme ve replikasyon tarafı için MariaDB replikasyon kurulumu yazılarına bakın.

[mariadb]
character-set-server=latin1
collation-server=latin1_swedish_ci
character-set-collations=''

Küçük bir uygulama: Türkçe blog veritabanı

Yeni bir Türkçe blog projesi kurduğunuzu düşünelim. Amaç, istemciden diske kadar her katmanda aynı karakter setini ve aynı collation'ı kullanmak, böylece hem emojili yorumları saklamak hem de 1267 hatasından kaçınmaktır. İlk adım seçenek dosyasıdır. Belgelerdeki UTF-8 örneğinde olduğu gibi default-character-set bir istemci seçeneğidir ve istemci grubuna yazılır; sunucu tarafında character-set-server ve collation-server kullanılır:

[client]
default-character-set = utf8mb4

[mariadbd]
character-set-server = utf8mb4
collation-server = utf8mb4_turkish_ci

İkinci adım, veritabanını ve tabloları collation'ı açıkça belirterek oluşturmaktır; yukarıdaki CREATE DATABASE blog örneği bunu yapar. Tablo tanımlarında yalnızca CHARACTER SET utf8mb4 yazıp COLLATE'i unutursanız haritadan gelen utf8mb4_uca1400_ai_ci devreye girer ve aynı veritabanında iki farklı collation oluşur. Bu yüzden ya tablo düzeyinde hiçbir şey yazmayıp veritabanından miras alın ya da her zaman COLLATE ile birlikte yazın. Üçüncü adımda yukarıdaki denetim sorgusunu çalıştırın; boş sonuç, tüm sütunların veritabanı collation'ıyla uyumlu olduğunu gösterir. Son olarak uygulamanızın bağlantısının da utf8mb4 kullandığını oturum değişkenlerinden kontrol edin. Metin fonksiyonlarının bu ayarlarla nasıl çalıştığını MariaDB string fonksiyonları yazısında görebilirsiniz.

Sık yapılan hatalar

• utf8 yazıp emoji beklemek. utf8 varsayılan olarak utf8mb3'ün takma adıdır ve ek düzlem karakterlerini saklamaz; açıkça utf8mb4 yazın.
• Karakter setini verip collation'ı unutmak. Bu durumda collation veritabanından değil character_set_collations haritasından gelir.
• Haritanın tek bir girdisini atamak. Atama tüm haritayı değiştirir; korumak istediğiniz girdileri de yazın.
• Yalnızca sunucuyu ayarlayıp bağlantıyı unutmak. Sorgular character_set_client ile yorumlanır; istemci farklı bir kodlama kullanıyorsa veri bozuk kaydedilebilir.
• CONVERT TO sonrası tip değişimini fark etmemek. TEXT sütunları daha büyük tiplere dönüşebilir; bunu istemiyorsanız MODIFY kullanın.
• Eski replikaya yeni varsayılanlarla yazmak. 10.6 replikası uca1400 collation'larını tanımaz.

Sık Sorulan Sorular

MariaDB 12.3'te varsayılan karakter seti nedir?

Belgelere göre MariaDB 11.6'dan beri varsayılan karakter seti utf8mb4, varsayılan collation utf8mb4_uca1400_ai_ci'dir; 12.3 bu sürümden sonra geldiği için aynı varsayılanları kullanır. Bazı dağıtım paketleri farklı varsayılanlarla gelebilir, kendi sunucunuzda SHOW VARIABLES ile kontrol edin.

utf8mb4_general_ci ile utf8mb4_uca1400_ai_ci arasında ne fark var?

Belgeler utf8mb4_uca1400_ai_ci'nin ek düzlem karakterlerini doğru işlediğini ve Unicode tablosundaki genişleme ve kısaltmaları desteklediğini, örneğin Almanca "ß" harfini "ss" ile eşit saydığını belirtir. utf8mb4_general_ci ise 11.4 ve öncesinde utf8mb4'ün varsayılanıydı. Aynı sorguda ikisini karıştırmak 1267 hatasına yol açar.

Türkçe için hangi collation'ı seçmeliyim?

Listede utf8mb4_turkish_ci ve uca1400_turkish_* ailesi bulunur. Aksana ve harf büyüklüğüne duyarlılık ihtiyacınıza göre ek seçin ve kararı kendi kelimelerinizle yapacağınız bir sıralama ve arama testiyle verin.

Collation değiştirince index'ler etkilenir mi?

CONVERT TO CHARACTER SET tabloyu yeniden inşa eder, dolayısıyla index'ler de yeniden oluşturulur. Ayrıca farklı collation'lı sütunlar arasındaki birleştirmeler, dönüşüm gerektirdiği için index kullanımını engelleyebilir. Index tasarımı için MariaDB index oluşturma yazısına bakın.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: MariaDB öğrenme rehberi · MariaDB veri tipleri · MariaDB string fonksiyonları · MariaDB FULLTEXT arama · LOAD DATA ve mariadb-import · MariaDB sürüm yükseltme