MySQL數據庫常見錯誤及解決方案

MySQL數據庫常見錯誤及解決方案

 

1  

MySQL沒法重啓問題解決Warning: World-writable config file ‘/etc/my.cnf’ is ignored

緣由

今天幫朋友維護服務器，在關閉數據庫的命令發現mysql關不了，提示Warning: World-writable config file '/etc/my.cnf' is ignored ，大概意思是權限全局可寫，任何一個用戶均可以寫。mysql擔憂這種文件被其餘用戶惡意修改，因此忽略掉這個配置文件。這樣mysql沒法關閉。

1 2 3 4

[root@ttlsa ~]# service mysqld stop Warning: World-writable config file '/etc/my.cnf' is ignored Warning: World-writable config file '/etc/my.cnf' is ignored MySQL manager or server PID file could not be found![FAILED]

查看my.cnf的權限

1 2	[root@ttlsa ~]# ls -l /etc/my.cnf -rwxrwxrwx 1 root root 4878 Jul 30 11:31 /etc/my.cnf

權限777，任何一個用戶均可以改my.cnf，存在很大的安全隱患.

解決方案：

修復MySQL問題

1	[root@ttlsa ~]# chmod 644 /etc/my.cnf

my.cnf設置爲用戶可讀寫，其餘用戶不可寫.

2

Can't connect to MySQL server on 'localhost' (10061)

緣由

不能鏈接到 localhost 上的mysql

解決方案：

這說明「localhost」計算機是存在的，但在這臺機器上卻沒提供MySQL服務。

須要啓動這臺機器上的MySQL服務,若是機子負載過高沒空相應請求也會產生這個錯誤。

解決：既然沒有啓動那就去啓動這臺機子的mysql。若是啓動不成功，多數是由於你的my.ini配置的有問題。從新配置其便可。

若是以爲mysql負載異常，能夠到mysql/bin 的目錄下執行mysqladmin -uroot -p123 processlist來查看mysql當前的進程。

3

Unknown MySQL Server Host 'localhosadst' (11001)

緣由

未知的MySQL服務器 localhosadst，服務器 localhosasdst 不存在。或者根本沒法鏈接。

解決方案：

仔細檢查本身論壇下面的 ./config.inc.php 找到$dbhost從新設置爲正確的mysql 服務器地址。

4

Access denied for user: 'roota@localhost' (Using password: YES)

緣由

用戶 roota 訪問 localhost 被拒絕（沒有容許經過）,形成這個錯誤通常數據庫用戶名和密碼相對mysql服務器不正確

解決方案：

仔細檢查本身論壇下面的 ./config.inc.php 找到$dbuser、$dbpw覈實後從新設置保存便可。

5

Access denied for user: 'red@localhost' to database 'newbbs'

緣由

用戶 red 在localhost 服務器上沒有權限操做數據庫newbbs

這個提示和問題三是不一樣的。那個是在鏈接數據庫的時候就被阻止了，而這個錯誤是在對數據庫進行操做時引發的。好比在select update等等。這個是由於該用戶沒有操做數據庫相應的權力。好比select 這個操做在mysql.user.Select_priv裏記錄 Y 能夠操做N 不能夠操做。

解決方案：

若是是本身的獨立主機那麼更新mysql.user 的相應用戶記錄，好比這裏要更新的用戶爲red 。或者直接修改 ./config.inc.php 爲其配置一個具備對數據庫操做權限的用戶

或者經過以下的命令來更新受權grant all privileges on dbname.* to 'user'@'localhost' identified by 'password’

提示：更新了mysql庫中的記錄必定要重啓mysql服務器才能使更新生效

6

No Database Selected

緣由

產生的緣由有兩種。

config.inc.php 裏面$dbname設置的不對。導致數據庫根本不存在，因此在 $db->select_db($dbname); 時返回了false

和上面問題四是同樣的，數據庫用戶沒有select權限，一樣會致使這樣的錯誤。當你發現config.inc.php的設置沒有任何問題，但仍是提示這個錯誤，那必定就是這種狀況了。

解決方案：

對症下藥

打開config.inc.php 找到$dbname覈實從新配置並保存

同問題四的解決方法

7

Can't open file: 'xxx_forums.MYI'. (errno: 145)

緣由

這種狀況是不能打開 cdb_forums.MYI 形成的，引發這種狀況可能的緣由有：

一、服務器非正常關機，數據庫所在空間已滿，或一些其它未知的緣由，對數據庫表形成了損壞。

二、類 unix 操做系統下直接將數據庫文件拷貝移動會由於文件的屬組問題而產生這個錯誤。

解決方案：

一、修復數據表

可使用下面的兩種方式修復數據表：（第一種方法僅適合獨立主機用戶）

1）使用 myisamchk ，MySQL 自帶了專門用戶數據表檢查和修復的工具 —— myisamchk 。更改當前目錄到 MySQL/bin 下面，通常狀況下只有在這個下面才能運行 myisamchk 命令。經常使用的修復命令爲：myisamchk -r 數據文件目錄/數據表名.MYI；

2）經過 phpMyAdmin 修復， phpMyAdmin 帶有修復數據表的功能，進入到某一個表中後，點擊「操做」，在下方的「表維護」中點擊「修復表」便可。

注意：以上兩種修復方式在執行前必定要備份數據庫。

二、修改文件的屬組（僅適合獨立主機用戶）

複製數據庫文件的過程當中沒有將數據庫文件設置爲 MySQL 運行的賬號可讀寫（通常適用於 Linux 和 FreeBSD 用戶）。

8

Table 'test.xxx_sessions' doesn't exist

翻譯：xxxxx表不存在

緣由

在執行sql語句時沒有找到表，好比：SELECT * FROM xxx_members WHERE uid=’XX’ 這裏若是表xxx_members不存在於$dbname庫裏，那麼就會提示這個錯誤。具體可分爲如下三種狀況來討論：

安裝插件或者hack時修改了程序文件，而忘記了對數據庫做相應的升級。

後臺使用了不徹底備份，導入數據時沒有導入到已經安裝了相應版本的論壇的數據庫中。

解決方案：

一樣對症下藥，不一樣的緣由不一樣的處理方法。

仔細對照插件做者提供的安裝說明，把遺漏的對數據庫的操做補上，若是仍然不能解決問題，那麼應該懷疑該插件的可用性了。去諮詢一下插件做者，或者將其卸載。

不要張冠李戴，多大的腳就穿多大的鞋。總之使得程序文件和數據庫配套便可.

9

Unknown column 'column_name' in 'field list'

緣由

在執行sql語句是出現了指定表中沒有的字段名稱，就會出現這個錯誤。具體致使的緣由可分爲如下兩種安裝插件或者hack時修改了程序文件，而忘記了對數據庫做相應的升級。

程序文件和數據庫不配套，好比d2.5的數據庫配置給d4.1的程序來用確定會出現這個錯誤。

解決方案：

 致使的緣由和問題八的1和 3是相同的，因此解決方法也同樣。

10

You have an error in your SQL syntax

緣由

論壇標準的程序是沒有sql語法錯誤的。因此形成這個錯誤的緣由通常就兩類：安裝插件或擅自修改程序。

不一樣的數據庫版本數據庫導出導入，好比MySQL4.1的數據在導出的語句包含了MySQL4.0沒有的功能，像字符集的設定，這時若是將這些sql導入到MySQL4.0的時候就會產生sql語法錯誤。

解決方案：

仔細檢查看究竟是哪裏的錯誤，將其修正，實在不行就用標準程序把出錯的程序替換。

在數據庫備份的時候要留意，若是不打算倒入到其餘版本的mysql中則不用特殊考慮，反之要特殊的設定。使用DZ4.1的後臺數據備份，能夠按照提示去設定想要的格式。獨立主機的也能夠在處處的時候將其導出爲mysql4.0的格式。

mysqldump -uroot -p --default-character-set=latin1 --set-charset=gbk --skip-opt databse > test.sql

11

Duplicate entry 'xxx' for key 1

翻譯：插入 xxx 使索引1重複

緣由

索引若是是primary unique這兩兩種，那麼數據表的數據對應的這個字段就必須保證其每條記錄的惟一性。不然就會產生這個錯誤。

通常發生在對數據庫寫操做的時候，例如Discuz!4.1論壇程序要求全部會員的用戶名username必須惟一，即username的索引是 unique，這時若是強行往cdb_members表裏插入一個已有的username的記錄就會發上這個錯誤，或者將一條記錄的username更新 爲已有的一個username。

改變表結構的時候也有可能致使這個錯誤。例如 Discuz!4.0論壇的數據庫中cdb_members.username 的索引類型是index這個時候是容許有相同username的記錄存在的，在升級到4.1的時候，由於要將username的索引由原來的index變 爲unique。若是這時cdb_members裏存在有相同的username的記錄，那麼就會引起這個錯誤。

導出數據據時有時會由於一些緣由（做者目前還不清楚）致使同一條記錄被重複導出，那麼這個備份數據在導入的時候出現這個錯誤是在所不免的了。

修改了auto_increment的值，導致「下一個 Autoindex」爲一條已經存在的記錄。

解決方案：

兩種思路，一是破壞掉惟一性的索引。二是把重複的數據記錄幹掉，只保留一條。很顯然第一種思路是不可取的。那麼按照二的思路咱們得出如下幾種解決方法，對應上面的i ii iii

略

按照錯誤提示裏的信息到數據庫中將重複的記錄刪除，僅保留一條便可。以後繼續執行升級操做。

這種狀況發生的機率很小，能夠用文本編輯器打開備份文檔，查找重複的信息。將其多餘的拿掉，僅保留一條便可。

查詢出表中auto_increment最大的一條記錄，設置auto_incerment比其大一便可。

PS：repaire table "表名「，能夠暫時解決問題。

12

Duplicate key name 'xxx'

翻譯：索引名重複

緣由

要建立的索引已經存在了，就會引起這個錯誤，這個錯誤多發生在升級的時候。多是已經升級過的，重複升級引發的錯誤。也有多是以前用戶擅自加的索引，恰好與升級文件中的因此相同了。

解決方案：

 看看已經存在的索引和要添加的索引是否同樣，同樣的話能夠跳過這條sql語句，若是不同那麼現刪除已存在的因此，以後再執行。

13

Duplicate column name 'xxx'

翻譯：字段名xxx重複

緣由

添加的字段xxx已經存在，多發生在升級過程當中，與問題十二的產生是同樣的。

解決方案：

看一下已經存在的字段是否和將要添加的字段屬性徹底相同，若是相同則能夠跳過不執行這句sql，若是不同則刪除掉這個字段。以後繼續執行升級程序。

14

Table 'xxx' already exists

翻譯：數據表xxx已經存在

緣由

xxx表已經存在於庫中，再次試圖建立這個名字的表就會引起這個錯誤。一樣多發生在論壇的升級中。相似於問題十二。

解決方案：

看看已經存在的表是否和將要建立的表徹底同樣，同樣的話能夠跳過不執行這個sql，不然請將存在的表先刪除，以後繼續執行升級文件。

15

Can't create database 'xxx'. Database exists

不能建立數據庫xxx，數據庫已經存在

緣由

一個mysql下面的數據庫名稱必須保證惟一性，不然就會有這個錯誤。

解決方案：

把已經存在的數據庫更名或者把將要建立的數據庫更名，總之不讓他們的名稱衝突。

16

 小結（針對問題 11\12\13\14\15）

此類問題錯誤提示中都暗藏一個關鍵詞duplicate（重複）

那麼對於mysql數據庫來講什麼東西是不能重複的呢？

數據庫 database

同一個數據庫下數據表 table

同一個數據表下字段 column

同一個數據表下索引 key

同一個數據表在索引惟一（UNIQUE PRIMARY）的狀況下記錄中的這些字段不能夠重複

17

Unknown system variable 'NAMES'

翻譯：未知的系統變量NAMES

緣由

Mysql版本不支持字符集設定，此時強行設定字符集就會出現這個錯誤。

解決方案：

 將sql語句中的SET NAMES ‘xxx’ 語句去掉

18

Lost connection to MySQL server during query

翻譯：MySQL服務器失去鏈接在查詢期間

緣由

遠程鏈接數據庫是有時會有這個問題。MySQL服務器在執行一條sql語句的時候失去了鏈接形成的。

解決方案：

通常不須要怎麼去處理，若是頻繁的出現那麼考慮改善硬件環境。

19

User 'red' has exceeded the 'max_updates' resource (current value: 500)

翻譯：msql用戶red已經超過了'max_updates'（最大更新次數），'max_questions'（最大查詢次數），'max_connections'（最大鏈接數），當前設定爲500

緣由

在mysql數據庫的下有一個庫爲mysql，它其中有一個表爲user這裏面的紀錄每一條都對應爲一個mysql用戶的受權。其中字段 max_questions max_updates max_connections分別記錄着最大查詢次數 最大更新數 最大鏈接數，當目前的任何一個參數大於任何一個設定的值就會產生這個錯誤。

解決方案：

獨立主機用戶能夠直接修改受權表。修改完以後重啓mysql或者跟新受權表，進入mysql提示符下執行FLUSH PRIVILEGES;

記得後面要有分號’;’

虛擬主機的用戶若是老是出現這個問題可找空間商協商解決。

20

Too many connections (1040)連接過多

翻譯：達到最大鏈接數

緣由

鏈接數超過了mysql設置的值，與max_connections 和wait_timeout 都有關係。wait_timeout的值越大，鏈接的空閒等待就越長，這樣就會形成當前鏈接數越大

解決方案：

1.虛擬主機用戶請聯繫空間商優化 MySQL 服務器的配置；

2.獨立主機用戶請聯繫服務器管理員優化 MySQL 服務器的配置，可參考：

修改 MySQL 配置文件 my.ini 或者 my.cnf 中的參數：

max_connections= 1000

wait_timeout = 10

修改後重啓 MySQL ，若是常常性的報此錯誤，請作一下服務器的總體優化。

21

There is no such grant defined for user '%s' on host '%s'

錯誤編號：1141

緣由

MySQL 當前用戶無權訪問數據庫。

解決方案：

一、虛擬主機用戶請聯繫空間商，確認給你提供的賬號是否有受權數據庫的權限。

二、獨立主機用戶請聯繫服務器管理員，確認給您提供的數據庫賬號是否有管理此數據庫的權限。

22

Error on rename of '%s' to '%s' (errno: %d)

error.:1025

緣由

請檢查一下您的程序是否有修改數據庫表名的語句。

解決方案：

1.請檢查您的程序中哪些地方須要修改數據庫表名；

2.若是您的實際應用確實須要修改到數據庫表名的話，請聯繫空間商或者服務器管理員給您開放修改庫名的權限和服務器自己是否正常。

23

Error reading file '%s' (errno: %d)

error.:1023

緣由

數據庫文件不能被讀取。

解決方案：

1.虛擬主機用戶請聯繫空間商查看數據庫是否無缺。

2.獨立主機用戶請聯繫服務器管理員檢查一下 MySQL 自己是否正常， MySQL 是否能夠讀取文件，Linux 用戶能夠檢查一下 MySQL 的數據庫文件的屬主是否正確以及自己的文件是否損壞。

24

Host '*****' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'

error.:1129

緣由

數據庫出現異常，請重啓數據庫。

解決方案：

因爲存在不少鏈接錯誤，主機'****'被屏蔽，虛擬主機用戶請聯繫空間商處理，獨立主機用戶請聯繫服務器管理員，在 MySQL 的命令控制檯下執行'mysqladmin flush-hosts'解除屏蔽便可，或者重啓 MySQL 數據庫。

25

dropping database (can't delete '%s', errno: %d)

error.:1009

緣由

不能刪除數據庫文件，致使刪除數據庫失敗。

解決方案：

1.檢查您使用的數據庫管理賬號是否有權限刪除數據。

2.檢查數據庫是否存在。

26

Got error 28 from table handler

error.:1030

緣由

數據庫所在磁盤空間已滿。

解決方案：

1.虛擬主機用戶請聯繫空間商增長 MySQL 所在的磁盤空間或者清理一些無用文件；

2.獨立主機用戶請聯繫服務器管理員增長 MySQL 所在的磁盤空間或者清理一些無用文件

27

Can't create a new thread; if you are not out of available memory, you can consult the manual for a possible OS-dependent bug。

error.:11/35

緣由

數據庫服務器問題，數據庫操做沒法建立新線程。通常是兩個緣由：

1.服務器系統內存溢出。

2.環境軟件損壞或系統損壞。

解決方案：

1.虛擬主機用戶請聯繫下空間商數據庫服務器的內存和系統是否正常。

2.獨立主機用戶請聯繫服務器管理員檢查服務器的內存和系統是否正常，若是服務器內存緊張，請檢查一下哪些進程消耗了服務器的內存，同時考慮是否增長服務器的內存來提升整個的負載能力。

28

Error: Client does not support authentication protocol requested by server; consider upgrading MySQL client

error.:1251

緣由

若是你升級 MySQL 到 4.1 以上版本後遇到以上問題,請先肯定你的 MySQL Client 是 4.1 或者更高版本( Windows 下有問題你就直接跳到下面看解決方法了，由於 MySQL 在 Windows 是 client 和 server 一塊兒裝上了的)。

解決方案：

1. Windows 平臺

主要是改變鏈接 MySQL 的賬戶的加密方式，MySQL 4.1/5.0 是經過 PASSWORD 這種方式加密的。能夠經過如下兩種方法獲得解決：

1) mysql->SET PASSWORD FOR 'some_user'@'some_host'=OLD_PASSWORD('new_password');

2) mysql->UPDATE mysql.user SET Password=OLD_PASSWORD('new_password') WHERE Host='some_host' AND User='some_user';

2. Linux/Unix 平臺

Linux 平臺下首先肯定是否安裝過 MySQL 的客戶端，這個用 rpm 安裝很簡單，Linux 代碼爲：

rpm -ivh MySQL-client-4.1.15-0.i386.rpm

而後在編譯 php 的時候要加上：

--with-mysql=/your/path/to/mysql

通常狀況下均可以解決。若是還出現這種錯誤，能夠按照下面的方法來作：

mysql->SET PASSWORD FOR 'some_user'@'some_host'=OLD_PASSWORD('new_password');

mysql->UPDATE mysql.user SET Password=OLD_PASSWORD('new_password') WHERE Host='some_host' AND User='some_user';

29

Error: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'

error.:2002

緣由

出現這個錯誤通常狀況下是由於下面兩個緣由：

1.MySQL 服務器沒有開啓。

2.MySQL 服務器開啓了，但不能找到 socket 文件。

解決方案：

1.虛擬主機用戶，請聯繫空間商確認數據庫是否正常啓動。

2.獨立主機用戶，請檢查一下 MySQL 服務是否已經開啓，沒有開啓，請啓動 MySQL 服務；若是已經開啓，而且是 Linux 系統，請檢查一下 MySQL 的 socket 的路徑，而後打開 config.inc.php 找到

$dbhost = 'localhost'; 在 hostname 後面加冒號‘:’和 MySQL 的 socket 的路徑。

好比 MySQL 服務器爲 localhost

MySQL 的 socket 的路徑爲 /tmp/mysql.sock

那麼就改爲以下：

$dbhost = 'localhost:/temp/mysql.sock';

30

Can't connect to MySQL server on 'localhost'

error.:2003

緣由

MySQL 服務沒有啓動，通常是在異常的狀況下 MySQL 沒法啓動致使的，好比無可用的磁盤空間，my.ini 裏 MySQL 的 basedir 路徑設置錯誤等。

解決方案：

1.檢查磁盤空間是否還有剩餘可用空間，儘可能保持有足夠的磁盤空間可用。

2.檢查 my.ini 裏的 basedir 等參數設置是否正確，而後從新啓動下 MySQL 服務。

31

Lost connection to MySQL server during query

error.:2013

緣由

數據庫查詢過程當中丟失了與 MySQL 服務器的鏈接。

解決方案：

1.請確認您的程序中是否有效率很低的程序，好比某些插件，能夠卸載掉插件，檢查一下服務器是否正常；

2.服務器自己資源緊張，虛擬主機用戶請聯繫空間商確認，獨立主機用戶請聯繫服務器管理員，檢查一下服務器是否正常。

32

Got a packet bigger than \'max_allowed_packet\' bytes

錯誤編號：1153

緣由

調整了 Mantis 的上傳附件的大小卻沒有調整 MySQL 的配置文件。

解決方案：

一、獨立主機用戶請按照如下方法調整：

查找 MySQL 的配置文件（my.cnf 或者 my.ini）

在 [mysqld] 部分添加一句（若是存在，調整其值就能夠）：

max_allowed_packet=10M

重啓 MySQL 服務就能夠了。這裏設置的是 10MB。

二、虛擬主機用戶請聯繫空間商調整此參數。