Unknown Collation utf8mb4_0900_ai_ci Hatası Nasıl Çözülür?

Bir sunucudan aldığınız SQL yedeği diğerinde Unknown collation: 'utf8mb4_0900_ai_ci' mesajıyla duruyorsa dosya mutlaka bozuk değildir. Hedef sunucu, dökümde kullanılan karşılaştırma kuralını tanımıyor olabilir. phpMyAdmin yalnızca hatayı gösteren arayüzdür; dosyanın yükleme limitini artırmak bu hatayı çözmez.

Buradaki kritik ayrım şudur: karakter kümesi hangi karakterlerin saklanabildiğini, collation ise metinlerin nasıl karşılaştırılıp sıralandığını belirler. Bir collation adını başka bir adla değiştirmek, yalnızca yazım düzeltmesi değildir. Kullanıcı adlarının eşit sayılması, arama davranışı ve UNIQUE indeksler de değişebilir.

Önce gerçek sunucu desteğini sorgulayın

Kaynak ve hedefte aşağıdaki sorguları ayrı ayrı çalıştırın. Panelin veya istemcinin sürümü yerine veritabanı sunucusunun sürümünü kaydedin. MySQL ile MariaDB aynı sürüm numaralandırmasını kullanmaz; yalnızca ana sürüme bakarak uyumluluk kararı vermeyin.

SELECT VERSION(), @@version_comment;
SHOW COLLATION WHERE Collation = 'utf8mb4_0900_ai_ci';
SHOW COLLATION WHERE Collation = 'utf8mb4_unicode_ci';

İlk collation sorgusu hedefte boş dönüyorsa o ad desteklenmiyordur. Bir satır dönmesi ise bütün MySQL dökümünün koşulsuz uyumlu olduğunu kanıtlamaz; diğer DDL seçeneklerini de sınamak gerekir. MariaDB sürümleri arasında destek ve takma ad davranışı değişebildiğinden, “MariaDB bu adı hiçbir zaman tanımaz” gibi genellemeler yapmayın.

Hata mesajındaki tam adı dosyada arayın. Tablo sonundaki varsayılan collation dışında tek tek sütunlarda, veritabanı tanımında veya ifadelerde de geçebilir. Hedefte veritabanının varsayılanını değiştirmeniz, CREATE TABLE içinde açıkça yazan başka bir değeri geçersiz kılmaz.

Bağlantı karakter kümesi bunu neden düzeltmez?

SET NAMES utf8mb4 veya istemcide --default-character-set=utf8mb4, bağlantının veri alışverişiyle ilgilidir. Hedefin bilmediği bir COLLATE adını sunucuya öğretmez. UTF-8 dosyayı başka kodlamayla kaydetmek de bu aşamada gereksizdir ve içerikte gerçek karakter bozulmasına yol açabilir.

Yedek bir test tablosunun CREATE komutunda duruyorsa önce şema uyumluluğunu çözün. Veri geldikten sonra Türkçe harfler bozuk görünüyorsa bu ayrı bir katmandır; utf8mb4 ve bağlantı teşhisi üzerinden ilerleyin. İki sorunu aynı işlemde topluca düzeltmeye çalışmak hangi değişikliğin neyi etkilediğini belirsizleştirir.

Uyumlu hedef mi, dönüştürülmüş şema mı?

Uygulama kaynak sunucunun karşılaştırma davranışına dayanıyorsa, aynı davranışı destekleyen bakımlı bir hedef sürüm kullanmak daha az dönüşüm gerektirebilir. Bu, üretim sunucusunu hemen yükseltmek anlamına gelmez. Önce uygulama, sürücü ve yedekleme araçlarını test ortamında doğrulamak gerekir.

Hedef değiştirilemiyorsa desteklenen alternatiflerden birini bilinçli seçin. utf8mb4_unicode_ci sık karşılaşılan bir adaydır; ancak utf8mb4_0900_ai_ci ile birebir eşdeğer kabul edilmemelidir. Türkçe sıralama ve I/ı/İ/i davranışı uygulamanız için önemliyse temsilî kayıtlarla ayrıca test edin. Alternatifin adında utf8mb4 bulunması, bütün dil ve boşluk kurallarının aynı olduğu anlamına gelmez.

Boşluk farkı bile UNIQUE çakışması üretebilir

Aşağıdaki deney, iki collation'ın da bulunduğu MySQL sunucusunda çalıştırılır. MySQL 8.4'te ilk karşılaştırma 0, ikincisi 1 verir. Birincisi sondaki boşluğu ayırt ederken ikinci kural bu karşılaştırmada ayırt etmez.

SELECT
  (_utf8mb4'a' COLLATE utf8mb4_0900_ai_ci =
   _utf8mb4'a ' COLLATE utf8mb4_0900_ai_ci) AS yeni_kural,
  (_utf8mb4'a' COLLATE utf8mb4_unicode_ci =
   _utf8mb4'a ' COLLATE utf8mb4_unicode_ci) AS eski_kural;

Kaynakta farklı kabul edilen iki etiket hedefte eşit sayılırsa, benzersiz indeks oluşturulurken aktarım durabilir. Sadece metinlerin ekranda doğru görünmesini kontrol etmek bu riski yakalamaz. Kullanıcı adı, slug, e-posta veya ürün kodu gibi benzersiz metin alanlarını özellikle inceleyin.

Aşağıdaki sorgudaki aktarim_kontrol, ayrı test alanında oluşturulmuş ve aday değerleri UNIQUE kısıtı olmadan tutan örnek bir tablodur. etiket sütununun karakter kümesi utf8mb4 olmalıdır. Amaç birleştirme yapmak değil, seçilen karşılaştırma kuralının eşit gördüğü grupları bulmaktır.

SELECT etiket COLLATE utf8mb4_unicode_ci AS aday, COUNT(*) AS adet
FROM aktarim_kontrol
GROUP BY etiket COLLATE utf8mb4_unicode_ci
HAVING COUNT(*) > 1;

Döküm üzerinde kontrollü değişiklik

1. Orijinal SQL dosyasını koruyun; dönüşümü ayrı bir kopyada hazırlayın.
2. Mümkünse şema ve veriyi ayrı dışa aktarın. Değiştirilecek tablo ve sütun tanımlarını listeleyin.
3. Yalnızca ilgili DDL tanımlarındaki collation seçimlerini düzenleyin. Bütün dosyada körlemesine metin değiştirmek, içerik alanlarındaki aynı kelimeleri de değiştirebilir.
4. Boş ve kısıtlı yetkili test alanına aktarın. UNIQUE indeksleri kaldırarak hatayı gizlemeyin.
5. Sıralama, eşitlik, benzersizlik ve uygulama aramalarını kaynaktaki beklenen davranışla karşılaştırın.

Dönüşüm kaydınızda eski değer, yeni değer ve etkilenen sütunlar bulunsun. Böylece sonraki yedekte aynı hata tekrarlandığında hangi uyarlamanın neden yapıldığını görebilirsiniz. Test sırasında 1062 oluşursa bunu kayıt çakışması olarak ayrı inceleyin; collation dönüşümünü tamamlanmış sayıp hatalı satırları atlamayın.

Teknik başvuru: MySQL karşılaştırma kurallarının etkisi ve MariaDB desteklenen karakter kümeleri ve collation listesi.