MySQL 5.7'den 8.4'e Yükseltme: Neler Kırılır, Nasıl Geri Dönülür

Paketleri yükselttiniz, systemctl restart mysqld dediniz ve iki ekrandan biriyle karşılaştınız. Ya MySQL hiç açılmadı ve log şunu yazıyor:

[ERROR] [MY-000067] [Server] unknown variable 'query_cache_size=64M'.
[ERROR] [MY-010119] [Server] Aborting

Ya da MySQL açıldı, mysql istemcisiyle bağlanabiliyorsunuz ama uygulama beyaz ekran veriyor ve PHP log'unda şu satır var:

The server requested authentication method unknown to the client [caching_sha2_password]

İkisi de aynı sebepten kaynaklanıyor: MySQL 8, 5.7'nin devamı değil, davranış kuralları birkaç yerde bilinçli olarak değiştirilmiş bir ana sürüm. Yükseltme komutu tek satır, sonuçları ise yapılandırma dosyanızda, kullanıcı tablonuzda, karakter setinizde ve şema nesnelerinizde dağınık halde duruyor.

Bu rehber "MySQL nasıl yükseltilir" sorusunu değil, "yükseltince tam olarak ne kırılır ve bunu nasıl önceden görürüm" sorusunu cevaplıyor. Önce doğru yükseltme yolunu netleştireceğiz, sonra MySQL Shell'in yükseltme denetleyicisiyle sorunları daha eski sürüm ayaktayken tespit edeceğiz. Ardından pratikte gerçekten karşınıza çıkan beş kırılmayı tek tek, belirti-sebep-çözüm sırasıyla ele alacağız. Sonunda da en kritik konuya geleceğiz: 8.x'ten aşağı yerinde geri dönüş desteklenmez. Geri alma planınız, yükseltmeden önce alınmış bir mantıksal yedektir; o yoksa bu işe hiç başlanmaz.

5.7'den 8.4'e Tek Adımda Geçilmez: Doğru Yükseltme Yolu#

MySQL, sürüm atlamayı desteklemez. Bir seriden diğerine geçerken araya giren seriyi atlayamazsınız. Yani hedefiniz 8.4 LTS ise yolunuz şudur:

Doğrudan 5.7'den 8.4'e geçmek desteklenmez. Ayrıca 8.0'a çıkarken 5.7'nin GA sürümlerinden (5.7.9 ve üzeri) geliyor olmanız gerekir, ve her adımda kaynak serinin son minör sürümünde olmak hata düzeltmelerini yanınıza alır.

İki adımı aynı bakım penceresine sıkıştırmayın. 8.0'a çıktıktan sonra sistemi en az birkaç gün gerçek trafikte çalıştırın; 5.7 → 8.0 geçişinde ortaya çıkan sorunlar genellikle ilk saatte değil, ilk raporlama sorgusunda veya ilk gece cron'unda görünür. İki adımı üst üste bindirirseniz sorunun hangi sürümden geldiğini ayırt edemezsiniz.

MySQL 8.0.16'dan itibaren ayrı bir mysql_upgrade komutu yoktur; sunucu, yeni sürümle ilk kez açıldığında sistem tablolarını kendisi dönüştürür. Yani "yükseltme adımını unutmak" diye bir risk kalmadı — ama bunun bedeli şu: sunucuyu bir kez yeni sürümle başlattığınızda dönüşüm yapılmış olur ve veri dizini artık eski sürüme uygun değildir.

Yükseltme Öncesi Tek Zorunlu Adım: Upgrade Checker Çıktısını Okumak#

Aşağıdaki bölümlerde anlatacağım kırılmaların neredeyse tamamını, hâlâ 5.7 ayaktayken tek komutla önceden görebilirsiniz. MySQL Shell'in util.checkForServerUpgrade yardımcı programı, çalışan sunucuya bağlanır ve hedef sürümde sorun çıkaracak her şeyi listeler.

Tek şart: MySQL Shell sürümünüz hedef sürümden düşük olamaz. 8.4'ü hedefliyorsanız 8.4 (veya üzeri) Shell kurun.

# Komut satırı modunda, metin çıktısıyla
mysqlsh -- util check-for-server-upgrade root@localhost:3306 \
  --target-version=8.0.36 --output-format=TEXT

# Bağlantı bilgilerini ayrı ayrı vermek isterseniz
mysqlsh -- util check-for-server-upgrade \
  { --user=root --host=localhost --port=3306 } \
  --target-version=8.0.36 --output-format=JSON

Hedef sürüm numarasını gerçekten kuracağınız sürümle değiştirin; denetleyici kontrollerini bu numaraya göre seçer. İkinci adımdan önce aynı komutu --target-version=8.4.0 ile tekrar çalıştıracaksınız — 8.0'a özgü kontroller ile 8.4'e özgü kontroller aynı değildir.

Çıktı üç ağırlıkta gelir ve aradaki fark pazarlık konusu değildir:

• Errors — yükseltmeyi durdurur ya da yükseltmeden sonra o nesneyi kullanılamaz hale getirir. Hepsi düzeltilmeden ilerlenmez.
• Warnings — davranış değişikliği. Uygulamanız etkileniyor mu, tek tek bakmanız gerekir.
• Notices — bilgilendirme; genellikle sonradan planlanabilir.

Denetleyicinin gerçekten yakaladığı tipik başlıklar şunlardır: yeni ayrılmış kelimelerle çakışan tablo ve kolon adları, utf8mb3 karakter seti kullanan nesneler, kaldırılmış sql_mode bayrakları, sıfır tarih (0000-00-00) değerleri, 64 karakteri aşan yabancı anahtar adları, yerel bölümleme desteği olmayan motorlardaki bölümlenmiş tablolar, mysql şemasındaki isim çakışmaları ve kaldırılmış sistem değişkenleri.

Bu çıktıyı bir dosyaya alıp değişiklik kaydınıza ekleyin. Yükseltme sonrasında "bu hata yükseltmeden mi geldi?" tartışmasını bitiren tek belge budur.

Kırılma 1: Uygulama Bağlanamıyor, caching_sha2_password#

Belirti. MySQL ayakta, sunucudan mysql -u kok -p ile bağlanabiliyorsunuz, ama uygulama bağlanamıyor. İstemci tarafında iki mesajdan biri görünür: The server requested authentication method unknown to the client [caching_sha2_password] ya da Authentication plugin 'caching_sha2_password' cannot be loaded.

Sebep. MySQL 5.7'de varsayılan kimlik doğrulama eklentisi mysql_native_password'dü. 8.0 ile varsayılan caching_sha2_password oldu. 8.4'te ise iş bir adım ileri gitti: mysql_native_password eklentisi artık varsayılan olarak yüklenmiyor; sunucu --mysql-native-password=OFF ile açılıyor. Eklenti ikili dosyası hâlâ duruyor ama açıkça açılmadıkça yok sayılıyor. 9.x serisinde tamamen kaldırıldı.

Burada ince bir ayrım var ve karışıklığın kaynağı da bu: 5.7'den 8.0'a yükseltirken mevcut kullanıcılarınızın eklentisi değişmez, mysql_native_password olarak kalır. Yeni oluşturduğunuz kullanıcılar caching_sha2_password alır. Yani sorun çoğu zaman yükseltmenin ertesi günü değil, birkaç hafta sonra yeni bir uygulama kullanıcısı açtığınızda patlar. 8.4'e geçişte ise eski kullanıcılarınız da tehlikeye girer.

Çözüm. Önce kimin hangi eklentiyi kullandığını görün:

SELECT user, host, plugin FROM mysql.user ORDER BY plugin, user;

Doğru çözüm, istemciyi güncelleyip kullanıcıları modern eklentiye taşımaktır:

ALTER USER 'uygulama'@'10.0.0.%'
  IDENTIFIED WITH caching_sha2_password BY 'yeni-guclu-sifre';
FLUSH PRIVILEGES;

İstemci tarafı hazır değilse (çok eski bir PHP veya libmysqlclient sürümü), 8.4'te eklentiyi geçici olarak açabilirsiniz — ama bunu bir son tarih belirleyerek yapın:

[mysqld]
mysql_native_password=ON
authentication_policy=caching_sha2_password,,

⚠️ default_authentication_plugin değişkenini kullanmayın. 8.0.27'de kullanımdan kaldırıldı ve 8.4'te tamamen silindi; my.cnf'inizde durursa sunucu hiç açılmaz. Yerini authentication_policy aldı.

Son bir tuzak: caching_sha2_password, bir kullanıcının ilk kimlik doğrulamasında ya TLS bağlantısı ya da sunucunun RSA açık anahtarını isteyebilme yeteneği ister. Şifresiz düz bağlantı kuran ve açık anahtar talebini desteklemeyen eski istemciler tam olarak bu noktada takılır. Bağlantının kullanıcı-host eşleşmesinden mi yoksa eklentiden mi kaynaklandığını ayırt etmek için MySQL 1045 Access denied hatası rehberindeki teşhis adımları işinizi görür.

Kırılma 2: MySQL Hiç Açılmıyor, my.cnf'teki Kaldırılmış Değişkenler#

Belirti. systemctl start mysqld başarısız oluyor, servis "activating" durumunda takılıyor ve hata log'unda unknown variable satırı var.

Sebep. MySQL, tanımadığı bir sistem değişkenini yok saymaz — açılmayı reddeder. Yıllar içinde biriktirdiğiniz my.cnf, artık var olmayan ayarlar içeriyor.

En sık rastlananlar şunlar:

Sorgu önbelleği özellikle canınızı sıkabilir, çünkü 5.7 döneminde yazılmış hemen her Türkçe optimizasyon rehberi query_cache_size ayarlamanızı söylüyordu. MySQL 8 bu özelliği kaldırdı; performans için artık InnoDB buffer pool ve uygulama seviyesindeki önbellek katmanı çalışıyor. Yeni dünyada nereye bakmanız gerektiği için MySQL ve MariaDB performans optimizasyonu rehberine göz atın.

Çözüm. Yükseltmeden önce yapılandırmayı kuru çalıştırmayla doğrulayın. Bu komut sunucuyu başlatmaz, sadece seçenekleri okur:

# Yapılandırmayı yedekleyin
cp /etc/my.cnf /root/my.cnf.5.7.yedek

# Seçenekleri doğrula (hatalı değişken varsa burada söyler)
mysqld --defaults-file=/etc/my.cnf --validate-config --verbose

# Hangi dosyaların okunduğunu görün — dahil edilen .cnf parçaları unutulur
mysqld --help --verbose | head -20

/etc/my.cnf.d/ veya /etc/mysql/conf.d/ altındaki dahil edilen dosyaları atlamayın; kaldırılmış değişken çoğu zaman ana dosyada değil, yıllar önce eklenmiş bir parça dosyada durur.

Kırılma 3: utf8mb3 Kolonlar ve Değişen Varsayılan Collation#

Belirti. Yükseltme sorunsuz geçiyor, ama emoji veya bazı özel karakterler kayboluyor; ya da yedek dosyanızı başka bir sunucuya aktarırken Unknown collation hatası alıyorsunuz.

Sebep. MySQL'de utf8, tarihsel olarak gerçek UTF-8 değil, karakter başına en fazla üç bayt tutan utf8mb3'ün takma adıdır. Gerçek UTF-8 karşılığı utf8mb4'tür. MySQL 8 ile utf8mb3 açıkça kullanımdan kaldırılmış sayılıyor ve sunucu varsayılan collation'ı utf8mb4_0900_ai_ci oldu. Yani 5.7'de utf8 yazıp geçtiğiniz kolonlar hâlâ üç baytlık ve yeni sunucunun varsayılanıyla aynı kümede değil.

Çözüm. Önce hangi kolonların etkilendiğini listeleyin:

SELECT table_schema, table_name, column_name,
       character_set_name, collation_name
FROM information_schema.columns
WHERE character_set_name IN ('utf8', 'utf8mb3')
  AND table_schema NOT IN
      ('mysql', 'information_schema', 'performance_schema', 'sys')
ORDER BY table_schema, table_name;

Ardından tabloları dönüştürün. Bu işlem tabloyu yeniden yazar, yani büyük tablolarda uzun sürer ve kilitleme davranışını göz önünde bulundurmanız gerekir:

ALTER TABLE siparisler
  CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

⚠️ utf8mb4_0900_ai_ci yalnızca MySQL 8'de vardır; MariaDB veya 5.7 tarafına aktaracağınız bir yedek üretiyorsanız utf8mb4_unicode_ci daha taşınabilirdir. Bu ayrımın taşıma sırasında nasıl bozulmalara yol açtığı ve zaten bozulmuş veriyle ne yapılacağı ayrı bir konu; veritabanı taşıdım Türkçe karakterler bozuldu rehberi tam olarak bunu anlatıyor.

Bir de dizin sınırı ayrıntısı var: utf8mb4'te karakter başına dört bayt sayıldığı için VARCHAR(255) üzerine kurulmuş bir dizin, eski satır formatlarında uzunluk limitine takılabilir. Denetleyici bunu genellikle önceden raporlar.

Kırılma 4: sql_mode Değerleri ve Yeni Ayrılmış Kelimeler#

Belirti — 1. Eski bir yedeği geri yüklerken import ilk satırlarda duruyor:

ERROR 1231 (42000): Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER'

Sebep. NO_AUTO_CREATE_USER ve birlikte anılan NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, MAXDB, DB2, MSSQL, ORACLE, POSTGRESQL gibi uyumluluk modları MySQL 8'de kaldırıldı. 5.7'de alınmış her mysqldump çıktısı başında bu değeri ayarlayan bir satır taşır.

Çözüm. Yedek dosyasından ilgili değeri temizleyin:

sed -i 's/NO_AUTO_CREATE_USER,//g; s/,NO_AUTO_CREATE_USER//g' yedek.sql
grep -c NO_AUTO_CREATE_USER yedek.sql   # 0 dönmeli

Aynı temizliği my.cnf içindeki sql_mode satırında da yapın.

Belirti — 2. Uygulama sorgularından biri artık sözdizimi hatası veriyor: You have an error in your SQL syntax ... near 'rank'.

Sebep. MySQL 8, pencere fonksiyonlarını getirirken bir dizi yeni ayrılmış kelime tanımladı: RANK, ROW, ROWS, GROUPS, OVER, WINDOW, LEAD, LAG, FIRST_VALUE, LAST_VALUE, NTILE, DENSE_RANK, PERCENT_RANK, CUME_DIST, RECURSIVE, SYSTEM, LATERAL, JSON_TABLE. rank adında bir kolonunuz varsa ve sorguda ters tırnak kullanmıyorsanız sorgu kırılır.

Çözüm. Kolonları yeniden adlandırmak yerine — bu, uygulama kodunda geniş bir değişiklik demektir — sorgularda ters tırnak kullanın:

SELECT id, `rank`, `system` FROM kullanici_puanlari ORDER BY `rank` DESC;

Hangi nesnelerin etkilendiğini denetleyici zaten listeler; listeyi alıp kod tabanınızda o adları aratın.

Bir başka sessiz değişiklik: MySQL 8'de GRANT artık olmayan bir kullanıcıyı örtük olarak oluşturmaz. Kurulum betiklerinizde GRANT ALL ON db.* TO 'u'@'h' IDENTIFIED BY '...' kalıbı varsa, önce CREATE USER çağırmanız gerekir. Kullanıcı ve yetki yönetiminin 8 dünyasındaki güncel hali için MySQL ve MariaDB kullanıcı yönetimi rehberine bakabilirsiniz.

Kırılma 5: Tanımsız DEFINER'lı View, Trigger ve Yordamlar#

Belirti. Bir rapor sayfası açılmıyor ve hata şu: ERROR 1449 (HY000): The user specified as a definer ('eski_kullanici'@'localhost') does not exist.

Sebep. Her view, trigger, stored procedure ve event bir DEFINER kullanıcısıyla kaydedilir. 5.7 tarafında bu kullanıcı silinmiş ya da yedek başka bir sunucudan geldiği için hiç var olmamış olabilir. 5.7 bazı durumlarda bunu tolere ediyordu; 8'e taşındığında nesne kullanılamaz hale gelir.

Çözüm. Önce envanteri çıkarın:

SELECT definer, COUNT(*) AS adet
FROM information_schema.views
WHERE table_schema NOT IN ('sys', 'mysql')
GROUP BY definer;

SELECT definer, trigger_schema, trigger_name
FROM information_schema.triggers;

SELECT definer, routine_schema, routine_name, routine_type
FROM information_schema.routines
WHERE routine_schema NOT IN ('sys', 'mysql');

Eksik kullanıcıyı geri oluşturmak en az müdahaleli yoldur:

CREATE USER 'eski_kullanici'@'localhost' IDENTIFIED BY 'rastgele-uzun-sifre';
GRANT SELECT ON uygulama_db.* TO 'eski_kullanici'@'localhost';

Alternatif olarak yedek dosyasındaki DEFINER yan tümcelerini tamamen kaldırabilirsiniz; bu durumda nesneler geri yükleyen kullanıcıya ait olur:

sed -E 's/DEFINER=`[^`]+`@`[^`]+`//g' yedek.sql > yedek-definersiz.sql

Bu yöntemi kullanacaksanız sonucun ne anlama geldiğini bilin: nesneler artık geri yükleyen hesabın (çoğunlukla root) yetkileriyle çalışır. Çok kiracılı bir sunucuda bu istenmeyen bir yetki genişlemesidir.

Geri Dönüş: 8.x'ten Aşağı İnmek Desteklenmez#

Bu bölüm rehberin en kısa ve en önemli bölümü.

MySQL'de ana seriler arasında yerinde geri dönüş (in-place downgrade) desteklenmez. 8.0 sunucusu 5.7 veri dizinini bir kez açtığında veri sözlüğünü kendi formatına dönüştürür; o dizini tekrar 5.7 ile açamazsınız. Aynı şey 8.4'ten 8.0'a inmek için de geçerlidir. "Paketi geri kur, eski sürüm açılsın" diye bir yol yoktur; deneyen kişi genellikle açılmayan bir sunucu ve dönüştürülmüş bir veri dizini ile kalır.

Dolayısıyla geri alma planınız tek bir şeydir: yükseltmeden önce alınmış, geri yüklenebilirliği test edilmiş mantıksal bir yedek. Fiziksel dosya kopyası değil, mantıksal dump. Sıralama şöyle olmalı:

# 1. Tutarlı, mantıksal yedek (InnoDB tablolar için kilitsiz)
mysqldump --all-databases --single-transaction --routines --triggers \
  --events --set-gtid-purged=OFF -u root -p | gzip > /yedek/tam-5.7-$(date +%F).sql.gz

# 2. Yedeği DOĞRULAYIN — geri yüklenmeyen yedek yedek değildir
gunzip -c /yedek/tam-5.7-2026-08-18.sql.gz | head -5
# Ayrı bir test sunucusuna geri yükleyip satır sayılarını karşılaştırın

# 3. Sanal makine snapshot'ı (yedeğin yerine değil, yanına)

--routines, --triggers ve --events bayraklarını atlamayın; varsayılan mysqldump bunları almaz ve geri dönmek zorunda kaldığınızda saklı yordamlarınız yedekte olmaz. Yedekleme seçeneklerinin tamamı ve otomatik yedek kurulumu için mysqldump ile veritabanı yedekleme rehberine bakın.

Kural nettir: doğrulanmış bir mantıksal yedek yoksa yükseltme başlatılmaz. Snapshot yardımcıdır ama tek başına yeterli değildir; aynı altyapıda durur ve hipervizör tarafındaki bir sorunda ikisini birden kaybedersiniz.

Yükseltme Günü: Uygulama Sırası ve Sonrası Doğrulama#

Hazırlık bittiğinde asıl işlem kısadır. Sıra şöyle:

1. Bakım penceresi ilan edin, uygulamayı bakım moduna alın.
2. Tam mantıksal yedeği alın ve doğrulayın.
3. Sanal makine snapshot'ı alın.
4. InnoDB'yi temiz kapanmaya zorlayın; bu, redo log'un boş kalmasını sağlar ve ana sürüm geçişinde önerilir:

SET GLOBAL innodb_fast_shutdown = 0;

systemctl stop mysqld
tail -20 /var/log/mysqld.log   # "Shutdown completed" satırını görün

5. Paketleri yükseltin ve sunucuyu başlatın. Sunucu sistem tablolarını kendisi dönüştürür; ayrı bir mysql_upgrade çağrısı yoktur.
6. Log'u dönüşüm bitene kadar izleyin.

Sunucu ayağa kalktıktan sonra doğrulama listesi:

# Sürüm ve dönüşüm durumu
mysql -u root -p -e "SELECT VERSION(); SHOW GLOBAL VARIABLES LIKE 'version%';"

# Hata log'unda dönüşüm sırasında ne oldu?
grep -iE 'error|\[Warning\]' /var/log/mysqld.log | tail -40

# Tüm tabloları yeni sürüme göre kontrol et
mysqlcheck --all-databases --check-upgrade -u root -p

# Kimlik doğrulama eklentileri beklediğiniz gibi mi?
mysql -u root -p -e "SELECT user, host, plugin FROM mysql.user;"

Ardından uygulama tarafını doğrulayın: en ağır raporlama sorgunuzu çalıştırın, bir yazma işlemi yapın, cron görevlerinin çıktısını kontrol edin, replikasyon varsa SHOW REPLICA STATUS ile gecikmeye bakın. Yükseltme sonrasında sorgu planları değişebilir; birden yavaşlayan bir sayfa varsa hemen sunucuyu suçlamadan yavaş sorgu günlüğüyle teşhis yapın. WordPress gibi bir uygulamada bağlantı kurulamıyorsa, hatanın kimlik doğrulama eklentisinden mi yoksa yapılandırmadan mı geldiğini veritabanı bağlantı hatası rehberindeki adımlarla ayırın.

Snapshot'ı ve yedeği en az iki hafta saklayın. Yükseltme kaynaklı sorunların bir kısmı ilk gün değil, aylık raporun çalıştığı ilk gece ortaya çıkar.

Sıkça Sorulan Sorular#

MySQL 5.7'den doğrudan 8.4'e geçebilir miyim?#

Hayır. MySQL sürüm atlamayı desteklemez; önce son 8.0 sürümüne, ardından 8.4 LTS'e geçmeniz gerekir. Ayrıca her adımda kaynak serinin son minör sürümünde olmanız önerilir. İki adımı aynı bakım penceresine sıkıştırmayın: 8.0'da birkaç gün gerçek trafikte çalışmadan 8.4'e geçerseniz, çıkan bir sorunun hangi sürümden geldiğini ayırt edemezsiniz.

8.0'a yükselttikten sonra 5.7'ye geri dönebilir miyim?#

Yerinde geri dönüş desteklenmez. 8.0 sunucusu veri dizinini bir kez açtığında veri sözlüğünü dönüştürür ve o dizin artık 5.7 ile açılamaz. Tek geri dönüş yolu, yükseltmeden önce alınmış mantıksal bir yedeği yeniden kurulmuş bir 5.7 sunucusuna geri yüklemektir. Bu yüzden doğrulanmış bir dump olmadan yükseltmeye başlanmamalıdır.

caching_sha2_password hatasını almadan yükseltebilir miyim?#

Evet, ama hazırlık gerekir. Önce mysql.user tablosundan hangi hesapların hangi eklentiyi kullandığını çıkarın, istemci kütüphanelerinizin caching_sha2 desteklediğini doğrulayın ve kullanıcıları ALTER USER ... IDENTIFIED WITH caching_sha2_password ile taşıyın. İstemci güncellenemiyorsa 8.4'te mysql_native_password=ON ile eklentiyi geçici olarak açabilirsiniz, ancak 9.x'te eklenti tamamen kaldırıldığı için bunu kalıcı çözüm saymayın.

Yükseltme denetleyicisini çalıştırmak sunucuya zarar verir mi?#

Hayır. util.checkForServerUpgrade yalnızca okuma yapar; şemayı, veriyi veya yapılandırmayı değiştirmez. Sunucu çalışırken güvenle çalıştırılır ve üretim ortamında koşulması zaten amaçlanmıştır. Tek dikkat edilecek nokta, MySQL Shell sürümünüzün hedef sunucu sürümünden düşük olmamasıdır; aksi halde hedefe özgü kontroller çalışmaz.

my.cnf dosyamı yükseltmeden önce nasıl kontrol edebilirim?#

Yeni sürümün mysqld ikilisiyle --validate-config seçeneğini kullanın; bu, sunucuyu başlatmadan yalnızca seçenekleri okur ve tanınmayan değişkeni raporlar. /etc/my.cnf.d/ veya /etc/mysql/conf.d/ altındaki dahil edilen parça dosyaları da unutmayın; kaldırılmış bir değişken çoğu zaman ana dosyada değil, yıllar önce eklenmiş bir parça dosyada bulunur.

utf8 kolonlarımı utf8mb4'e dönüştürmek zorunda mıyım?#

Yükseltmenin çalışması için zorunlu değil, ama şiddetle önerilir. utf8, MySQL'de üç baytlık utf8mb3'ün takma adıdır ve emoji gibi dört baytlık karakterleri saklayamaz; ayrıca MySQL 8'in varsayılan collation'ı ile aynı kümede olmadığı için birleştirme sorgularında collation çakışmaları görebilirsiniz. Dönüşümü tabloları yeniden yazan bir işlem olarak planlayın ve büyük tablolarda bakım penceresine alın.

Yükseltme sonrası bazı sorgular yavaşladı, sebep ne olabilir?#

MySQL 8'de optimize edici davranışı ve varsayılan ayarların bir kısmı değişti; aynı sorgu farklı bir plan seçebilir. Önce yavaş sorgu günlüğünü açıp gerçekten hangi sorguların etkilendiğini ölçün, ardından EXPLAIN çıktısını 5.7 dönemindeki planla karşılaştırın. Ayrıca yükseltmeden sonra tablo istatistikleri güncel olmayabilir; ilgili tablolarda ANALYZE TABLE çalıştırmak çoğu zaman planı düzeltir.