MySQL：错误删除数据库（errno 13; errno 17; errno 39）
我失败了一个数据库：
mysql> drop database mydb; 错误1010（HY000）：错误下降数据库（不能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
我该怎么办？
Errno 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 ，并允许在那里有完整的R / W，但是MySQLd来自不同的分发或构build，并且实际上将其数据存储在其他地方 （例如： /var/lib/mysql5/data/**而不是/var/lib/mysql/** ）。 所以你看到的是该目录具有正确的权限和所有权 ，但它仍然给Errno 13，因为apparmor / selinux将不允许访问它。
要validation，请检查系统日志是否存在安全违规，手动检查apparmor / selinuxconfiguration，和/或模拟mysql用户并尝试进入基本var目录，然后递增cd直到您进入目标目录，然后运行类似touch aardvark && rm aardvark 。 如果权限和所有权匹配，然而上述情况会导致访问错误，则可能是安全框架问题。
Errno 39
这个代码的意思是“目录不是空的”。 该目录包含一些隐藏的文件，MySQL一无所知。 对于非隐藏文件，请参阅Errno 17.解决scheme是相同的。
Errno 17
这个代码的意思是“文件存在”。 该目录包含一些MySQL不认为要删除的MySQL文件。 这样的文件可能已经由SELECT ... INTO OUTFILE "filename"; 命令其中filename没有path。 在这种情况下，MySQL进程在当前工作目录中创build它们（在OpenSuSE 12.3上的MySQL 5.6上testing）是数据库的数据目录 ，例如/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)
将文件移到外面（如果不需要，也可以删除）并重试。 此外，确定为什么他们是在第一个地方创build的 – 它可能指向一些应用程序中的错误 。 或更糟糕的是：见下面…
更新：错误17作为利用标志
这发生在一个安装了Wordpress的Linux系统上。 不幸的是，客户受到时间限制，我既不能对磁盘进行镜像，也不能做一个真正的取证 – 我重新安装了整个机器，Wordpress在这个过程中得到了更新，所以我只能说我几乎可以肯定他们是通过这个插件 。
症状 ： mysql数据目录包含三个扩展名为PHP的文件。 等等，什么？！？ – 在文件里面有大量的base64代码被传递给base64_decode ， gzuncompress和[eval()][2] 。 啊哈 当然，这只是第一次尝试，不成功的尝试。 该网站已经很好，真正pwn3d。
所以如果你在你的mysql数据目录中find一个导致错误17的file ， 请用file工具检查它，或者用防病毒软件扫描它。 或者目视检查其内容。 不要以为是一些无害的错误。
在这种情况下，受害者（他有一些朋友“做维护”）将永远不会猜到他被黑客攻击，直到维护/更新/任何脚本运行DROP DATABASE （ 不要问我为什么 – 我甚至不确定我想知道 ），并得到一个错误。 从CPU负载和系统日志消息来看，我相当肯定主机已经成为垃圾邮件群。
还有一个错误17
如果您在同一版本的两个MySQL安装之间进行rsync或复制， 但是不同的平台或文件系统 （如Linux或Windows）（这是不鼓励的，风险很高的，但很多都是这样做的），尤其是不同的大小写敏感设置，最终得到相同文件的两个版本 （数据，索引或元数据）; 说Customers.myi和Customer.MYI 。 MySQL使用其中的一个，对另一个则一无所知（这可能会过时并导致灾难性的同步）。 当删除数据库时，这也发生在许多mysqldump ... | ... mysql mysqldump ... | ... mysql备份scheme， DROP将失败，因为额外的文件（或那些额外的文件）存在。 如果发生这种情况，您应该能够识别需要从文件时间手动删除的废弃文件，或者从他们的案例scheme与大多数其他表格不同的事实中识别出来。
find数据目录
一般情况下，您可以通过检查my.cnf文件（Linux上的/etc/my.cnf ; MySQL中的my.ini程序文件目录在Windows中），在[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。
这是通过将小写参数更改恢复到之前的状态来解决的。
只需转到/ opt / lampp / var / mysql
那里你可以find你的datavase名字。 打开该文件夹。 如果有文件在里面
现在来到phpmyadmin并删除该数据库
