MySQL: # 126 - Tablo için yanlış anahtar dosyası

Bir MySQL sorgusundan aşağıdaki hatayı aldım.

#126 - Incorrect key file for table

Bu tablo için bir anahtar bile açıklamadım ama endekslerim var. Sorunun ne olabileceğini bilen var mı?

Bu her gerçekleştiğinde, benim deneyimime göre tam bir disk oldu.

DÜZENLE

Yapılandırılmış bir ramdiskiniz varsa, büyük bir tabloyu değiştirmek gibi şeyler yaparken bunun tam bir ramdiskten kaynaklanabileceğini de belirtmek gerekir. Eğer boyutunu artıramazsanız, bu tür işlemlere izin vermek için ramdisk satırını geçici olarak yorumlayabilirsiniz.

Her şeyden önce, anahtarların ve dizinlerin MySQL'de eşanlamlı olduğunu bilmelisiniz. CREATE TABLE Sözdizimi hakkındaki belgelere bakarsanız , şunları okuyabilirsiniz:

KEYnormalde eşanlamlıdır INDEX. Anahtar öznitelik PRIMARY KEY, KEYbir sütun tanımında verildiği zaman da belirtilebilir . Bu, diğer veritabanı sistemleriyle uyumluluk için uygulanmıştır.

Şimdi, aldığınız türden bir hata iki şeye bağlı olabilir:

• MySQL sunucusundaki disk sorunları
• Bozuk anahtarlar / tablolar

İlk durumda, sorgunuza bir sınır eklemenin sorunu geçici olarak çözebileceğini göreceksiniz. Bunu sizin için yaparsa, muhtemelen tmpyapmaya çalıştığınız sorguların boyutu için çok küçük bir klasörünüz vardır. Daha sonra tmpdaha büyük hale getirmeye veya sorgularınızı küçültmeye karar verebilirsiniz ! ;)

Bazen tmpyeterince büyük olsa da yine de dolar, bu durumlarda manuel temizlik yapmanız gerekir.

İkinci durumda, MySQL verileriyle ilgili gerçek sorunlar vardır. Verileri kolayca yeniden ekleyebiliyorsanız, tabloyu bırakmanızı / yeniden oluşturmanızı ve verileri yeniden eklemenizi tavsiye ederim. Eğer yapamazsanız, TAMİR masasıyla masayı yerinde tamir etmeyi deneyebilirsiniz . Bu genellikle uzun bir süreçtir ve çok iyi başarısız olabilir.

Aldığınız tam hata mesajına bakın :

'FILEPATH.MYI' tablosu için yanlış anahtar dosyası; tamir etmeyi dene

Mesajda onu onarmaya çalışabileceğinizden bahsediyor. Ayrıca, aldığınız gerçek FILEPATH'a bakarsanız, daha fazlasını öğrenebilirsiniz:

• eğer böyle bir /tmp/#sql_ab34_23fşeyse, MySQL'in sorgu boyutu nedeniyle geçici bir tablo oluşturması gerektiği anlamına gelir. Onu / tmp içinde depolar ve / tmp dosyanızda bu geçici tablo için yeterli alan yoktur.

• bunun yerine gerçek bir tablonun adını içeriyorsa, bu tablonun büyük olasılıkla bozuk olduğu ve onu onarmanız gerektiği anlamına gelir.

Sorununuzun / tmp boyutunda olduğunu belirlerseniz, bu yanıtı düzeltme için benzer bir soruya okuyun: MySQL, Hata 126: Tablo için yanlış anahtar dosyası .

Bu talimatlara uymak, tmp dizinimi yeniden oluşturmama ve sorunu çözmeme izin verdi:

Tüm dosya sistemlerini ve disk kullanımlarını okunabilir biçimde görüntüleyin:

df -h

Dosyaların açık olduğu işlemleri bulun /tmp

sudo lsof /tmp/**/*

Sonra umount /tmpve /var/tmp:

umount -l /tmp
umount -l /var/tmp

Ardından bozuk bölüm dosyasını kaldırın:

rm -fv /usr/tmpDSK

Sonra güzel bir yeni tane oluşturun:

/scripts/securetmp

Securetmp Perl betiğini düzenleyerek tmp dizininin boyutunu kendiniz manuel olarak ayarlayabileceğinizi, ancak yalnızca betiği çalıştırmanın sunucumuzdaki tmp dizininin boyutunu kabaca 450MB'den 4.0GB'ye yükselttiğini unutmayın.

Hata # 126 genellikle bozuk bir tablonuz olduğunda ortaya çıkar. Bunu çözmenin en iyi yolu onarım yapmaktır. Bu makale yardımcı olabilir:

http://dev.mysql.com/doc/refman/5.0/en/repair-table.html

Ben ayarladığınızda bu hata var ft_min_word_len = 2içinde my.cnf4 varsayılan, 2'ye tam metin endeksinde minimum kelime uzunluğu düşürür.

Masayı onarmak sorunu çözdü.

Sorgunuzda limit kullanmayı deneyin. @ Monsters X'in söylediği gibi dolu disk yüzünden.

Ben de bu problemle karşılaştım ve sorgulamada limitle çözdüm çünkü binlerce kayıt vardı. Şimdi iyi çalışıyor :)

Bunun eski bir konu olduğunu biliyorum ama bahsedilen çözümlerin hiçbiri benim için işe yaramadı. İşe yarayan başka bir şey yaptım:

Gerek:

1. MySQL hizmetini durdurun:
2. Mysql \ data dosyasını aç
3. Hem ib_logfile0 hem de ib_logfile1'i kaldırın.
4. Hizmeti yeniden başlatın

repair table myschema.mytable;

Bu sorunu şu şekilde düzelttim:

ALTER TABLE table ENGINE MyISAM;
ALTER IGNORE TABLE table ADD UNIQUE INDEX dupidx (field);
ALTER TABLE table ENGINE InnoDB;

Yardımcı olabilir

• Referanslar: MySQL: ALTER IGNORE TABLE "Bütünlük kısıtlaması ihlali" veriyor

Git /etc/my.cnfve yorum yaptmpfs

#tmpdir=/var/tmpfs

Bu sorunu çözer.

Başka bir cevapta önerilen komutu çalıştırdım ve dizin küçükken boştu, bu yüzden sorun alan değildi.

/var/tmp$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs              60G   51G  9.5G  85% /
none                  1.5G  4.0K  1.5G   1% /dev
tmpfs                 200M     0  200M   0% /var/tmpfs
/var/tmpfs$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs              60G   51G  9.5G  85% /
none                  1.5G  4.0K  1.5G   1% /dev
tmpfs                 200M     0  200M   0% /var/tmpfs

Sorguda yer alan tabloların her biri için bir onarım komutu çalıştırmayı deneyin.

MySQL yöneticisini kullanın, Kataloğa gidin -> Kataloğunuzu seçin -> Bir tablo seçin -> Bakım düğmesine tıklayın -> Onar -> FRM Kullan.

Şimdi diğer cevaplar benim için çözdü. Aynı sorguda bir sütunu ve bir dizini yeniden adlandırmanın hataya neden olduğu ortaya çıktı.

Çalışmıyor:

-- rename column and rename index
ALTER TABLE `client_types`
    CHANGE `template_path` `path` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
    DROP INDEX client_types_template_path_unique,
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC);

Works (2 ifade):

-- rename column
ALTER TABLE `client_types`
    CHANGE `template_path` `path` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL;
-- rename index
ALTER TABLE `client_types`
    DROP INDEX client_types_template_path_unique,
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC);

Bu, MariaDB 10.0.20'deydi. MySQL 5.5.48'de aynı sorguda herhangi bir hata yoktu.

mysql> set global sql_slave_skip_counter=1; start slave; show slave status\G

Sonra var hata var:

 Error 'Table './openx/f_scraper_banner_details' is marked as crashed and should be repaired' on query. Default database: 'openx'. Query: 'INSERT INTO f_scraper_banner_details(job_details_id, ad_id, client_id, zone_id, affiliateid, comments, pct_to_report, publisher_currency, sanity_check_enabled, status, error_code, report_date) VALUES (10274859, 321264, 0, 31926, 0, '', -1, 'USD', 1, 'FAILURE', 'INACTIVE_BANNER', '2016-06-28 04:00:00')'

mysql> onarım tablosu f_scraper_banner_details;

Bu benim için çalıştı

Sorunum kötü bir sorudan geldi. FROM'daki bir tabloya SELECT'te başvurulmamış.

misal:

   SELECT t.*,s.ticket_status as `ticket_status`
   FROM tickets_new t, ticket_status s, users u

, users ubenim için soruna neden olan şeydi. Bunu kaldırmak sorunu çözdü.

Referans için bu bir CodeIgniter geliştirici ortamındaydı.

Bu mesajı ft_min_word_len (tam metin min kelime uzunluğu) azalttıktan sonra bir tabloya yazarken aldım . Çözmek için, tabloyu onararak dizini yeniden oluşturun.

mysqlcheck -r -f -uroot -p --use_frm db_name

normalde hile yapacak