MySQL：刪除數據庫時出錯（errno 13；errno 17；errno 39）

Question

我未能刪除數據庫：

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

我應該怎么辦？

Answer 1

快速解決

如果您無論如何只想刪除數據庫（但請先閱讀整篇文章：錯誤是有原因的，了解原因可能很重要！），您可以：

• 使用命令SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';查找數據目錄SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
• 停止 MySQL 服務器（例如，Linux 上的service mysql stop或rcmysqld stop或類似命令， NET STOP <name of MYSQL service, often MYSQL57 or similar>或通過 Windows 上的SERVICES.MSC ）
• 轉到數據目錄（這是您應該調查的地方；見下文）
• 刪除與數據庫同名的目錄
• 再次啟動 MySQL 服務器並連接到它
• 執行 DROP DATABASE
• 而已！

錯誤 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 來自不同的發行版或構建，並且它實際上將其數據存儲在其他地方（例如： /var/lib/mysql5/data/**而不是/var/lib/mysql/** ）。 所以你看到的是該目錄具有正確的權限和所有權，但它仍然給出 Errno 13，因為 apparmor/selinux 不允許訪問它。

要驗證，請檢查系統日志是否存在安全違規，手動檢查 apparmor/selinux 配置，和/或模擬 mysql 用戶並嘗試轉到基本 var 目錄，然后逐步 cd 直到您進入目標目錄，然后運行類似touch aardvark && rm aardvark 。 如果權限和所有權匹配，但上述內容產生訪問錯誤，則很可能是安全框架問題。

“EASY FIX”被認為是有害的

我偶然發現了“專家論壇”（不是Stack Overflow，謝天謝地）上建議的“簡單修復”，我有時會為 Web 和 FTP 問題找到相同的“修復”—— chown 777 。 請永遠不要這樣做。 對於那些還不知道的人來說，777（或 775 或 666）並不是一個神奇的數字，MySQL 程序員不知何故忘記應用自己，或者不想讓您知道。 每個數字都有一個含義，777 的意思是“我在此同意每個人對我的東西做任何他們想做的事情，直到並包括像執行二進制或 shell 腳本一樣執行它”。 通過這樣做（並且很可能不允許您在配置合理的系統上執行此操作），

• 你冒着幾個安全意識程序拒絕運行的風險（例如，如果你對你的 SSH 密鑰這樣做，再見 SSH 連接等），因為他們意識到他們現在處於不安全的環境中。
• 您實際上允許任何對系統具有任何級別訪問權限的人都可以讀取和寫入您的數據，無論 MySQL 是否允許， MySQL 本身都不知道- 即可以悄悄地破壞整個數據庫。
• 有時，絕望和知識淵博的人可能會在極其可怕的困境中完成上述操作，以再次訪問原本無法訪問的錯誤 MySQL 安裝（即，即使mysqladmin不再授予本地訪問權限），一旦事情發生，將立即撤消恢復正常 - 這不是永久性的變化，即使如此。 並且它不是“能夠刪除我的數據庫的一個奇怪技巧”的解決方案。

（不用說，它幾乎從來都不是解決任何 Web 或 FTP 問題的真正方法。“最近，妻子的鑰匙無法打開前門，她無法進入我們家”的解決方法是“檢查鑰匙或修理或更換鎖'；公認更快的chown 777是“讓前門大開！輕松！可能發生的最糟糕的事情是什么？”）

錯誤 39 的原因

此代碼的意思是“目錄不為空”。 該目錄包含一些 MySQL 一無所知的隱藏文件。 非隱藏文件見Errno 17，解決方法同上。

錯誤 17 的原因

此代碼表示“文件存在”。 該目錄包含一些 MySQL 文件，MySQL 不想刪除這些文件。 此類文件可能是由SELECT ... INTO OUTFILE "filename";創建的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 在此過程中得到了更新，所以我只能說我幾乎可以肯定他們是通過這個完成的插件。

症狀： mysql數據目錄包含三個擴展名為 PHP 的文件。 等等，什么？！？ - 在文件中，有大量 base64 代碼被傳遞給base64_decode 、 gzuncompress和[eval()][2] 。 啊哈。 當然，這些只是第一次嘗試，沒有成功。 該網站一直很好，真正的 pwn3d。

因此，如果您在 mysql 數據目錄中發現導致錯誤 17 的file ，請使用file實用程序檢查它或使用防病毒軟件對其進行掃描。 或目視檢查其內容。 不要認為它是一些無害的錯誤。

（不用說，要目視檢查文件，切勿雙擊它）。

在這種情況下，受害者（他有一些朋友“做維護”）永遠不會猜到他被黑了，直到維護/更新/任何腳本運行DROP DATABASE （不要問我為什么 - 我什至不確定我想知道) 並出現錯誤。 從 CPU 負載和系統日志消息來看，我相當肯定主機已成為垃圾郵件群。

又一個錯誤 17

如果您在相同版本但不同平台或文件系統（例如 Linux 或 Windows）的兩個 MySQL 安裝之間進行rsync或復制（這是不鼓勵的，並且有風險，但許多人仍然這樣做），特別是使用不同的區分大小寫設置，您可能會意外最終得到同一文件的兩個版本（數據、索引或元數據）； 說Customers.myi和Customer.MYI 。 MySQL 使用其中一個並且對另一個一無所知（這可能已經過時並導致災難性的同步）。 刪除數據庫時，這也發生在許多mysqldump ... | ... mysql mysqldump ... | ... mysql備份方案， DROP將失敗，因為該額外文件（或那些額外文件）存在。 如果發生這種情況，您應該能夠從文件時間或從它們的案例方案與大多數其他表不同的事實中識別需要手動刪除的過時文件。

查找數據目錄

在一般情況下，你可以通過檢查發現數據目錄my.cnf文件（ /etc/my.cnf ， /etc/sysconfig/my.cnf ， /etc/mysql/my.cnf在Linux上; my.ini在MySQL 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)

Answer 2

就我而言，這是由於 'lower_case_table_names' 參數造成的。

當我嘗試刪除包含帶有lower_case_table_names 參數的大寫表名的數據庫時拋出的錯誤號39 已啟用。

這是通過將小寫參數更改恢復到先前狀態來解決的。

Answer 3

只需轉到/opt/lampp/var/mysql

在那里您可以找到您的database名稱。 打開那個文件夾。 刪除其中的任何文件

現在來到phpmyadmin並刪除該database

Answer 4

至於ERRORCODE 39 ，你肯定可以刪除磁盤上的物理表文件。 位置取決於您的操作系統分發和設置。 在 Debian 上，它通常在 /var/lib/mysql/ database_name / 下，所以請執行以下操作：

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

然后從您選擇的工具中刪除數據庫或使用以下命令：

DROP DATABASE <database_name>

Answer 5

我將 XAMP 服務器用於 MySQL，但是當我想刪除數據庫時遇到以下問題

#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，database/schema刪除成功。

Answer 6

我是這樣解決的：

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

Answer 7

在我的情況下，一個不屬於數據庫的附加文件位於數據庫文件夾中。 在刪除所有觸發錯誤的表后，Mysql 發現文件夾不為空。 我刪除了文件，drop 數據庫工作正常。

Answer 8

在 linux 中，只需轉到“/var/lib/mysql”右鍵單擊並（以管理員身份打開），在 mysql 文件夾中找到與您的數據庫名稱對應的文件夾並將其刪除。 而已。 數據庫被刪除。