What is error 1146 in mysql

mysqldump error 1146 table doesn’t exist – How to fix it

by Nicky Mathew | May 26, 2021

We may come across the mysqldump error 1146 table doesn’t exist while we perform the database dump.

As part of our Server Management Services, we assist our customers with several MySQL queries.

Today, let us see how to fix this error in Plesk and Directadmin.

mysqldump: Got error: 1146: Table doesn‘t exist

Recently, while performing the database dump, some of our users notice the error:

In order to check, we go to MySQL:

Then we query for the tables:

Here, we can find the table. However, when we query for that particular table:

We get the same error:

We can try to repair it via:

However, the error may prevail:

The major causes of this can be:

  • InnoDB tablespace might have been deleted and recreated but corresponding .frm files of InnoDB tables from the database directory were not removed, or .frm files were moved to another database
  • Incorrect permissions and ownership on table’s files in MySQL data directory
  • A corrupt table data.

How to fix it?

Moving ahead, let us see how our Support Techs fix this error in both Plesk and Directadmin.


  1. Initially, we try to connect to the server using SSH
  2. Then we try to use —skip-lock-tables parameter with mysqldump to skip lock tables.
    For example,

If it does not help, we check permissions and ownership on the table’s files in the MySQL data directory for the database that fails to dump. It should be mysql for both owner and group:

    Find data dir location:
  • Check permissions:
  • Fix permissions:
  • If it is still not possible, we try to repair the table in the error using the native MySQL repair tool:

    Note: We need to replace the with table name in the error message.

    If the issue still persists, most probably ibdata* file does not have the info about the table. However, the orphaned .frm files still persist on the file system. We remove it:

      To verify that table is corrupt or not, we run:

    If this command fails with the error, it means that ibdata* does not have the information about the table and we need to remove the .frm file.

  • To do so, we browse to the database directory /var/lib/mysql/example_db/ and move .frm file:
  • If these options fail and we have no valid backups to restore, the only available option to save the database is to dump it with the innodb_force_recovery option
  • Directadmin

    Suppose, we get the error for the User database and Table:

      In this case, we check to see if there are any other data files, or if it’s just the .frm file:

    If it’s just the table .frm file, then the rest of the data is likely lost. However, we may be able to rebuild the table.

    To do so, we need to read the .frm file. We need the mysqlfrm tool for that, eg: yum install mysql-utilities. Once we install it, we check if it can be read:

    READ  Realme gt neo прошивка на глобальную версию

    This can output the full CREATE TABLE syntax. We save this somewhere, until the end of the last ; character.

    Note, we can either delete the “CHARACTER SET “, or change it to the correct charset.

  • Then, we remove the broken table. To do so, we login to /phpMyAdmin and run the query:
  • Finally, we run the CREATE TABLE query from above, to rebuild the table.
  • [Finding it hard to fix? We’d be happy to assist you]


    In short, we saw how our Support Techs fix the MySQL error for our customers.


    Never again lose customers to poor server speed! Let us help you.

    Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.


    MYSQL replication error 1146 – Easy way to fix it !

    by Anjaly Baby | Nov 12, 2019

    Are you trying to figure out MYSQL replication error 1146?

    This is a generic error when we set up the MYSQL replication.

    Also, the main reasons for the MYSQL replication error 1146 due to invalid MySQL queries or non-existing SQL queries.

    At Bobcares, we often get requests to solve such MYSQL replication errors as part of our Server Management Services.

    Today, let’s analyze the cause and see how our Support Team fix it for our customers.

    What is MYSQL replication?

    Normally, it is a process that enables data from one MySQL database server (the master) to copied automatically to one or more MySQL database servers (the slaves). However, general principles of setting up the MySQL master-slave replication on the same machine are the same for all operating systems.

    It is simply copying data from one server to another server. So all the users can share the same data without any inconsistency.

    The main Advantages of MySQL Replication includes,

    1. High Performance
    2. Backup and Security
    3. Remote Access

    Reasons for MYSQL replication error 1146.

    This is a generic error when we discover the slave MySQL server is having a problem replicating data from the master. The main reason for this error is due to invalid MySQL queries or non-existing mysql queries.

    Recently one of our customers contacted us with this MYSQL error when he tried to set-up the MYSQL replication. Then he checked the slave status and returned the error code like this.

    MYSQL replication error 1146

    The above error message shows that the table “db3.table3” does not exist in the slave database. To fix this error, we just simply ignore this error and resume the replication.

    How we fix the MYSQL replication error 1146.

    So far, we discuss the MYSQL replication and reasons for the replication error 1146. Now let’s see how our Support Engineers fix this error for our customers.

    Solution 1

    To fix the replication error we follow the below steps.

    1. First, we log into the MYSQL.

    2. On the MySQL shell, we check the slave status.

    The sample result as follows.

    If anyone of the Slave_IO_Running or Slave_SQL_Running is set as NO, it means the replication is broken.

    So, we start to repair the MYSQL replication.

    3. For that, we stop the slave from replication, using the below command.

    4. Next, we tell the slave to simply skip the invalid SQL query. So we use the below command.

    This query tells the slave to skip one query (which is the invalid one that caused the replication to stop). If we like to skip two queries, we use the following code instead.

    5. Again, we start the slave.

    6. After that, we check if replication is working again.

    READ  Sony kd 49xe7096 прошивка

    Both Slave_IO_Running and Slave_SQL_Running are set to Yes now. And the replication is running without any error.

    Then we leave the MySQL shell.

    Solution 2

    Recently another customer contacted us with the MYSQL replication error. He also tried to set up the MYSQL replication and returns the error as follows.

    Next, he tried mysql_upgrade` and it looked already up to date, so he tried –force, which gave:

    Then he checked the dB/mysql folder and found that the .frm and .ibd is already existing.


    Then we just removed the files and recreated the table, which solved the error.

    1. So we go to the mysql folder and drop the following files using the command.

    Also, to create the table we use the command:

    2. Then, we stop and start the slave

    This fixes the error.

    [Need more assistance for MYSQL replication error 1146? We’ll help you]


    In short, the main reasons for the MYSQL replication error 1146 is invalid MySQL queries or non-existing SQL queries. Today, we saw how our Support Engineers fix this error for our customers.


    Never again lose customers to poor server speed! Let us help you.

    Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

    1 Comment

    I too had this 1146 error regarding creating tables in the DB.
    Then I manually created the DB and the tables related to the error.
    After that, I executed `STOP SLAVE` and `START SLAVE`.
    Finally, it auto-synced all the data from the other instance.


    Борьба с ошибкой 1146 «Table `table_name` doesn’t exist when using LOCK TABLES» в СУБД MySQL

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

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

    получаю такую ошибку. Файл дампа создаётся, но он пустой, утилита 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, но это не помогло. При проверке утилита так же нашла эту несуществующую таблицу и стала ругаться, что она не найдена, но работу доделала до конца:

    READ  Kisan k2 обновление прошивки

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

    Воспользовался стандартным родным консольным менеджером БД, который так и называется 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:

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

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

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

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

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

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

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

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