Merhaba arkadaşlar, bugün sizlere özellikle çok dilli projelerde veya veri taşıma işlemlerinde başımızı ağrıtan, doğru yapılmadığında "soru işareti" veya "karakter bozulması" sorunlarına yol açan bir konuyu, karakter seti ve collation seçimini anlatacağım. Bu ayarlar sadece uyumluluk için değil, aynı zamanda sorgu performansınızı da doğrudan etkiler. Benim sunucularda genelde kullandığım yöntemleri ve dikkat ettiğim noktaları paylaşacağım.
Temel Kavramlar: Charset ve Collation Nedir?
Öncelikle bu iki terimi netleştirelim. Charset (Karakter Seti), veritabanının hangi karakterleri saklayabileceğini belirler. Örneğin, `latin1` batı Avrupa dilleri için yeterliyken, `utf8mb4` Türkçe karakterler, emojiler ve dünyadaki neredeyse tüm yazı sistemlerini destekler.
Collation ise bu karakterlerin nasıl sıralanacağını ve nasıl karşılaştırılacağını belirleyen kurallar bütünüdür. Örneğin, `utf8mb4_general_ci` ile `utf8mb4_unicode_ci` arasında sıralama doğruluğu ve hız açısından farklar vardır. `_ci` eki "case insensitive" yani büyük/küçük harf duyarsız olduğunu gösterir.
Neden UTF8MB4 Kullanmalıyız?
Eski `utf8` tanımı MySQL'de maksimum 3 byte destekler ve 4 byte gerektiren emojileri (
) saklayamaz. `utf8mb4` ise tam 4 byte desteği sunar. Günümüzdeki her yeni proje için varsayılan seçimim kesinlikle `utf8mb4` oluyor. Eski bir veritabanını taşıyorsanız, dönüşüm işlemi planlı yapılmalıdır.
Mevcut bir veritabanınızın karakter setini kontrol etmek için şu sorguyu kullanabilirsiniz:
Collation Seçimi: Performans vs. Doğruluk
Bu kısım çok kritik. Collation seçimi, `ORDER BY` ve `WHERE` ile metin karşılaştırması yapılan sorgularınızın hızını ve sonucun doğruluğunu belirler.
utf8mb4_general_ci: Daha hızlıdır çünkü karşılaştırma kuralları basitleştirilmiştir. Ancak bazı dil kurallarını tam olarak uygulamayabilir (örneğin, bazı dillerde belirli harf eşleşmeleri).
utf8mb4_unicode_ci: Daha doğru ve dil kurallarına uygundur. Unicode kurallarını tam olarak uyguladığı için `general_ci`'ye göre biraz daha yavaş olabilir, ancak modern donanımlarda bu fark çoğu uygulama için hissedilmez düzeydedir.
Benim tavsiyem, performans kaygısı özel bir durum olmadıkça, daha doğru sonuçlar için utf8mb4_unicode_ci kullanmanız yönünde. Eğer sadece İngilizce karakterler kullanıyorsanız, fark neredeyse yok denecek kadar azdır.
Dikkat Edilmesi Gerekenler ve En Sık Yapılan Hatalar
1. Tutarsızlık: En büyük hata, veritabanı, tablo ve sütun seviyelerinde farklı charset/collation kullanmaktır. Bu, JOIN sorgularında performans düşüklüğüne ve beklenmeyen hatalara yol açar. Mümkünse her seviyede aynı değeri kullanın.
2. Bağlantı Karakter Seti: Veritabanı `utf8mb4` olsa bile, uygulamanızdan bağlantı kurarken karakter seti belirtmezseniz sorun yaşayabilirsiniz. Bağlantı dizesine `charset=utf8mb4` parametresini eklemeyi unutmayın.
3. Sunucu Varsayılanı: MariaDB/MySQL sunucu geneli varsayılanını değiştirmek iyi bir fikirdir. /etc/mysql/my.cnf veya /etc/my.cnf.d/server.cnf dosyasında `[mysqld]` bölümüne aşağıdakileri ekleyebilirsiniz:
Değişiklikten sonra servisi yeniden başlatmayı unutmayın: `sudo systemctl restart mysql`
4. Mevcut Veritabanını Dönüştürme: Büyük bir veritabanını dönüştürmeden önce MUTLAKA yedek alın. Her tablo için ayrı ayrı `ALTER TABLE` komutu çalıştırmanız gerekebilir ve bu işlem, tablo boyutuna bağlı olarak uzun sürebilir.
Sonuç ve Öneriler
Özetlemek gerekirse:
Yeni Proje: Tercihiniz daima `utf8mb4` charset ve `utf8mb4_unicode_ci` collation olsun.
Mevcut Proje: Tutarlılığı sağlayın ve mümkünse `utf8mb4_unicode_ci`'ye geçiş planı yapın.
Performans: Collation farkı, büyük veri ve yoğun metin sorguları dışında genellikle kritik değildir. Önce doğru sonuç, sonra performans optimizasyonu gelir.
Siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? Farklı collation'lar üzerinde performans testleriniz oldu mu? Yaşadığınız ilginç karakter sorunları varsa paylaşalım. Sorularınız için çekinmeden aşağıya yazın, yardımcı olmaya çalışayım.
Temel Kavramlar: Charset ve Collation Nedir?Öncelikle bu iki terimi netleştirelim. Charset (Karakter Seti), veritabanının hangi karakterleri saklayabileceğini belirler. Örneğin, `latin1` batı Avrupa dilleri için yeterliyken, `utf8mb4` Türkçe karakterler, emojiler ve dünyadaki neredeyse tüm yazı sistemlerini destekler.
Collation ise bu karakterlerin nasıl sıralanacağını ve nasıl karşılaştırılacağını belirleyen kurallar bütünüdür. Örneğin, `utf8mb4_general_ci` ile `utf8mb4_unicode_ci` arasında sıralama doğruluğu ve hız açısından farklar vardır. `_ci` eki "case insensitive" yani büyük/küçük harf duyarsız olduğunu gösterir.
Neden UTF8MB4 Kullanmalıyız?Eski `utf8` tanımı MySQL'de maksimum 3 byte destekler ve 4 byte gerektiren emojileri (
) saklayamaz. `utf8mb4` ise tam 4 byte desteği sunar. Günümüzdeki her yeni proje için varsayılan seçimim kesinlikle `utf8mb4` oluyor. Eski bir veritabanını taşıyorsanız, dönüşüm işlemi planlı yapılmalıdır.Mevcut bir veritabanınızın karakter setini kontrol etmek için şu sorguyu kullanabilirsiniz:
SQL:
SELECT default_character_set_name, default_collation_name
FROM information_schema.SCHEMATA
WHERE schema_name = 'veritabani_adiniz';Bu kısım çok kritik. Collation seçimi, `ORDER BY` ve `WHERE` ile metin karşılaştırması yapılan sorgularınızın hızını ve sonucun doğruluğunu belirler.
utf8mb4_general_ci: Daha hızlıdır çünkü karşılaştırma kuralları basitleştirilmiştir. Ancak bazı dil kurallarını tam olarak uygulamayabilir (örneğin, bazı dillerde belirli harf eşleşmeleri).
utf8mb4_unicode_ci: Daha doğru ve dil kurallarına uygundur. Unicode kurallarını tam olarak uyguladığı için `general_ci`'ye göre biraz daha yavaş olabilir, ancak modern donanımlarda bu fark çoğu uygulama için hissedilmez düzeydedir.
Benim tavsiyem, performans kaygısı özel bir durum olmadıkça, daha doğru sonuçlar için utf8mb4_unicode_ci kullanmanız yönünde. Eğer sadece İngilizce karakterler kullanıyorsanız, fark neredeyse yok denecek kadar azdır.
Dikkat Edilmesi Gerekenler ve En Sık Yapılan Hatalar1. Tutarsızlık: En büyük hata, veritabanı, tablo ve sütun seviyelerinde farklı charset/collation kullanmaktır. Bu, JOIN sorgularında performans düşüklüğüne ve beklenmeyen hatalara yol açar. Mümkünse her seviyede aynı değeri kullanın.
2. Bağlantı Karakter Seti: Veritabanı `utf8mb4` olsa bile, uygulamanızdan bağlantı kurarken karakter seti belirtmezseniz sorun yaşayabilirsiniz. Bağlantı dizesine `charset=utf8mb4` parametresini eklemeyi unutmayın.
3. Sunucu Varsayılanı: MariaDB/MySQL sunucu geneli varsayılanını değiştirmek iyi bir fikirdir. /etc/mysql/my.cnf veya /etc/my.cnf.d/server.cnf dosyasında `[mysqld]` bölümüne aşağıdakileri ekleyebilirsiniz:
INI:
[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ciDeğişiklikten sonra servisi yeniden başlatmayı unutmayın: `sudo systemctl restart mysql`
4. Mevcut Veritabanını Dönüştürme: Büyük bir veritabanını dönüştürmeden önce MUTLAKA yedek alın. Her tablo için ayrı ayrı `ALTER TABLE` komutu çalıştırmanız gerekebilir ve bu işlem, tablo boyutuna bağlı olarak uzun sürebilir.
Sonuç ve ÖnerilerÖzetlemek gerekirse:
Yeni Proje: Tercihiniz daima `utf8mb4` charset ve `utf8mb4_unicode_ci` collation olsun.
Mevcut Proje: Tutarlılığı sağlayın ve mümkünse `utf8mb4_unicode_ci`'ye geçiş planı yapın.
Performans: Collation farkı, büyük veri ve yoğun metin sorguları dışında genellikle kritik değildir. Önce doğru sonuç, sonra performans optimizasyonu gelir.
Siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? Farklı collation'lar üzerinde performans testleriniz oldu mu? Yaşadığınız ilginç karakter sorunları varsa paylaşalım. Sorularınız için çekinmeden aşağıya yazın, yardımcı olmaya çalışayım.