我无法删除数据库：MySQL的：错误删除数据库（错误13;错误号17;错误号39）
mysql> drop database mydb; ERROR 1010 (HY000): Error dropping database (can't rmdir './mydb', errno: 39)
目录DB/MYDB在MySQL树存在，但没有表：
# ls -l db/mydb -rw-rw---- mysql mysql HIS_STAT.MYD -rw-rw---- mysql mysql HIS_STAT.MYI
我该怎么办？
的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中具有其数据，并允许在那里提供完整的R/W，但MySQLd来自不同的分发或构建，并且它实际上将其数据存储在其他地方（例如：/var/lib/mysql5/data/**而不是/var/lib/mysql/**） 。所以你看到的是该目录有正确的权限和所有权，但它仍然给Errno 13，因为apparmor/selinux将不允许访问它。
要验证，请检查系统日志是否存在安全违规，手动检查apparmor/selinux配置，和/或模拟mysql用户并尝试进入基本var目录，然后递增cd直到您进入目标目录，并运行如touch aardvark && rm aardvark。如果权限和所有权匹配，但上述情况会导致访问错误，则可能是安全框架问题。
该代码表示 “目录不为空”。该目录包含一些隐藏的文件MySQL一无所知。对于非隐藏文件，请参阅Errno 17.解决方案是相同的。
此代码表示“文件存在”。该目录包含一些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)
移动文件（县）外（或删除，如果没有必要），然后重试。 另外，确定它们为什么在第一个地方创建 - 它可能指向某些应用程序中的错误。或者更糟：见下文......
这发生在Linux系统与WordPress安装。不幸的是，客户受到时间限制，我既不能对磁盘进行镜像，也不能进行真正的取证 - 我重新安装了整个机器，并在此过程中更新了Wordpress，因此我只能说我是，几乎某些他们做了通过this plugin。
症状：在mysql数据目录中包含三个文件扩展名为PHP。 等一下，什么？！？ - 文件内部有大量的base64代码，它被传递到base64_decode,gzuncompress和[eval()][2]。 Aha。当然，这些只是第一次尝试，不成功的尝试。该网站一直很好，真正pwn3d。如果你发现在你的MySQL数据目录文件是造成错误17，与file实用查看或与反病毒扫描它
左右。或者目视检查其内容。 不要以为它存在一些无害的错误。
在这种情况下，受害者（他有一些朋友“做保养”）绝不会猜到他会被黑客攻击，直到维修/更新/不管脚本跑了DROP DATABASE（不要问我为什么 - 我我不知道，即使我想知道）并得到一个错误。从CPU负载和系统日志消息中，我相当肯定主机已经成为垃圾邮件群。
如果rsync或相同版本的但不同平台或文件系统两个MySQL安装之间复制如Linux或者Windows（这是气馁，有风险，但很多做尽管如此），并且与不同的case sensitivity设置不同，您可能会无意中最终得到两个版本（数据，索引或元数据）;说Customers.myi和Customer.MYI。 MySQL使用其中的一个，而对另一个则一无所知（这可能会过时并导致灾难性的同步）。当删除数据库时，这种情况也发生在许多备份方案中，DROP将因为存在额外文件（或那些额外文件）而失败。如果发生这种情况，您应该能够识别需要从文件时间手动删除的过时文件，或者从他们的案例方案与大多数其他表不同的事实中识别出来。
在一般情况下，你可以通过检查my.cnf文件（/etc/my.cnf，/etc/sysconfig/my.cnf，/etc/mysql/my.cnf在Linux上; 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)
对我来说，这是由于考虑“lower_case_table_names”参数。
当我尝试删除由lower_case_table_names参数组成的大写字母表名称的数据库时，错误编号39被启用。
这是通过将小写字母参数更改恢复为以前的状态来解决的。
是的。这可能是由于该设置。 BUt，恢复该设置不是正确的解决方案，但妥协恕我直言。 –
这解决了我的问题。你可以恢复它，删除你的数据库并恢复它... – c4k
是的，这是我的原因以及 –
只需进入到/ opt/LAMPP在/ var/mysql的
那里你可以找到你的名字datavase。 打开该文件夹。删除其中的任何文件
现在来到phpmyadmin并删除该数据库
听起来像一个权限问题。你能发布完整的'ls -l'输出吗？ –
@Chris Henry：我已经更新了＃ls -l mydb –