MySQL> Tablo mevcut değil. Ama öyle (ya da olmalı)

Bir MySQL kurulumunun datadirini değiştirdim ve biri hariç tüm üsler doğru şekilde taşındı. USEVeritabanına bağlanabiliyorum . SHOW TABLESayrıca tüm tabloları doğru bir şekilde döndürür ve her tablonun dosyaları MySQL veri dizininde bulunur.

Ancak, SELECT tablodan bir şey , tablo yok bir hata iletisi alıyorum. Yine de, aynı tabloyu SHOW TABLESifade ile gösterebildiğim için bu bir anlam ifade etmiyor .

Benim tahminim SHOW TABLESdosya varlığını listeler ama bir dosyanın bozuk olup olmadığını kontrol etmez. Sonuç olarak, bu dosyaları listeleyebilirim ancak erişemiyorum.

Bununla birlikte, bu sadece bir tahmindir. Bunu daha önce hiç görmedim. Şimdi, veritabanını test için yeniden başlatamıyorum, ancak onu kullanan diğer tüm uygulamalar iyi çalışıyor. Ama bu sadece bir tahmin, bunu daha önce hiç görmedim.

Bunun neden olduğunu bilen var mı?

Misal:

mysql> SHOW TABLES;
+-----------------------+
| Tables_in_database    |
+-----------------------+
| TABLE_ONE             |
| TABLE_TWO             |
| TABLE_THREE           |
+-----------------------+
mysql> SELECT * FROM TABLE_ONE;
ERROR 1146 (42S02): Table 'database.TABLE_ONE' doesn't exist

Herkesin umurunda olması durumunda:

Komutu kullanarak doğrudan bir veritabanı dizini kopyaladıktan sonra aynı sorunu yaşadım

cp -r /path/to/my/database /var/lib/mysql/new_database

Bunu InnoDBtabloları kullanan bir veritabanı ile yaparsanız, yukarıda belirtilen bu çılgın 'tablo yok' hatası alırsınız.

Sorun, gerektiğidir ib*MySQL datadir kök dosyaları (örneğin ibdata1, ib_logfile0ve ib_logfile1).

Bunları kopyaladığımda benim için çalıştı.

Mac OS'de (MySQL DMG Kurulumu) benim için MySQL sunucusunun basit bir şekilde yeniden başlatılması sorunu çözdü. Kış uykusuna neden oldu sanırım.

Kullandığım tablo adı için durum kapalıyken bu sorunu alıyorum. Yani tabloya 'db' deniyor ama select deyiminde 'DB' kullandım. Kasanın aynı olduğundan emin olun.

Ayarlanırken bu hata da oluşabilir lower_case_table_namesiçin 1ve daha sonra bu değişken için varsayılan değerle oluşturulan erişim tabloları çalışıyor. Bu durumda, önceki değere geri döndürebilirsiniz ve tabloyu okuyabilirsiniz.

1. mysqld'i durdur
2. yedekleme mysql klasörü: cp -a /var/lib/mysql /var/lib/mysql-backup
3. veritabanı klasörünü eski makineden /var/lib/mysql
4. eski veritabanından ib * (ib_logfile *, ibdata) geçersiz kıl
5. mysqld başlat
6. dökmek
7. mysqldump >dbase.mysql
8. mysql hizmetini durdur
9. Kaldırmak /var/lib/mysql
10. adlandırmak /var/lib/mysql-backupiçin/var/lib/mysql
11. mysqld başlat
12. veritabanı oluştur
13. mysqldump < dbase.mysql

Lütfen sorguyu çalıştırın:

SELECT 
    i.TABLE_NAME AS table_name, 
    LENGTH(i.TABLE_NAME) AS table_name_length,
    IF(i.TABLE_NAME RLIKE '^[A-Za-z0-9_]+$','YES','NO') AS table_name_is_ascii
FROM
    information_schema.`TABLES` i
WHERE
    i.TABLE_SCHEMA = 'database'

Maalesef MySQL, unicode ve yazdırılamayan karakterlerin tablo adında kullanılmasına izin verir. Tablolarınızı, bir belge / web sitesinden kod oluştur'u kopyalayarak oluşturduysanız, bir yerde sıfır genişlik boşluğuna sahip olma olasılığı vardır.

Bu kâbusta sadece üç gün geçirdim. İdeal olarak, geri yükleyebileceğiniz bir yedeklemeniz olmalı, ardından hasarlı tabloyu bırakmalısınız. Hataların Bu tür sizin ibdata1 büyümeye neden olabilir devasa (mütevazı tablolar için boyut olarak 100GB +)

Eğer mySqlDump'a güveniyormuş gibi yeni bir yedeğiniz yoksa, yedeklemeleriniz muhtemelen geçmişte bir noktada sessizce bozuldu. Tabii ki yapamayacağınız veritabanlarını dışa aktarmanız gerekecek, çünkü mySqlDump'ı çalıştırırken kilit hataları alacaksınız.

Bu nedenle, geçici bir çözüm olarak /var/log/mysql/database_name/table_name dosyasına gidin ve kaldırın. *

Sonra hemen masayı boşaltmaya çalışın; bunu yapmak artık işe yarıyor. Şimdi veritabanını yeni bir veritabanına geri yükleyin ve eksik tabloları yeniden oluşturun. Sonra kırık veritabanı dökümü.

Bizim durumumuzda da mysql has gone awaytüm veritabanlarında sürekli olarak rastgele mesajlar alıyorduk ; hasarlı veritabanı kaldırıldıktan sonra her şey normale döndü.

Sebebini bilmiyorum ama benim durumumda sadece yabancı anahtar kontrolünü devre dışı bırakmayı ve etkinleştirmeyi çözdüm

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

Aynı sorunu yaşadım ve 2-3 gün aradım, ama benim için çözüm gerçekten aptalcaydı.

MySQL'i yeniden başlatın

$ sudo service mysql restart

Artık tablolar erişilebilir hale geliyor.

Tamam bu oldukça saçma gelecektir, ama beni mizah edin.
Benim için bu ifadeyi değiştirdiğimde sorun çözüldü:

SELECT * FROM `table`

İki değişiklik yaptım
1.) Tablo adı küçük harf yaptı - Biliyorum !!
2.) Belirli alıntı sembolünü kullandı = ` : SEKME'nizin üzerindeki anahtar

Çözüm kulağa saçma geliyor, ama işe yaradı ve Cumartesi akşamı ve sabah 9'dan beri çalışıyorum - Ben de alacağım :)

İyi şanslar.

WAMP yükselttikten sonra ama hiçbir veritabanı yedekleme sahip sonra bu sorun vardı.

Bu benim için çalıştı:

1. Yeni WAMP'ı durdur

2. İhtiyacınız olan veritabanı dizinlerini ve eski WAMP kurulumundan ibdata1 dosyasını kopyalayın

3. Sil ib_logfile0veib_logfile1

4. WAMP'ı başlat

Artık veritabanlarınızın yedeğini alabilmeniz gerekir. Ancak sunucunuz yeniden başlatıldıktan sonra sorun yaşamaya devam edersiniz. Şimdi WAMP'ı yeniden yükleyin ve veritabanlarınızı içe aktarın.

İdb dosyasını kopyalamadan önce tablo alanını silmek için sql sorgusunu çalıştırmayı deneyin:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

İdb dosyasını kopyala

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

MySql'i yeniden başlat

MySQL'i yeniden yüklemek zorunda kaldıktan sonra aynı sorunu yaşadım, kurulum sırasında InnoDB günlük dosyaları hakkında veri depolayan bazı yapılandırma dosyalarının, bu dosyaların ib_logfile * (günlük dosyaları doğru mu?), Üzerine yazıldığı anlaşılıyor. Bu sorunu çözmek için ib_logfile * dosyalarını sildim.

Benim için işe yarayan, var olmamasına rağmen sadece masayı düşürmekti. Sonra tabloyu yeniden oluşturulan ve daha önce yapılan bir sql dökümü yeniden doldurdu.

Bazı tablo adları metatabanı olmalı ve ben bırakana kadar büyük olasılıkla hala orada mevcuttu.

Bir hayalet tablo ile benzer bir sorun vardı. Neyse ki başarısızlıktan önce bir SQL dökümü vardı.

Benim durumumda:

1. MySQL'i durdurun
2. İb * dosyalarını /var/mysqlkapalı konumdan yedeklemeye taşıma
3. Sil /var/mysql/{dbname}
4. MySQL'i yeniden başlat
5. Boş veritabanını yeniden oluştur
6. Döküm dosyasını geri yükle

NOT: Döküm dosyası gerektirir.

1. Veritabanına mysqldump yapın:

   mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sql

2. Veritabanını geri yükle

   mysql -u user -ppass dbname < D:\Back-ups\dbname.sql

Artık veritabanındaki tüm tablolar tamamen geri yüklendi. Deneyin..

SELECT * FROM dbname.tablename;

MariaDB'yi yeni bilgisayara yükledim, Mysql hizmetinin veri klasörünü yeniden adlandırdığı veriyi durdurdum - sadece Mysql \ data \ table_folders ve ibdata1 kopyalama sorunumu çözdüm çökmüş HD MySql veri Klasöründen yeni kurulan mysql veri klasörüne kopyalayarak .

Ben Atlananları ib_logfile0 ve ib_logfile1 (Aksi sunucu hizmeti başlamadı)

MySQL hizmetini başlattı.

Sonra sunucu çalışıyor.

Sorunun geçersiz (bozuk?) İnnodb günlük dosyalarıyla (en azından benim ve birkaçında) yapılması gerektiği anlaşılıyor. Genel olarak konuşursak, sadece yeniden yaratılmaları gerekir.

İşte çoğu mysql'nin yeniden başlatılmasını gerektiren çözümler.

• Günlük dosyalarınızı yeniden oluşturun (MySQL'i silin ve yeniden başlatın )
• Günlük dosyalarınızı yeniden boyutlandırın (MySql 5.6+ dosyayı sizin için yeniden oluşturur)
• Bir tür veri taşıma işlemi yapıyorsanız, doğru dosyayı doğru şekilde taşıdığınızdan ve diğerlerinin belirttiği gibi dosyaya izin verdiğinizden emin olun
• MySQL'in her ikisinin de sahibi olduğu verilerinizin ve günlük dosyalarınızın izinlerini kontrol edin
• Her şey başarısız olursa, büyük olasılıkla veritabanını yeniden oluşturmanız gerekir

İşte başka bir senaryo (sürüm yükseltme) :

İşletim sistemimi (Mac OS El Captain) yeniden yükledim ve yeni bir mysql sürümü (homebrew kullanarak) yükledim. Yüklü sürüm (5.7) öncekinden daha yeni oldu. Sonra ib * dosyaları da dahil olmak üzere tabloların üzerine kopyaladım ve sunucuyu yeniden başlattım. MySQL tezgah tabloları görebiliyordu ama bir şey seçmeye çalıştığımda, "Tablo yok" var.

Çözüm:

1. mysql sunucusunu durdurun örn. mysql.server stop veyabrew services stop mysql
2. kullanarak sunucuyu başlat mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/ (yolu gerektiği gibi değiştirin)
3. Çalıştırmak mysql_upgrade -u root -p password (başka bir terminal penceresinde)
4. çalışan sunucuyu kapat mysqladmin -u root -p password shutdown
5. sunucuyu normal modda yeniden başlatın mysql.server startveyabrew services start mysql

İlgili dokümanlar burada .

Benim durumumda, ben masaya bir tetikleyici tanımlamıştı ve sonra tabloya satır eklemek çalışıyordu. bir şekilde tetikleyici hatalıydı ve bu nedenle insert hata veriyor, tablo mevcut değil.

Tablo adınızda gizli bir karakter olması mümkündür. Şov tabloları yaptığınızda bunlar görünmez. Bir "TABLE_ONE TABLOSU OLUŞTUR" ve "TABLE_ONE" sekmesini tamamlayabilir ve herhangi bir gizli karakter içerip içermediğini görebilir misiniz? Ayrıca, tabloları bırakarak ve remaking denediniz. Ayrıcalıklarda hiçbir şeyin yanlış olmadığından ve gizli karakterlerin olmadığından emin olmak için.

TimeMachine yedeklemesinin içe aktarılmasından sonra aynı sorun. Benim çözümüm MySQL sunucusunu durdurmak ve ib * dosyalarındaki okuma-yazma izinlerini düzeltmekti.

Sanırım başka bir cevap buraya getirmeye değer (çünkü buraya aynı problemle geldim ve bu benim için cevap oldu):

Sorgunuzdaki tablo adının tamamen aynı olduğundan emin olun. veritabanındakiyle olduğundan emin olun.

Bir tür bariz, acemi bir şey, ama "kullanıcı" vs "kullanıcılar" gibi şeyler insanları yukarı yolculuk olabilir ve ben burada listede olması yararlı bir cevap olacağını düşündüm. :)

Benim durumumda, dışa aktarılan sql dosyasını içe aktarırken, tablo oluşturma sorgusu için tablo yok gibi bir hata alıyordum.

Veritabanı adımda bir alt çizgi olduğunu fark ettim ve mysql bundan önce bir kaçış karakteri koyuyordu.

Bu yüzden veritabanı adındaki alt çizgiyi kaldırdım, her şey yolunda gitti.

Umarım başka birine de yardımcı olur.

Benim tablo bir şekilde ' Customers'yani önde gelen boşluk ile yeniden adlandırılmıştı

Bu demek oluyor ki

a) sorgular kırıldı

b) tablo, tablolarımın alfabetik sırada beklendiği yerde görünmedi, bu da panik içinde göremediğim anlamına geliyordu!

RENAME TABLE ` Customer` TO `Customer`;

Benim durumumda SQLCA.DBParmparametre oldu.

kullandım

SQLCA.DBParm = "Databse = "sle_database.text""

ama olmalı

SQLCA.DBParm = "Database='" +sle_database.text+ "'"

Açıklama:

Üç dizeyi birleştireceksiniz:

 1. Database='              -  "Database='"

 2. (name of the database)  - +sle_database.text+

 3. '                       - "'" (means " ' "  without space)

Quatermarklarda boşluk kullanmayın. Meslektaşım Jan'a teşekkürler.

Git: xampp\mysql\data\dbname
dbname içinde tablename.frm ve tablename.ibd dosyası var.
kaldırın ve mysql'yi yeniden başlatın ve tekrar deneyin.

Yalnızca ibdata1eski veri dizininizdeki dosyayı kopyalayın . Kopyalamayın ib_logfile1veya ib_logfile0dosyaları. Bu MySQL'in artık başlamamasına neden olacaktır.

Bugün aynı sorunu aştı. Bu bir mysql "Tanıtıcı Büyük / Küçük Harfe Duyarlılık" sorunudur.

Lütfen ilgili veri dosyasını kontrol edin. Büyük olasılıkla dosya sisteminde dosya adının küçük olması, ancak "tabloları göster" komutunda listelenen tablo adının büyük olması mümkündür. " lower_case_table_names" Sistem değişkeni 0 ise, " " 0 olduğunda ad karşılaştırmaları büyük / küçük harfe duyarlı olduğundan sorgu "tablo yok" döndürür lower_case_table_names.

Aynı sorunu pencerelerde de yaşadım. İb * dosyaları ve thd veri dizini altındaki mysql dizinini kopyalamaya ek olarak, my.ini dosyasıyla eşleşmem gerekiyordu.

Önceki yüklememdeki my.ini dosyasında şu satır yoktu:

innodb-page-size=65536

Ama yeni kurulumum yaptı. Muhtemelen eski yükleyicide bu seçeneğim yoktu. Bu kaldırıldı ve hizmet yeniden başladı ve tablolar beklendiği gibi çalıştı. Kısacası, yeni kurulumunuza bağlı olarak, tek istisna datadir, plugin-dir ve port # olmak üzere yeni my.ini dosyasının eskisinin bir kopyası olduğundan emin olun.