Büyük SQL Dosyası phpMyAdmin'e Yüklenmiyor: Limit Aşmanın 5 Yolu

Elinizde 480 MB'lık bir yedek.sql var, phpMyAdmin'in İçe Aktar sekmesini açıyorsunuz ve dosya seçme alanının hemen altında şu yazıyor: (Maksimum boyut: 50 MiB). Dosyayı yine de seçip Başlat'a basıyorsunuz, tarayıcı bir süre bekliyor ve boş bir sayfa ya da "You probably tried to upload a file that is too large" mesajıyla dönüyorsunuz. Veritabanı hâlâ boş.

Bu noktada çoğu rehber tek bir çözüme odaklanır — genellikle "php.ini içindeki upload_max_filesize değerini artırın". Bu bazen işe yarar, ama paylaşımlı hostinglerin önemli bir kısmında phpMyAdmin kullanıcının kendi PHP ayarlarını hiç okumaz; o durumda saatlerinizi doğru dosyayı düzenlemeye çalışarak harcarsınız. Üstelik limit aşıldıktan sonra karşınıza çıkan ikinci dalga hatalar (max_allowed_packet, zaman aşımı, bellek) tamamen farklı katmanlardan gelir ve aynı ilaçla geçmez.

Bu yazıda önce hata mesajınızın hangi duvarı gösterdiğini belirleyeceğiz, sonra beş yöntemi kolaydan sağlama doğru sırayla uygulayacağız: PHP limitlerini yükseltme, dosyayı sıkıştırıp yükleme, SSH ile doğrudan import, phpMyAdmin'e sunucudaki dizinden okutma ve son çare olarak dosyayı bölme. Her yöntemin nerede çalıştığını ve nerede çalışmadığını da açıkça yazacağım.

Önce Hangi Duvara Çarptığınızı Belirleyin#

Aynı görünen "yüklenmedi" durumunun arkasında en az beş farklı sınır var ve her biri farklı bir bileşene ait:

Ekrandaki üst sınırı doğrulamak için phpMyAdmin'in ana sayfasındaki Sunucu Değişkenleri bölümüne değil, İçe Aktar ekranındaki parantez içi değere bakın. Bu değer upload_max_filesize ile post_max_size arasındaki küçük olandır — birini artırıp diğerini unutmak, ayarı hiç değiştirmemekle aynı sonucu verir.

Mevcut değerleri kesin olarak görmek için sitenizin kök dizinine geçici bir dosya koyabilirsiniz:

<?php
foreach (['upload_max_filesize','post_max_size','memory_limit',
          'max_execution_time','max_input_time'] as $ayar) {
    echo $ayar . ' = ' . ini_get($ayar) . PHP_EOL;
}

Bu dosyayı test ettikten sonra mutlaka silin; sunucu yapılandırmasını dışarıya açık bırakmanın gereği yok. SSH erişiminiz varsa aynı bilgiyi tek satırda alırsınız:

php -i | grep -E 'upload_max_filesize|post_max_size|memory_limit|max_execution_time'

Burada kritik bir ayrım var: bu çıktı sitenizin PHP ayarlarını gösterir. cPanel/DirectAdmin gibi panellerde phpMyAdmin panelin kendi dizininde, ayrı bir PHP havuzunda çalışır. Yani sitenizin limitini 512 MB yapmanız phpMyAdmin'in limitini değiştirmez. Aşağıdaki ilk yöntem tam olarak bu yüzden bazen sonuç vermez.

Yol 1: PHP Limitlerini Yükseltmek#

Kendi sunucunuz (VDS/VPS) varsa ya da panel size PHP ayarlarını değiştirme yetkisi veriyorsa en doğrudan yol budur. Hedef değerler, dosyanızın sıkıştırılmamış boyutunun rahatça üzerinde olmalı:

upload_max_filesize = 512M
post_max_size = 512M
memory_limit = 512M
max_execution_time = 600
max_input_time = 600

post_max_size her zaman upload_max_filesize değerine eşit veya ondan büyük olmalıdır; aksi halde PHP dosyayı sessizce reddeder. memory_limit için de aynı mantık geçerlidir, çünkü phpMyAdmin dosyayı işlerken bir kısmını bellekte tutar.

Değişikliğin nereye yazılacağı kurulumunuza göre değişir:

Nginx kullanıyorsanız PHP tarafını hallettikten sonra bir sınır daha var. Nginx istek gövdesini varsayılan olarak 1 MB'la sınırlar ve aşıldığında PHP'ye hiç ulaştırmadan 413 döner:

server {
    client_max_body_size 512M;
    client_body_timeout  600s;
}

Bu hatayı ayrıntılı olarak 413 Request Entity Too Large hatası yazısında ele aldık. PHP tarafındaki değerlerin tek tek ne işe yaradığını görmek isterseniz php.ini ayarları ve upload_max_filesize yazıları başvuru niteliğinde.

Yol 2: Dosyayı Sıkıştırıp Yüklemek#

Bu, en az bilinen ve en hızlı kazanç sağlayan yöntem. phpMyAdmin sıkıştırılmış SQL dosyalarını doğrudan kabul eder ve açma işlemini sunucuda kendisi yapar; yani limitle karşılaştırılan boyut, sıkıştırılmış boyuttur.

SQL dump'ları düz metin olduğu ve içinde çok fazla tekrar bulunduğu için sıkıştırma oranı olağanüstüdür. Pratikte gördüğümüz aralık:

Yani 50 MB'lık bir limit, sıkıştırma sayesinde pratikte 400 MB'lık bir dump'ı taşıyabilir hâle gelir. Yedeği zaten sıkıştırılmış almak en verimlisidir:

mysqldump -u kullanici -p --single-transaction veritabani | gzip > yedek.sql.gz

Elinizdeki dosya sıkıştırılmamışsa yerelde sıkıştırın:

gzip -9 yedek.sql          # yedek.sql.gz üretir, orijinali siler
gzip -9 -k yedek.sql       # orijinali korur

Windows'ta 7-Zip ile .zip veya .gz üretebilirsiniz. phpMyAdmin .gz, .bz2 ve .zip uzantılarını tanır; hangisinin çalışacağı sunucudaki PHP eklentilerine (zlib, bz2, zip) bağlıdır. Üçü arasında en güvenli seçim .gz, çünkü zlib neredeyse her kurulumda etkindir.

İki noktaya dikkat: dosya adı yedek.sql.gz biçiminde olmalı, yani sıkıştırmadan önceki .sql uzantısı korunmalı. Ve .zip arşivinin içinde tek bir SQL dosyası bulunmalı; birden fazla dosya içeren arşivi phpMyAdmin işlemez. Yedekleme tarafının tamamı için mysqldump ile veritabanı yedekleme yazısına bakabilirsiniz.

Yol 3: SSH Varsa En Sağlam Yöntem#

SSH erişiminiz varsa phpMyAdmin'i tamamen devre dışı bırakın. mysql istemcisi dosyayı akış hâlinde okur; PHP'nin yükleme limiti, bellek sınırı ve web sunucusunun zaman aşımı denklemden çıkar. Boyut ne olursa olsun çalışır.

Önce dosyayı sunucuya taşıyın:

scp yedek.sql.gz [email protected]:/home/kullanici/

Sonra hedef veritabanını oluşturup içeri alın:

mysql -u kullanici -p -e "CREATE DATABASE yeni_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

# Sıkıştırılmış dosyayı açmadan doğrudan aktarma
zcat yedek.sql.gz | mysql -u kullanici -p --default-character-set=utf8mb4 yeni_db

# Sıkıştırılmamış dosya için
mysql -u kullanici -p --default-character-set=utf8mb4 yeni_db < yedek.sql

--default-character-set=utf8mb4 parametresini atlamayın. Bunu unutmak, taşımadan sonra Türkçe karakterlerin bozuk çıkmasının en yaygın sebeplerinden biridir; belirtilerini ve onarımını WordPress Türkçe karakter sorunu yazısında ayrıntılı işledik.

Büyük dosyalarda ekranda hiçbir şey olmaması insanı tedirgin eder. pv kuruluysa ilerlemeyi canlı izleyebilirsiniz:

pv yedek.sql | mysql -u kullanici -p yeni_db

SSH oturumu koparsa import da yarıda kalır. Uzun süren işlemleri screen veya tmux içinde başlatmak bu riski ortadan kaldırır:

screen -S import
zcat yedek.sql.gz | mysql -u kullanici -p yeni_db
# Ctrl+A ardından D ile ayrılın; screen -r import ile geri dönün

cPanel'de SSH'ı nasıl etkinleştireceğinizi ve terminale nereden ulaşacağınızı cPanel SSH erişimi ve terminal yazısında bulabilirsiniz. Paylaşımlı paketlerde SSH kapalıysa doğrudan destek talebiyle açtırmak, bir sonraki yöntemlerle uğraşmaktan çoğu zaman daha hızlıdır.

Yol 4: phpMyAdmin'e Sunucudaki Dizinden Okutmak#

SSH yok ama FTP var mı? O zaman dosyayı tarayıcıdan yüklemek yerine FTP ile sunucuya koyup phpMyAdmin'e "şu dizindeki dosyayı oku" diyebilirsiniz. Bu yöntemde HTTP yükleme adımı hiç yaşanmadığı için upload_max_filesize sınırı devreye girmez.

phpMyAdmin'in yapılandırma dosyasında (config.inc.php) şu satır tanımlıysa özellik açıktır:

$cfg['UploadDir'] = '/home/kullanici/pma_upload';

Bu tanım varsa, İçe Aktar ekranında "Dosya seç" alanının yanında "Sunucudaki yükleme dizininden seç" başlıklı ikinci bir seçenek ve dosya listesi belirir. Yapmanız gerekenler:

1. FTP veya cPanel Dosya Yöneticisi ile belirtilen dizini oluşturun.
2. yedek.sql ya da yedek.sql.gz dosyasını bu dizine yükleyin.
3. phpMyAdmin → veritabanını seçin → İçe Aktar.
4. Dosya seçme alanının altındaki açılır listeden dosyayı seçin ve Başlat'a basın.

Bazı hosting sağlayıcıları bu dizini varsayılan olarak tanımlar ama duyurmaz — İçe Aktar ekranınızda böyle bir açılır liste görüyorsanız özellik zaten aktiftir. Görmüyorsanız ve config.inc.php dosyasına erişiminiz yoksa (paylaşımlı hostingde genellikle yoktur), sağlayıcıdan UploadDir tanımlanmasını istemek makul bir taleptir.

Bu yöntem yükleme limitini aşar ama zaman aşımını aşmaz. Dosya sunucuda dursa bile phpMyAdmin onu PHP içinde işler; çok büyük dump'larda script yine kesilebilir. Kesilme durumunda phpMyAdmin genellikle "kaldığı yerden devam" seçeneği sunar: yeniden yüklerken "İçe aktarmaya şu satırdan başla" alanına en son işlenen satır numarasını yazarsınız. Bu, tek bir dosyayı birkaç turda bitirmenin resmî yoludur.

Yol 5: Dosyayı Parçalara Bölmek#

Diğer dört yol da kapalıysa geriye bölme kalır. Ama burada çok yapılan bir hata var: dump dosyasını split -b 20M gibi boyuta göre kesmek. Bu, bir SQL ifadesini tam ortasından ikiye böler; ortaya çıkan parçaların hiçbiri tek başına geçerli SQL değildir ve import ederken sözdizimi hatası alırsınız.

Doğru yaklaşım, dosyayı ifade sınırlarında bölmektir. Bunun en güvenli yolu, yedeği baştan tablo tablo almaktır:

# Önce yalnızca şema (tüm CREATE TABLE ifadeleri)
mysqldump -u kullanici -p --no-data veritabani > 00-sema.sql

# Sonra her tablo için ayrı veri dosyası
for t in urunler siparisler musteriler yorumlar; do
  mysqldump -u kullanici -p --no-create-info veritabani "$t" > "10-$t.sql"
done

Dosyaları sırayla (00-sema.sql en başta) phpMyAdmin'den yükleyin. Bu yöntemin ek avantajı, hangi tablonun sorun çıkardığını hemen görebilmenizdir.

Tek bir tablo bile limiti aşacak kadar büyükse, o tabloyu satır satır bölünebilir hâle getirin:

mysqldump -u kullanici -p --no-create-info --skip-extended-insert \
  veritabani buyuk_tablo > buyuk_tablo.sql

split -l 20000 buyuk_tablo.sql parca_ --additional-suffix=.sql

--skip-extended-insert her satır için ayrı bir INSERT ifadesi üretir; böylece satır bazlı bölme güvenli hâle gelir. Bedeli dosyanın belirgin şekilde büyümesidir, ama parçalar küçük olduğu için bu bir sorun yaratmaz.

Bölme işini yapan hazır masaüstü araçları da var (SQLDumpSplitter gibi). Kullanacaksanız, çıkan parçaların ilkinde CREATE TABLE ifadelerinin bulunduğundan ve parçaların doğru sırayla yüklendiğinden emin olun.

"MySQL server has gone away" ve max_allowed_packet#

Dosyayı sonunda yükleyebildiniz ama import ortalarda şu hatayla düştü:

ERROR 2006 (HY000): MySQL server has gone away
ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes

Bu artık bir yükleme sorunu değil; MySQL sunucusunun tek bir sorguda kabul ettiği azami veri boyutu aşıldı. mysqldump varsayılan olarak "extended insert" kullanır, yani binlerce satırı tek bir dev INSERT ifadesine sıkıştırır. İçinde büyük metin veya resim (BLOB) alanları olan tablolarda bu ifade kolayca 100 MB'ı geçer.

Varsayılan değerler sürümden sürüme değişir ve fark büyüktür:

MySQL 8'den MariaDB'ye taşıma yapanların bu hatayla sık karşılaşmasının sebebi tam olarak bu tablodur. Mevcut değeri görmek için:

SHOW VARIABLES LIKE 'max_allowed_packet';

Kalıcı çözüm sunucu yapılandırmasındadır:

[mysqld]
max_allowed_packet = 512M

Değişiklik systemctl restart mysql (veya mariadb) ile devreye girer. Yeniden başlatamıyorsanız geçici olarak oturum düzeyinde ayarlayabilirsiniz — ancak bu değer sunucu yeniden başladığında sıfırlanır ve yalnızca yeni bağlantılar için geçerlidir:

SET GLOBAL max_allowed_packet = 536870912;

İstemci tarafında da aynı sınırı bildirmeniz gerekir:

mysql --max-allowed-packet=512M -u kullanici -p veritabani < yedek.sql

Yapılandırmaya hiç dokunamıyorsanız, yedeği baştan küçük paketlerle almak da işe yarar. --max-allowed-packet parametresi mysqldump için de geçerlidir; alternatif olarak --skip-extended-insert ile her satırı ayrı ifade hâline getirebilirsiniz.

Zaman Aşımı Hataları ve Import'u Hızlandırmak#

Zaman aşımının üç ayrı kaynağı vardır ve üçünü birden ayarlamak gerekir: PHP'nin max_execution_time değeri, phpMyAdmin'in kendi $cfg['ExecTimeLimit'] ayarı (varsayılan 300 saniye; 0 yaparsanız sınır kalkar) ve Nginx/Apache tarafındaki proxy zaman aşımı. Biri bile düşük kalırsa istek yarıda kesilir.

Ama süreyi uzatmadan önce import'un neden yavaş olduğuna bakmak daha verimli. Varsayılan hâliyle MySQL her INSERT sonrasında indeksleri günceller, yabancı anahtarları kontrol eder ve işlemi diske yazar. Bu kontrolleri import süresince kapatmak, büyük veri kümelerinde süreyi katbekat kısaltır:

SET autocommit = 0;
SET unique_checks = 0;
SET foreign_key_checks = 0;

SOURCE /home/kullanici/yedek.sql;

COMMIT;
SET foreign_key_checks = 1;
SET unique_checks = 1;
SET autocommit = 1;

SOURCE komutu yalnızca mysql istemcisinde çalışır; phpMyAdmin'de kullanılamaz. Kapattığınız kontrolleri mutlaka geri açın — açık unutulan foreign_key_checks, sonraki günlerde tutarsız veri yazılmasına izin verir ve bunu fark etmeniz aylar sürebilir.

Import bitince veritabanının gerçekten sağlam geldiğini doğrulayın:

SELECT COUNT(*) FROM urunler;
SHOW TABLE STATUS FROM yeni_db;

Tablo sayısı ve satır sayıları kaynakla uyuşmuyorsa import sessizce yarıda kalmıştır. Kısmi bir import'un üzerine tekrar yükleme yapmak yerine veritabanını sıfırlayıp baştan başlamak her zaman daha güvenlidir; aksi halde yinelenen kayıtlar ve bozuk tablolarla uğraşırsınız. Aynı ekranların adım adım kullanımı için phpMyAdmin içe ve dışa aktarma yazısı yol gösterir.

Sıkça Sorulan Sorular#

phpMyAdmin'de import limitini kalıcı olarak nasıl artırırım?#

Limit phpMyAdmin'in kendi ayarı değil, onu çalıştıran PHP sürümünün upload_max_filesize ve post_max_size değerleridir; ikisinden küçük olanı geçerlidir. Kendi sunucunuzda php.ini dosyasını düzenleyip PHP-FPM veya Apache'yi yeniden başlatmanız yeterlidir. Paylaşımlı hostingde phpMyAdmin genellikle panelin ayrı PHP havuzunda çalıştığı için kendi hesabınızın ayarlarını değiştirmeniz sonucu etkilemez; bu durumda sıkıştırma veya SSH yöntemine geçin.

500 MB'lık bir SQL dosyasını phpMyAdmin ile yükleyebilir miyim?#

Doğrudan yüklemek mümkün ama tavsiye edilmez. Dosyayı .gz olarak sıkıştırırsanız boyut tipik olarak 60 MB civarına iner ve çoğu limitin altına girer; asıl risk yükleme değil, işleme süresidir. Bu boyutta bir dump'ın phpMyAdmin içinde zaman aşımına uğrama ihtimali yüksektir. SSH erişiminiz varsa mysql < dump.sql yöntemi hem daha hızlı hem de yarıda kesilme riski olmayan tek seçenektir.

max_allowed_packet değerini ne kadar yapmalıyım?#

Import sırasında karşılaşılan hataları geçmek için 256 MB veya 512 MB fazlasıyla yeterlidir. Kalıcı üretim ayarı olarak gereksiz yüksek bir değer belirlemek anlamsızdır, çünkü MySQL bu boyutta bir arabelleği bağlantı başına ayırabilir ve bellek tüketimi artar. Yaygın pratik, import süresince değeri yükseltip iş bittikten sonra 64 MB gibi makul bir seviyeye çekmektir.

SQL dosyasını bölerken nelere dikkat etmeliyim?#

Dosyayı boyuta göre kesmeyin; bir SQL ifadesinin ortasında bölünen parçalar geçerli SQL olmaz. Tablo tablo yedek almak en güvenli yoldur: önce --no-data ile şemayı, sonra her tablo için --no-create-info ile veriyi alın ve şema dosyasını her zaman ilk sırada yükleyin. Tek bir tablo bile çok büyükse --skip-extended-insert ile satır başına bir INSERT ürettirip satır sayısına göre bölebilirsiniz.

Import yarıda kaldı, baştan mı başlamalıyım?#

Evet, kısmi bir import'un üzerine devam etmek yerine hedef veritabanını silip yeniden oluşturmak en temiz yoldur. Yarıda kalan bir dosyada hangi satıra kadar gelindiği çoğu zaman belirsizdir; üzerine yükleme yaparsanız birincil anahtar çakışmaları ve yinelenen kayıtlar oluşur. phpMyAdmin'in "şu satırdan devam et" özelliğini yalnızca kesildiği satır numarasını ekranda gördüyseniz kullanın.

Türkçe karakterler import sonrası bozuk çıkıyor, sebebi limit olabilir mi?#

Hayır, bu tamamen ayrı bir sorundur ve karakter seti uyuşmazlığından kaynaklanır. Yedek alırken ve geri yüklerken --default-character-set=utf8mb4 parametresini kullanmak, phpMyAdmin'de ise İçe Aktar ekranındaki karakter kümesini utf8mb4 seçmek çoğu vakayı önler. Veri zaten bozulmuşsa dosya boyutuyla ilgisi olmayan ayrı bir onarım süreci gerekir.