InnoDB tablo oluşturma hatası: “Satır boyutu çok büyük”

Rapor oluşturmak amacıyla normalize edilmiş bir db yapısını geçici bir tablo haline getiren bazı mühendislerimiz var. Sütunlar TEXT NOT NULL("neden bunu yaptıklarını biliyorum" olarak belirtildi ; sadece bunu ele aldığımızı varsayalım).

Linux'ta InnoDB eklentisi 1.0.9 ile MySQL 5.1.48 Community RHEL5 kullanıyoruz.

MyISAM kullanırken, maksimum sütun veya maksimum satır uzunluğunun tablo boyutu sınırlarıyla hiç karşılaşmadık (araştırma sırasında 2598'de maksimum sütun sınırına ulaştık (2599. hata 1117'ye neden oluyor) InnoDB ile sınırlara ulaşıyoruz.Bu sınırlar, tablo (veri ekleme yok):

Satır 1'deki HATA 1118 (42000): Satır boyutu çok büyük. BLOB'ları saymayan, kullanılan tablo türü için maksimum satır boyutu 8126'dır. Bazı sütunları METİN veya BLOB'lar olarak değiştirmeniz gerekir.

Aşağıdakilere cevap arıyorum:

1. V / v / b / t sütunlarının lotlarını kullanırken satır boyutu parçacıklarını belirlemek için ayrıntılı formül nedir? Ben varchar(N)sütunları kullanarak birkaç farklı formülü denedim (burada N 1 ve 512 arasındadır), UTF8 karakter kümesi (* 3) ve tablo başarısızlığa kadar alacak kadar çok sütun. Denediğim kombinasyonların hiçbiri gerçek test sonuçlarıyla eşleşen değerler vermiyor.

2. Satır boyutunu hesaplarken başka hangi 'ek yükü' düşünmeliyim?

3. Varchar (109) sütunları olan tablolar oluşturmaktan varchar (110) sütunlarına gitmem neden hata iletisi 8126'dan 65535'e değişiyor?

Sorularınızın cevapları karmaşıktır, çünkü bunlar InnoDB dosya biçimine göre değişir . Bugün, Antilop ve Barracuda adı verilen iki format var.

Merkezi tablo alanı dosyası (ibdata1) her zaman Antilop biçimindedir. Tablo başına dosya kullanıyorsanız, tek tek dosyaların my.cnf dosyasında Barracuda biçimini kullanmasını sağlayabilirsiniz innodb_file_format=Barracuda.

Temel noktalar:

• Bir 16KB InnoDB verisi sayfası en az iki veri satırı içermelidir. Ayrıca her sayfanın üstbilgisi ve sayfa sağlama toplamlarını ve günlük sırası numarasını içeren bir altbilgisi vardır. Bu, satır başına 8 KB'tan biraz daha az sınırınızı alacağınız yerdir.

• INTEGER, DATE, FLOAT, CHAR gibi sabit boyutlu veri türleri bu birincil veri sayfasında depolanır ve satır boyutu sınırına dahil edilir.

• VARCHAR, TEXT, BLOB gibi değişken boyutlu veri türleri taşma sayfalarında saklanır, bu nedenle satır boyutu sınırına tam olarak sayılmazlar. Antilop'ta, taşma sayfasında depolanmasının yanı sıra, bu tür sütunların 768 bayta kadarı birincil veri sayfasında depolanır. Barracuda dinamik satır biçimini destekler , bu nedenle birincil veri sayfasında yalnızca 20 baytlık bir işaretçi saklayabilir.

• Değişken boyutlu veri türlerine, uzunluğu kodlamak için 1 veya daha fazla bayt da eklenir. Ve InnoDB satır formatı da bir dizi alan ofseti içerir. Yani wiki'lerinde az çok belgelenmiş bir iç yapı var . [EDIT] Ölü bağlantı - işte şimdi daha iyi görünüyor.

Barracuda , taşma verileri için daha fazla depolama verimliliği elde etmek için ROW_FORMAT = COMPRESSED'i de destekler .

Ben de hiç iyi tasarlanmış bir tablo satır boyutu sınırını aşan görmedim yorum yapmak zorunda. İlk Normal Formun yinelenen grup koşullarını ihlal ettiğiniz güçlü bir "kod kokusu" dur.

Durumum biraz farklı. Her satırda depolamam gereken veri öğelerinden biri potansiyel olarak çok büyük. (Veri alanı, birden fazla gömülü görüntü içerebilen bir belge için LONGBLOB'dur. Örnek veritabanım 25-30 MB kadar büyük belgeler içeriyor, ancak bu belgeler bazı durumlarda daha büyük olabilir.) Çevrimiçi bulduğum çözümlerin hiçbiri yardım sağladı . (InnoDB dosya türünü Barracuda olarak değiştirdi, günlük dosyası boyutunu artırdı, satır biçimini COMPRESSED olarak ayarladı.)

Benim için işe yaradığını bulduğum tek çözüm, MySQL 5.6.x'ten MySQL 5.5.x'e geri dönmekti.