Ошибка sql error 1146 - Исправление ошибок и поиск оптимальных решений проблем

I am using windows XP. I am creating a table in phpMyAdmin using its built-in create table feature,
my database name is ddd.

It generates the following code:

CREATE TABLE  `ddd`.`mwrevision` (

`asd` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`sddd` INT NOT NULL
) ENGINE = INNODB;

and the following error shows up:

MySQL said:     
#1146 - Table 'ddd.mwrevision' doesn't exist

What might be the problem?

mins

5,87611 gold badges52 silver badges72 bronze badges

asked Jun 14, 2011 at 10:29

I also had same problem in past. All had happend after moving database files to new location and after updating mysql server. All tables with InnoDB engine disappeared from my database. I was trying to recreate them, but mysql told me 1146: Table 'xxx' doesn't exist all the time until I had recreated my database and restarted mysql service.

I think there’s a need to read about InnoDB table binaries.

answered Dec 7, 2011 at 4:43

sempashasempasha

6235 silver badges18 bronze badges

I had the same problem and can’t get a good tip for this over the web, so I shared this for you and for all who needs.

In my situation I copy a database (all files: frm, myd) to the data folder in MySQL data folder (using Wamp at home). All thing was OK until I want to create a table and have the error #1146 Table '...' doesn't exist!.

I use Wamp 2.1 with MySQL version 5.5.16.

My solution:

Export the database to file;
verify if exported file is really OK!!;
drop the database where I have issues;
create a new database with the same name that the last;
import the file to the database.

FOR ME IS PROBLEM SOLVED. Now I can create tables again without errors.

answered Jan 24, 2012 at 6:30

carloscarlos

1111 silver badge2 bronze badges

Restarting MySQL works fine for me.

answered Nov 2, 2014 at 18:24

Muhammad UsmanMuhammad Usman

10.2k22 gold badges72 silver badges107 bronze badges

In my case I ran this command even if the table wasn’t visible in PhpMyAdmin :

DROP TABLE mytable

then

CREATE TABLE....

Worked for me !

answered May 21, 2015 at 9:22

Jim 007Jim 007

2201 gold badge3 silver badges8 bronze badges

Check filenames.

You might need to create a new database in phpmyadmin that matches the database you’re trying to import.

Mayur Birari

5,8278 gold badges33 silver badges61 bronze badges

answered Nov 21, 2012 at 15:23

blargblarg

3,72310 gold badges40 silver badges69 bronze badges

I had the same problem. I tried to create a table in mysql and got the same error. I restarted mysql server and ran the command and was able to create/migrate table after restating.

answered May 10, 2013 at 11:10

thekosmixthekosmix

1,68521 silver badges33 bronze badges

Today i was facing same problem. I was in very difficult situation but what id did i create a table with diffrent name e.g (modulemaster was not creating then i create modulemaster1) and after creating table i just do the rename table.

answered Jun 12, 2013 at 11:57

I encountered the same problem today. I was trying to create a table users, and was prompted that ERROR 1146 (42S02): Table users doesn't exist, which did not make any sense, because I was just trying to create the table!!

I then tried to drop the table by typing DROP TABLE users, knowing it would fail because it did not exist, and I got an error, saying Unknown table users. After getting this error, I tried to create the table again, and magically, it successfully created the table!

My intuition is that I probably created this table before and it was not completely cleared somehow. By explicitly saying DROP TABLE I managed to reset the internal state somehow? But that is just my guess.

In short, try DROP whatever table you are creating, and CREATE it again.

answered Apr 6, 2015 at 17:51

XinXin

4,2124 gold badges18 silver badges15 bronze badges

As pprakash mentions above, copying the table.frm files AND the ibdata1 file was what worked for me.

In short:

Shut your DB explorer client (e.g. Workbench).
Stop the MySQL service (Windows host).
Make a safe copy of virtually everything!
Save a copy of the table file(s) (eg mytable.frm) to the schema data folder (e.g. MySQL Server/data/{yourschema}).
Save a copy of the ibdata1 file to the data folder (i.e., MySQL Server/data).
Restart the MySQL service.
Check that the tables are now accessible, queryable, etc. in your DB explorer client.

After that, all was well. (Don’t forget to backup if you have success!)

answered Aug 17, 2016 at 23:46

SteveCinqSteveCinq

1,8901 gold badge16 silver badges22 bronze badges

Column names must be unique in the table. You cannot have two columns named asd in the same table.

answered Jun 14, 2011 at 10:32

OswaldOswald

30.9k3 gold badges43 silver badges68 bronze badges

run from CMD & %path%=set to mysql/bin

mysql_upgrade -u user -ppassword

answered Jun 14, 2011 at 11:04

Ravi ParekhRavi Parekh

4,9489 gold badges43 silver badges57 bronze badges

Recently I had same problem, but on Linux Server. Database was crashed, and I recovered it from backup, based on simply copying /var/lib/mysql/* (analog mysql DATA folder in wamp). After recovery I had to create new table and got mysql error #1146. I tried to restart mysql, and it said it could not start. I checked mysql logs, and found that mysql simply had no access rigths to its DB files. I checked owner info of /var/lib/mysql/*, and got 'myuser:myuser' (myuser is me). But it should be 'mysql:adm' (so is own developer machine), so I changed owner to ‘mysql:adm’. And after this mysql started normally, and I could create tables, or do any other operations.

So after moving database files or restoring from backups check access rigths for mysql.

Hope this helps…

thvwns

3,5383 gold badges43 silver badges57 bronze badges

answered Aug 23, 2013 at 8:32

The reason I was facing this was because I had two «models.py» files which contained slightly different fields.
I resolved it by:

deleting one of the models.py files
correcting references to the deleted file
then running manage.py syncdb

answered Nov 11, 2013 at 7:02

I got this issue after copying mytable.idb table file from another location. To fix this problem I did the following:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

Copy mytable.idb

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Restart MySql

answered Apr 13, 2014 at 20:34

l0panl0pan

4667 silver badges11 bronze badges

I had the same issue. It happened after windows start up error, it seems some files got corrupted due to this. I did import the DB again from the saved script and it works fine.

answered Oct 31, 2014 at 22:51

I had this problem because of a trigger not working..Worked after I deleted the trigger.

answered Aug 2, 2016 at 12:21

DauleDKDauleDK

2,9297 gold badges51 silver badges90 bronze badges

In my case, MySQL’s parameter; lower_case_table_names was configured = 0.

It causes queries related with using upper cases will not work.

answered Aug 9, 2017 at 6:25

hiroponhiropon

1,6152 gold badges18 silver badges41 bronze badges

For me it was a table name upper/lower case issue. I had to make sure that table case name matched in a delete query, table notifications was not the same as Notifications. I fixed it by matching table name case with query and what MySQLWorkbench reported.

What is wierd is that this error showed up in a worked sql statement. Don’t know what caused this case sensitivity. Perhaps an auto AWS RDS update.

answered Mar 16, 2018 at 15:43

KahitarichKahitarich

3752 silver badges7 bronze badges

if you are modifying mysql bin->data dir’s and after that, your database import will not works

so you need to close wamp and after that start wamp

now database import will work fine

answered Jan 15, 2021 at 19:03

Hassan SaeedHassan Saeed

5,8711 gold badge33 silver badges37 bronze badges

Make sure you do not have a trigger that is trying to do something with the table mentioned in the error. I was receiving Error Code: 1146. Table 'exampledb.sys_diagnotics' doesn't exist on insert queries to another table in my production database. I exported the table schemas of my production database then searched for instances of exampledb.sys_diagnotics the schema SQL and found a debugging insert statement I had added to a table trigger in my development environment but this debug statement had been copied to production. The exampledb.sys_diagnotics table was not present on my production database. The error was resolved by removing the debug statement in my table trigger.

answered May 4, 2022 at 19:33

Источник

MySQL database is a relational database system which contains tables, these tables are formally described and they contain data within them. The data could be accessed and modify with various ways and there is no need for changing the order of tables for it. Pretty cool, Isn’t it? But sometimes corruption or mishandling of the data can lead us to errors. Error 1146 in MySQL Table doesn’t exist is also one of those common errors which can take place during MySQL handling.

So, in this handout, I’ll elaborate MySQL Error 1146, the reason behind this error and how to resolve Bug? #1146 – Table ‘xxx.xxxxx’ doesn’t exist. So without wasting time, let’s get started.

Why Error 1146 in MySQL Takes Place?

There are multiple reasons and catalyst to this error. Some of the causes to error 1146 are stated below:

InnoDB crash and missing data files

As we all know that InnoDB is the transaction-safe (ACID compliant) storage engine for MySQL database, it offers multiple capabilities like Rollback, Commit and crash recovery for data of MySQL database. The InnoDB is also prone to corruption, so if it is not handled correctly there is a chance of crash of InnoDB. InnoDB is functional because of ibdata file and log file. It acts as a data dictionary to it. If by any reason these files go missing, there will be no chance of working InnoDB and MySQL will show you error 1146.

Improper directory accessing permissions

MySQL has a data storage directory where it stores all the database. Most of the time path is ‘/var/lib/mysql’. If the ownership and access permissions are not right and MySQL is not able to access this directory path then the error 1146 in MySQL will be shown.

Corruption in data tables

Tables of MySQL database can get corrupt due to several reasons like improper server shutdown, incomplete queries, user abuse, wrong formats, foreign key constraint error, etc. So if the table got corrupt the database can show MySQL error 1146.

.frm file missing

.frm file contains the format and structure of the database. If anyhow this file is not copied to the database directory or it gets deleted then there will be an error message for error code 1146.

Methods to Fix MySQL ERROR 1146 table doesn’t exist

To fix Bug? #1146 – Table ‘xxx.xxxxx’ doesn’t exist, we can use multiple remedies and DIYs like:

Restore Backup

This is the best alternative you should use. It will surely recreate all the lost tables from the database and MySQL code 1146 will also get solved but keep in mind that there should be a backup file to restore. So always keep the habit of creating backup time to time, it’s a good practice. Also, it resolve MySQL ERROR 1146 table doesn’t exist after backup.

Restart the Server

Try to restart the server if any improper server shutdown took place. There is a chance to get it back in working condition and removing error code. So that user access MySQL without any issue

Repair Database Tables

You can repair database tables using MySQL CLI. All you need to do is to follow the stated steps:

1. Using SSH, log in to the server.

2. From the command line, execute the following command:

mysql -u [username] -p

Note: Replace username with your username and remove the brackets.

3. Now enter your password for the username.

4. Again enter the command:

use [databasename];

Note: provide the name of the database without brackets.

5. Now execute the following command:

show tables;

6. Now repair table using following commands:

(a) Check for tables with error:

check table [tablename];

(b) Repair tables:

repair table [tablename];

7. Now quit using quit command.

Keep a copy of .frm file

You can keep a copy of .frm file and whenever the error 1146 arrises, you can paste the .frm file to the schema folder. It can fix error 1146.

Copy the ibdata file from backup

You should keep a copy of ibdata file as a backup so whenever the this MySQL error takes place you can paste it to the data directory of MySQL server.

Using Third Party Tools

If still, the error 1146 in MySQL takes place, you should go for a professional tool rather relying on the DIYs. You can use MySQL Data Recovery tool. It is the best tool to recover the corrupt tables and even fix MySQL ERROR 1146 table doesn’t exist after backup. Try the demo version of the solution from below button.

Watch this video tutorial for smooth use of MySQL Recovery Tool.

Conclusion

So, this is Error 1146 in MySQL ‘table doesn’t exist’. We discussed some quick remedies and DIYs to resolve this common MySQL error. It becomes really hard and disappointing when you face such errors cause these type of errors can lead you to lose all your valuable data.

Try your best and keeping the backup of data is the best precaution you can take. It will help you in such a critical situation to restore your MySQL database in the previous condition and it will also fix Bug? #1146 – Table ‘xxx.xxxxx’ doesn’t exist. So hope for the best and do it. Thanks fo reading this article. I hope you found it useful & interesting.

Источник

Содержание

How to resolve MySQL ‘1146 table doesn’t exist’ errors in your server
What causes MySQL ‘1146 table doesn’t exist’ error
How to fix MySQL ‘1146 table doesn’t exist’ error
ERROR 1146 (42S02): Table ‘information_schema.SCHEMATA’ doesn’t exist #1047
Comments
Issue:
Expected behavior:
Reproduce:
Relevant Code:
Как устранить неисправность InnoDB в базе данных MySQL
Проблема
Причина
Решение
I. Принудительное восстановление InnoDB
II. Копирование содержимого таблицы
III. Восстановление таблицы InnoDB
IV. Восстановление из резервной копии

How to resolve MySQL ‘1146 table doesn’t exist’ errors in your server

In our role as Support Engineers for web hosts, we manage servers with various services such as web, database, mail, control panels, FTP, etc.

MySQL is the most commonly used database server in Linux hosting and handling the databases and resolving the errors associated with it, is a common task that we perform.

A commonly noticed error in MySQL server is ‘1146 table doesn’t exist’. Today we’ll see what causes this ‘1146 table doesn’t exist’ error in MySQL and how to fix it.

Error : Table ‘mysql.innodb_index_stats’ doesn’t exist
status : Operation failed

What causes MySQL ‘1146 table doesn’t exist’ error

MySQL table errors happen due to many reasons, the major ones we’ve come across include:

InnoDB crash – When the InnoDB server crash due to any process load or user abuse, or if the server was not restarted properly, it can get corrupt and cause table errors to show up.
Missing ibdata file in the MySQL datadir – InnoDB has a data dictionary – the ibdata file and log files, which are crucial for InnoDB to function. If during migrations or restorations, these files go missing, it can prevent InnoDB tables from functioning right.
Improperly placed .frm files – In InnoDB, tables have ‘.frm’ files that define the table format. If these files get deleted or were missed to copy over to the proper database directory, then the tables can show errors.
Incorrect permissions and ownership of MySQL datadir – MySQL has a data directory, usually ‘/var/lib/mysql’ that stores the databases. If the permission and ownership of this directory is not adequate for MySQL to access it, errors would occur.
Corrupt tables or improper table names – If the database tables got corrupt due to improper server shut down or incomplete queries, or if the table name format is not correct, the ‘1146 table doesn’t exist’ error may show up.

How to fix MySQL ‘1146 table doesn’t exist’ error

Inorder to fix the error ‘1146 table doesn’t exist’, we adopt different techniques, after analyzing the root cause of the error.

Restart MySQL server – If the error has happened due to improper server shut down or MySQL service related errors, we restart the service and check if it fixes the issue. If the service doesn’t start properly, we further investigate and fix the error.
Repair the tables – MySQL has tools such as ‘myisamchk’ to repair corrupt databases and tables.
Backup restore – Restoring database backups is the final resort to get the tables back to working condition. We always configure and maintain the backups in our customers’ servers up to date, inorder to ensure that there is no data loss or down time due to unexpected crashes or errors.
Copy ibdata file – If the ‘ibdata’ file is missing, we copy it from the backup and restore it to the data directory for MySQL, after discarding the tablespace to avoid any corruptions or errors.
InnoDB crash recovery – In case where the backup is incomplete or ibdata file is also corrupt, we’ve still been able to recover the tables via our expert crash recovery methods. Read the post ‘Database crash rescue‘ to know more.

[ Use your time to build your business. We’ll take care of your servers. Hire Our server experts to resolve and prevent server issues. ]

At Bobcares, our 24/7 Web Support Specialists constantly monitor all the services in the server and proactively audit the server for any errors or corruption in them.

With our systematic debugging approach for service or other software errors, we have been able to provide an exciting support experience to the customers.

If you would like to know how to avoid downtime for your customers due to errors or other service failures, we would be happy to talk to you.

Источник

ERROR 1146 (42S02): Table ‘information_schema.SCHEMATA’ doesn’t exist #1047

Issue:

What seems to be going wrong?

docker exec -it bash
mysql -u root -p
show databases;

Expected behavior:

What should be happening instead?

see available databases or none? isn’t the container supposed to create it by default?

Reproduce:

How might we be able to reproduce the error?

Relevant Code:

The text was updated successfully, but these errors were encountered:

I resolved this error by running:
mysql_upgrade -u root -p —force

However, the next error whilst try to migrate the schema versions of Laravel is:
SQLSTATE[HY000] [2054] Server sent charset unknown to the client. default character set utf8mb4 collate utf8mb4_unicode_ci.

It seems the problem has to do with a bug in the driver in the version of PHP that comes with laradock?
https://bugs.php.net/bug.php?id=74461

This bug seems to be resolved in PHP1.7.5.

Hi, was having the same issue, i run the mysql_upgrade you posted and now i’m able to see databases. But i still have an issue of connecting to the database via sequel pro, using credentials i changed in .env

Are you facing same issue and have you been able to solve it?

Have you tried to using host=mysql?

If you are using the laradock repo you can spin up phpmyadmin:
docker-compose up -d nginx mysql phpmyadmin
then you can browse phpmyadmin at: http://localhost:8080

I have added 127.0.0.1 mysql in my hosts file, base on some post i read.
i just used phpmyadmin wth the following credentials and it worked:
username: laradock
password: secret
database: zoo (Collation: utf8mb4_0900_ai_ci)

Then i have a php file which i have this code in it.
$con = mysqli_connect(«127.0.0.1″,»laradock»,»secret»,»zoo»); var_dump($con);

this is the result i get:
Warning: mysqli_connect(): (HY000/2002): Connection refused in.

When i use «mysql» instead of «127.0.0.1», i get:
Warning: mysqli_connect(): Server sent charset (255) unknown to the client.

Try downgrading the MySQL version from 8.0 to 5.7 5083426 then rebuild the container.

Hi @Mahmoudz, I try downgrading MySQL to 5.7 and rebuild, but when up docker-machine I receive this:

I did the following to get mine working:

Removed image $ docker rmi laradock_mysql
Remove container $ docker rm laradock_mysql
Located DATA_SAVE_PATH=

/.laradock/data in .env file

Deleted mysql folder

Modified laradock/mysql/Dockerfile

Buil docker-compeer up -d mysql nginx

I hope I didn’t miss anything in the steps.

Changing the mysql container version to 5.7 from 8.0 didn’t fix this for me.

After lots of faffing I decided to start from scratch. Before building the containers for the first time ensure you have set the mysql version at laradock/mysql/Dockerfile to 5.7 as described at #1047 (comment).

Setting the version from mysql 8.0 to 5.7 caused lots of issues. At the moment it’s quicker to set the version before starting the build process.

solution:

/.laradock/data/mysql warning: it will delete your mysql exist data

docker-compose up —build mysql

question:

for this issue,i know i need clear mysql old data when i change mysql version, so i exec docker-compose down -v , but the error still exist, i realize the mysql container not use docker volume system , so i checked docker-compose.yml ,In there, i found a question:

for laradock old version, mysql use docker volume save data, example:

so, who is using the volume mysql ? I hope I didn’t miss anything for this config. is that a bug? @Mahmoudz

Источник

Как устранить неисправность InnoDB в базе данных MySQL

Проблема

Причина

Повреждения InnoDB часто связаны с неисправностью оборудования. Сохранение поврежденных страниц происходит в результате сбоев питания или повреждений памяти. Также эта проблема может возникать, если вы храните базы данных InnoDB в сетевом хранилище (NAS).

Решение

Существует несколько способов восстановить MySQL:

I. Принудительное восстановление InnoDB

Остановите mysqld и сохраните резервную копию всех файлов, расположенных в папке /var/lib/mysql/:

Добавьте опцию innodb_force_recovery в раздел [mysqld] в /etc/my.cnf. Эта опция позволит вам запустить mysqld и создать дамп базы данных.

ПРИМЕЧАНИЕ. Вы можете увеличить эту опцию до 5 или 6 — пока не получите оптимальный дамп.

Запустите службу mysqld:

Создайте дамп всех баз данных:

Если при создании дампа возникла следующая ошибка:
Incorrect information in file: ‘xxxxxxxx.frm’ when using LOCK TABLES»`

увеличьте значение innodb_force_recovery и повторите попытку. Если вы не можете создать дамп баз данных, попробуйте использовать способ II (скопировать содержимое таблицы) или III (восстановить из резервной копии).

Остановите mysqld и удалите поврежденные данные:

Удалите опцию innodb_force_recovery из файла /etc/my.cnf и запустите mysqld:

В результате этого будет восстановлена главная база данных «mysql» и движок баз данных InnoDB.
Восстановите базы данных из дампа:

II. Копирование содержимого таблицы

Остановите mysqld и сохраните резервную копию всех файлов, расположенных в папке /var/lib/mysql/:

Попробуйте создать копию:

Если получилось, удалите поврежденную таблицу и присвойте ее имя новой.

III. Восстановление таблицы InnoDB

Восстановление таблиц InnoDB необходимо в случае возникновения следующей ошибки

Или при попытке сделать дамп через mysqldump

Создать резервную копию через mysqldump не получится (из-за ошибки). Потребуется копирование файлов базы на уровне файловой системы:

Для того чтобы восстановить таблицы InnoDB, нам нужно узнать:

узнать структуру таблиц
иметь файлы с данными (имеется ввиду файлы на уровне файловой системы)

Таблица InnoDB на уровне файловой системы состоит из двух фалов:

файл .frm хранит в себе структуру таблицы;
файл .ibd собственно данные

выяснить структуру поврежденной таблицы;
создать новую базу;
создать в новой базе таблицу нужной структуры;
скопировать данные в новую таблицу из старой;
если данные окажутся поврежденными, можно попробовать восстановить их используя утилиту innochecksum

Применяем утилиту чтения структуры таблицы:

Также желательно узнать кодировку старой базы:

Создаем новую базу:

Создаем таблицу по выводу утилиты чтения структуры поврежденной таблицы:

Далее копируем данные:

Очищаем автоматически созданный файл
Копируем файл с данными с поврежденной таблицы
Импортируем данные
Проверяем корректность чтения данных

Далее можно импортировать восстановленную таблицу или базу целиком.

IV. Восстановление из резервной копии

Если приведенные выше инструкции не помогли, остается только восстановить базы данных из резервных копий.

Источник

Попытался сделать дамп (бэкап) БД через родную для MySQL утилиту mysqldump и получил ошибку:

Got error: 1146: Table `table_name` doesn't exist when using LOCK TABLES

Вместо table_name имя несуществующей таблицы. Т.е. сразу после введения в консоль/терминал команды:

mysqldump --user=root -p db_name > db_name.sql

получаю такую ошибку. Файл дампа создаётся, но он пустой, утилита mysqldump после выдачи этой ошибки перестаёт работать.

Попытки ухода от проблемы

Не стал обращать внимание на mysqldump и взял другие инструменты пытаясь убежать от проблемы, так сказать, решил применить альтернативные пути решения. Пробовал сделать дамп базы через менеджер баз данных phpMyAdmin и всё получилось, но при импорте (поднятии) дампа возникли ошибки. Так же пробовал сделать тамп через родной для MySQL графический менеджер БД MySQL Workbench, но он тоже стал ругаться и выдавать эту обишку ибо он так же пользуется утилитой командной строки mysqldump при экспорте БД. Пробовал экспортировать дамп БД так же при помощи Sypex Dumper, он сперва вроде работал, но потом тоже выдал аналогичную ошибку. Короче говоря зря я только тратил время с этими альтернативными инструментами работы с БД. Если не работает родной mysqldump, то и другие программы врядли помогут ибо с базой что-то не так и надо разбираться.

Попытки решения проблемы

Что же это за «doesn’t exist when using LOCK TABLES» такой. Придётся разобраться. Если перевести текст сообщения об ошибке, то в нём говорится примерно следующее: «Таблица `table_name` не существует при использовании команды LOCK TABLES». Т.е. не была найдена указанная таблица, что понятно, ведь её никто там не создавал и быть её не должно.

Если посмотреть базу через разные графические менеджеры БД вроде браузерного phpMyAdmin или десктопного MySQL Workbench, то такой таблицы в базе действительно нет и не должно быть, но СУБД MySQL почему-то считает, что она там есть или должна быть, однако если посмотреть базу через родной консольный менеджер БД mysql (MySQL monitor), то такая таблица там будет в общем списке таблиц. Надо разбираться.

Поискал ответы на свои вопросы в служебной таблице information_schema, но это ни к чему не привело. Сделал пакетную проверку и восстановление всех таблиц базы данных через родную утилиту mysqlcheck, но это не помогло. При проверке утилита так же нашла эту несуществующую таблицу и стала ругаться, что она не найдена, но работу доделала до конца:

Repairing tables
table_name
Error : Table 'table_name' doesn't exist
status : Operation failed

Решение проблемы

Воспользовался стандартным родным консольным менеджером БД, который так и называется mysql, он же полностью MySQL monitor. Зашёл под нужным пользователем БД, выбрал базу, вывел список таблиц базы и оказалось в этом списке действительно есть та самая несуществующая таблица, которая была указана в тексте сообщения об ошибке. Так же при попытке создать таблицу с таким именем получаешь сообщение об ошибке, что такая таблица уже существует. Решил посмотреть что же есть в этой таблице. Получил сообщение об ошибке, что такой таблицы не существует, что не удивительно, ведь её и не должно существовать, но СУБД MySQL считает, что она есть и выводит её в общем списке таблиц. Решил удалить эту таблицу и тоже получил сообщение, что такой таблицы нет и удалять нечего. После этого вновь запросил список всех таблиц базы данных и о чудо, это несуществующей таблицы в списке больше нет.

Таким образом, что бы решить проблему «Got error: 1146: Table `table_name` doesn’t exist when using LOCK TABLES» при работе с БД надо пользоваться родным консольным менеджером БД MySQL monitor (mysql). Попытайтесь сперва создать таблицу с таким именем и получите сообщеине об ошибке, что такая таблица уже есть в БД. Попытайтесь удалить эту таблицу и получите сообщение, что её и так нет. Во время одного из этих действий СУБД MySQL ещё раз проверит базу и убедится, что такой таблицы нет и вычеркнет её из мета информации БД, т.е. забудет про эту несуществующую таблицу, не будет выводить её в списке всех таблиц и не будет выводить эту ошикбу. Скорее всего проверка целостности базы происходит при попытке удаления этой несуществующей таблицы, поэтому пробовать создавать её и не нужно. Так же, возможно, пользоваться консольным MySQL monitor тоже не обязательно и можно послать SQL-запрос СУБД на удаление этой таблицы откуда удобно, просто в MySQL monitor эта таблица сперва отображается в общем списке а в остальных менеджерах баз данных не показывается. В общем точно не знаю что в моём алгоритме действий лишнее, а что необходимое, я лишь говорю как я решил эту проблему. Задача нетривиальная и попытаться воссоздать эту ошибку с целостностью базы ещё раз для учебных целей оказалось не просто. У меня был лишь один проход решения проблемы, поэтому, что точно её решило я не знаю.

Для тех кто всё ещё не понял, скажу кратко. Просто воспользуйетесь консольным MySQL monitor и через него попробуйте удалить эту несуществующую таблицу. При запросе удаления СУБД MySQL проверит базу, поймёт, что такой таблицы действительно нет и всё будет в порядке. Проблема решена, вот и всё.

На всякий случай прикладываю список консольных команд и SQL-запросов, которые я использовал в ходе решения этой проблемы. Хотел их писать сразу по ходу изложения, но решил, что это не нужно для тех кто и так знает, а для остальных (забывчивых) напишу список ниже, названия файлов, пользователей, таблиц и баз, естественно взяты для примера, подставляйте свои.

Для начала консольная команды.
Попытка сделать дамп базы через утилиту mysqldump:

mysqldump --user=root -p db_name > db_name.sql

Пакетная проверка и восстановление всех таблиц базы данных через родную утилиту mysqlcheck:

mysqlcheck --user=USER --password=PASSWORD --auto-repair --check --all-databases

Вход в консольный менеджер баз данных MySQL monitor с указанием данных:

mysql --user=USER --password=PASSWORD

Далее работает непосрдественно с БД, поэтому теперь пойдут SQL-запросы.
Просмотр всех доступных для пользователя (для просмотра) баз данных:

SHOW DATABASES;

Выбор необходимой рабочей базы данных для работы с ней:

USE <db_title>;

Просмотр всех доступных для пользователя таблиц выбранной базы данных:

SHOW TABLES;

Просмотр содержимого указанной таблицы (с лимитом записей/строк):

SELECT * FROM table_title LIMIT 100;

Удаление таблицы из базы данных:

DROP TABLE table_title;

Следует понимать, что несуществующая таблица, это ошибка структуры базы данных, т.е. надо копать в эту сторону, восстанавливать структуру БД, а не таблиц.

Если моё решение не помогло, то можно попробовать воспользоваться утилитой «innodb tools» (Percona Data Recovery Tool for InnoDB) (https://code.google(точка)com/archive/p/innodb-tools/). Ещё есть решение описанное здесь (http://adw0rd(точка)com/2009/07/02/recovery-innodb/), но там народ в комментариях говорит, что это не всегда помогает.

На этом все, всем спасибо за внимание.

Источник