快速修复

如果你只是想删除数据库无论什么（但 * 请 * 首先阅读整个职位：错误是有原因的，知道原因可能很重要!），您可以：

使用命令SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';查找数据目录
停止MySQL服务器（例如，Linux上的service mysql stop或rcmysqld stop或类似命令，Windows上的NET STOP <name of MYSQL service, often MYSQL57 or similar>或通过SERVICES.MSC）
转到datadir（这是您应该调查的地方;见下文）
删除与数据库同名的目录
再次启动MySQL服务器并连接到它
执行DROP数据库
就是这样!

错误原因13

MySQL对mydb文件夹所在的父目录没有写权限。
检查一下

ls -la /path/to/data/dir/         # see below on how to discover data dir
ls -la /path/to/data/dir/mydb

在Linux上，如果你混合使用MySQL和AppArmor/SELinux软件包，也会发生这种情况。AppArmor希望mysqld的数据存储在/path/to/data/dir中，并允许在/path/to/data/dir中完全读写，但MySQLd来自不同的发行版或构建版本，它实际上将数据存储在其他地方（例如：/var/lib/mysql5/data/**而不是/var/lib/mysql/**）。因此，您看到的是该目录具有正确的权限和所有权，但它仍然给出Errno 13，因为apparmor/selinux不允许访问它。
为了验证，检查系统日志是否存在安全违规，手动检查apparmor/selinux配置，和/或模拟mysql用户并尝试转到基本var目录，然后递增cd直到您到达目标目录，并运行类似touch aardvark && rm aardvark的命令。如果权限和所有权匹配，但上述命令产生访问错误，则可能是安全框架问题。

"易修复"被视为有害*

我在"Maven论坛"上偶然发现了一个"简单的解决办法"（* 不是 * Stack Overflow，谢天谢地），我有时候找到的解决Web和FTP问题的"方法"--chown 777。请永远不要这样做。对于那些还不知道的人，777（或775，或666）不是MySQL程序员 * 忘记应用 * 或 * 不想让您知道 * 的神奇数字。而777意味着"我在此同意每个人对我的东西做任何他们想做的事情，直到并包括像执行二进制或shell脚本一样执行它"。通过这样做（很可能你 * 不会被允许 * 在一个配置合理的系统上这样做），

你冒着几个有安全意识的程序 * 拒绝再运行 * 的风险（例如，如果你对你的SSH密钥做了这样的事情，再见SSH连接;等等），因为他们意识到他们现在处于不安全的环境中。
你允许任何人以任何级别访问系统来读取 * 和写入 * 你的数据，不管MySQL允许与否，* MySQL自己不知道 *-也就是说，它有可能悄悄地破坏整个数据库。
上述 * 可能 * 有时会做，在 * 极端可怕的困境，由绝望和知识渊博的人，以获得访问一个否则无法访问拧MySQL安装再次（即，即使mysqladmin也不再授予本地访问），并且将在事情恢复正常时立即撤销-这不是永久性的改变，即使在那时 *。而且它也不是"一个奇怪的技巧，能够下降我的DB"的修复。

（不用说，这几乎从来都不是解决任何网络或FTP问题的真正方法。"最近，妻子的钥匙打不开前门，她不能进我们家"的解决方法是"检查钥匙或修理或更换锁";公认的更快的chown 777是"只要让前门大开!小菜一碟!最坏的情况会发生什么？"）

错误原因39

这段代码表示"目录不为空"。该目录包含一些MySQL一无所知的隐藏文件。对于非隐藏文件，请参见Errno 17。解决方案是相同的。

错误原因17

这段代码表示"file exists"。该目录包含一些MySQL不想删除的MySQL文件。这些文件可能是由SELECT ... INTO OUTFILE "filename";命令创建的，而filename没有路径。在这种情况下，MySQL进程在当前工作目录中创建这些文件，即（在OpenSuSE 12.3上的MySQL 5.6上测试）是数据库的 * 数据目录 *，例如/var/lib/mysql/data/nameofdatabase。
重现性：

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1676
Server version: 5.6.12-log openSUSE package
[ snip ]    

mysql> CREATE DATABASE pippo;
Query OK, 1 row affected (0.00 sec)

mysql> USE pippo;
Database changed
mysql> SELECT version() INTO OUTFILE 'test';
Query OK, 1 row affected (0.00 sec)

mysql> DROP DATABASE pippo;
ERROR 1010 (HY000): Error dropping database (can't rmdir './pippo/', errno: 17)

-- now from another console I delete the "test" file, without closing this connection
-- and just retry. Now it works.

mysql> DROP DATABASE pippo;
Query OK, 0 rows affected (0.00 sec)

将文件移出（或删除不需要的文件）并重试。此外，确定最初创建这些文件的原因-它可能指向某些应用程序中的错误。或者更糟：见下文......

更新：错误17作为漏洞利用标记

这发生在一个安装了WordPress的Linux系统上。不幸的是，客户的时间有限，我既不能镜像磁盘，也不能做真正的取证-我重新安装了整个机器，WordPress在这个过程中得到了更新，所以我只能说，我 * 几乎 * 肯定他们是通过this plugin完成的。

症状：mysql数据目录包含三个扩展名为PHP的文件. * 等等，什么？！？* --在这些文件中有大量的base64代码，这些代码被传递给base64_decode，gzuncompress和[eval()][2]. * 啊哈 *.当然，这只是第一次尝试，不成功的几次.这个网站已经很好地和真正的pwn 3d.

所以如果你在mysql数据目录中发现一个文件导致错误17，用file工具检查或者用杀毒软件扫描它。或者目测它的内容。不要以为它是因为一些无害的错误而存在。
（不用说，要目视检查文件，* 切勿双击它）。
这个案例中的受害者（他有一个朋友“做维护”）永远不会猜到他被黑客攻击了，直到一个维护/更新/任何脚本运行了一个DROP DATABASE（不要问我为什么-我甚至不确定我想知道 *），并得到了一个错误。从CPU负载和系统日志消息来看，我相当肯定主机已经成为一个垃圾邮件场。

又一个错误17

如果您在两个版本相同 * 但平台或文件系统不同 *（如Linux或Windows）的MySQL安装之间进行rsync或复制（这是不鼓励的，也是有风险的，但许多人还是这样做），特别是使用不同的case sensitivity设置，您可能会意外地得到同一文件（数据、索引或元数据）的两个版本;比如Customers.myi和Customer.MYI。MySQL使用其中一个，而对另一个一无所知（这可能是过时的，并导致灾难性的同步）。当删除数据库时，这在许多mysqldump ... | ... mysql备份方案中也会发生，DROP将失败，因为存在额外的文件（或 * 那些 * 额外的文件）。如果发生这种情况，您应该能够从文件时间或者从它们的大小写方案与大多数其他表不同的事实中识别出需要手动删除的过时文件。

查找数据目录

通常，您可以通过检查my.cnf文件（Linux上为/etc/my.cnf、/etc/sysconfig/my.cnf、/etc/mysql/my.cnf;my.ini（位于Windows中的MySQL程序文件目录中），在[mysqld]标题下，显示为datadir。
或者，您可以要求MySQL本身：

mysql> SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.00 sec)

8条答案

按热度按时间

piwo6bdm1#

赞(0）回复(0）举报 2023-01-29

t5zmwmid2#

在我的例子中，这是由于'lower_case_table_names'参数。
当我试图删除由大写表名和lower_case_table_names参数组成的数据库时，抛出了错误号39。
通过将小写参数更改恢复到以前的状态，可以修复此问题。

wfypjpf43#

只需转到/opt/lampp/var/mysql
您可以在那里找到您的database名称。打开该文件夹。删除其中的任何文件
现在转到phpmyadmin并删除database

avwztpqn4#

至于ERRORCODE 39，您可以直接删除磁盘上的物理表文件。位置取决于您的操作系统发行版和设置。在Debian上，它通常位于/var/lib/mysql/database_name/下。

rm -f /var/lib/mysql/<database_name>/

然后从您选择的工具或使用以下命令删除数据库：

DROP DATABASE <database_name>

0h4hbjxa5#

我使用了MySQL的XAMP服务器，但在删除数据库时遇到了以下问题

#1010 - Error dropping database (can't rmdir '.\database_name', errno: 41 "Directory not empty")

我想使用SQL查询删除，但收到上述错误
我打开XAMP安装程序文件夹“xamp\mysql\data”，其中有数据库架构文件夹，如database_name1、database_name2等
只需删除名称与database_name相同的文件夹并再次打开MySQL，数据库/模式已成功删除。

isr3a4wc6#

我是这样解决的：

mysql> DROP DATABASE mydatabase;
ERROR 1010 (HY000): Error dropping database (can't rmdir '.\mydatabase', errno: 13)
mysql>

我去删除这个目录：C:\...\UniServerZ\core\mysql\data\mydatabase .

mysql> DROP DATABASE mydatabase;
ERROR 1008 (HY000): Can't drop database 'mydatabase'; database doesn't exist

vxqlmq5t7#

在我的例子中，一个不属于数据库的附加文件在数据库文件夹中。Mysql在删除所有触发错误的表后发现该文件夹不为空。我删除了该文件，删除数据库工作正常。

qvtsj1bj8#

在Linux中，只需进入“/var/lib/mysql”右键单击并（以管理员身份打开），在mysql文件夹中找到与您的数据库名称对应的文件夹并删除它。

MySQL：删除数据库时出错(errno 13;错误编号17;错误编号39)