mysql資料庫磁碟未監控,監控顯示無磁碟

本文目錄一覽：

• 1、求助！mysql資料庫打不開了顯示 1286 – Unknown storage engine ‘InnoDB’
• 2、為什麼啟動mysql資料庫之後，過幾分鐘又顯示資料庫沒有連接，又要重新啟動，之前是win8系統沒有
• 3、zabbix添加mysql監控後沒數據怎麼辦
• 4、如何實現監控mysql，並將有變動的數據表寫入指定的文件夾？
• 5、資料庫mysql創建表格老是出錯，看不懂英文提示？

求助！mysql資料庫打不開了顯示 1286 – Unknown storage engine ‘InnoDB’

你把INNODB日誌弄壞了吧！

別隨便修改存儲引擎，啟動不起來你認真查一下配置文件，對不對。

mysql配置只要隨便一個配置參數錯誤就啟不來。

如果配置參數都對，能否先運行一下修復命令。

都不行，檢查一下磁碟，磁軌是不是壞了。

但願你修改的不是生產環境，要不老闆估計要讓你下課，最輕也會被訓。

為什麼啟動mysql資料庫之後，過幾分鐘又顯示資料庫沒有連接，又要重新啟動，之前是win8系統沒有

解決辦法：

第一步

刪除c:\windows\下面的my.ini

第二步

打開c:\mysql\bin\winmysqladmin.exe 輸入用戶名 和密碼

第三步 在dos下 輸入 mysqld-nt -remove 刪除服務

在接著輸入 mysqld-nt -install

第四步 輸入mysql 啟動成功。

其它可參考的方法：

1.看看hosts文件中localhost是不是指向127.0.0.1

2.如果是沒啟動mysql服務，則可運行net start mysql。

3.一些相關命令：

mysqld-nt –install #啟動Mysql

mysql #運行Mysql

mysql -h ipAddress -u username -p

或者：直接去bin里點mysqld.exe或mysqld-nt.exe，看下它的進程能否正常運行，如不行，再去控制面板，服務里去啟動它，看下是什麼錯誤。如果不行，就在添加刪除里刪去mysql，然後再重裝mysql，一般都能解決問題，可以在安裝前備份一下DATA。

Error: Can’t connect to MySQL server on ‘localhost’ (10061)

Errno.: 2003

錯誤編號：2003

問題分析：

無法連接到 MySQL 伺服器，可能的情況為：

1、MySQL 服務沒有啟動，一般是在異常的情況下 MySQL 無法啟動導致的，比如無可用的磁碟空間，my.ini 里 MySQL 的 basedir 路徑設置錯誤等；

2、MySQL 伺服器資源緊張，導致無法連接。

解決方法：

1、如果你是虛擬主機用戶（購買的空間），則聯繫空間商檢查 MySQL 是否正常啟動，並確認 MySQL 的配置信息（是否為 localhost）；

2、如果你是獨立主機用戶（擁有管理主機許可權），則按下面步驟檢查：

1）檢查磁碟空間是否還有剩餘可用空間，盡量保持有足夠的磁碟空間可用。

2）檢查 my.ini 里的 basedir （MySQL 安裝地址） 和 datadir （數據目錄存放地址）等參數設置是否正確，然後重新啟動下 MySQL 服務。

還有一種方法是將伺服器的windows補丁。

微軟9月9日發布了TCP/IP更新補丁（KB967723），如果伺服器開啟自動更新或者有自動更新軟體下載更新了這個補丁，那麼就會出現這個問題。

有人可能會問，為什麼9號出現的補丁，到現在才發現問題？

大家都知道，伺服器不是每天都重啟的，有的伺服器可能一個月或者一年半載重啟一次，有的可能在9月9日以後重啟過伺服器，所以補丁生效了（我個人這麼認為）。

補丁卸載方法：登錄伺服器，進入控制面板 — 添加和刪除程序 — （勾選上方的「顯示更新」）

在裡面可以看到更新的KB967723這個補丁，然後就想卸載普通軟體一樣卸載，卸載中會提示你，如果卸載可能導致程序運行出錯，沒關係，選擇「是」，繼續卸載。

卸載完成後程序伺服器，一切正常！

至於該補丁修補什麼漏洞，卸載後是否會出現伺服器安全隱患，這個先不說，要MYSQL正常運行，臨時的解決辦法只有如此。

還有種情況下，你可以這樣解決

Discuz! info: Can not connect to MySQL server

Time: 2007-11-13 6:25pm

Script: /bbs/index.php

Error: Can’t connect to MySQL server on ‘localhost’ (10061)

Errno.: 2003

Similar error report has beed dispatched to administrator before.

正常情況下原因如下:

網站論壇訪問量過大,資料庫連接超過最大連接數.MYSQL資料庫服務停止了.

解決方法(針對WIN系統):

1, 首先到系統服務裡面找到MYSQL服務並啟動MYSQL服務.

2, 到MYSQL安裝目錄找到MY.INI文件,打開MY.INI查找max_connections 修改連接數為1000 重啟IIS與MYSQL服務.

window 下

命令行下輸入：

cd E:\mysql\bin

mysqladmin -u root password 你的密碼

mysql -u root -p

Enter password: 你的密碼

便可以

、、、、、、、、、、、、、、、、、

找到了根本原因，在此涼一下：

導致此問題的根源在：因為給mysql的root設置了密碼，而不是最初安裝好時的密碼為空，所以使用

mysqladmin version這樣子不行了，必須這樣子：mysqladmin -uroot -p version，回車後按照提示要求輸入

root密碼即可成功運行命令。

第一種方法其實就是在不知道root密碼的情況下的一種解決辦法，那樣子啟動不用密碼即可進mysql

裡面並進行root密碼的修改，解決忘記了root密碼的問題。

輸入命令「mysqladmin -u root password 你的密碼」作用是修改root用戶的密碼，這條命令能夠不經

提示輸入原密碼而成功執行，也說明了原密碼是空。之後使用修改後的密碼自然能夠成功登錄。

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。怎麼更改密碼？

首先要聲明一點，大部分情況下，修改MySQL是需要有mysql里的root許可權的，所以一般用戶無法更改密碼

，除非請求管理員。

方法一

使用phpmyadmin，這是最簡單的了，修改mysql庫的user表，

不過別忘了使用PASSWORD函數。

方法二

使用mysqladmin，這是前面聲明的一個特例。

mysqladmin -u root -p password mypasswd

輸入這個命令後，需要輸入root的原密碼，然後root的密碼將改為mypasswd。

把命令里的root改為你的用戶名，你就可以改你自己的密碼了。

當然如果你的mysqladmin連接不上mysql server，或者你沒有辦法執行mysqladmin，

那麼這種方法就是無效的。

而且mysqladmin無法把密碼清空。

下面的方法都在mysql提示符下使用，且必須有mysql的root許可權：

方法三

mysql INSERT INTO mysql.user (Host,User,Password)

VALUES(‘%’,’jeffrey’,PASSWORD(‘biscuit’));

mysql FLUSH PRIVILEGES

確切地說這是在增加一個用戶，用戶名為jeffrey，密碼為biscuit。

在《mysql中文參考手冊》里有這個例子，所以我也就寫出來了。

注意要使用PASSWORD函數，然後還要使用FLUSH PRIVILEGES。

方法四

和方法三一樣，只是使用了REPLACE語句

mysql REPLACE INTO mysql.user (Host,User,Password)

VALUES(‘%’,’jeffrey’,PASSWORD(‘biscuit’));

mysql FLUSH PRIVILEGES

方法五

使用SET PASSWORD語句，

mysql SET PASSWORD FOR ” = PASSWORD(‘biscuit’);

擬也必須使用PASSWORD()函數，

但是不需要使用FLUSH PRIVILEGES。

方法六

使用GRANT … IDENTIFIED BY語句

mysql GRANT USAGE ON *.* TO ” IDENTIFIED BY ‘biscuit’;

這裡PASSWORD()函數是不必要的，也不需要使用FLUSH PRIVILEGES。

注意： PASSWORD() [不是]以在Unix口令加密的同樣方法施行口令加密。

MySQL 忘記口令的解決辦法

如果 MySQL 正在運行，首先殺之： killall -TERM mysqld。

啟動 MySQL ：bin/safe_mysqld –skip-grant-tables

就可以不需要密碼就進入 MySQL 了。

然後就是

use mysql

update user set password=password(“new_pass”) where user=”root”;

flush privileges;

重新殺 MySQL ，用正常方法啟動 MySQL 。

linux下

方法一：

# /etc/init.d/mysql stop

# mysqld_safe –user=mysql –skip-grant-tables –skip-networking

# mysql -u root mysql

mysql UPDATE user SET Password=PASSWORD(‘newpassword’) where USER=’root’;

mysql FLUSH PRIVILE

zabbix添加mysql監控後沒數據怎麼辦

有兩種方法，一種方法使用mysql的check table和repair table 的sql語句，另一種方法是使用MySQL提供的多個myisamchk, isamchk數據檢測恢復工具。前者使用起來比較簡便。推薦使用。

1. check table 和 repair table

登陸mysql 終端：

mysql -uxxxxx -p dbname

check table tabTest;

如果出現的結果說Status是OK，則不用修復，如果有Error，可以用：

repair table tabTest;

進行修復，修復之後可以在用check table命令來進行檢查。在新版本的phpMyAdmin裡面也可以使用check/repair的功能。

2. myisamchk, isamchk

其中myisamchk適用於MYISAM類型的數據表，而isamchk適用於ISAM類型的數據表。這兩條命令的主要參數相同，一般新的系統都使用MYISAM作為預設的數據表類型，這裡以myisamchk為例子進行說明。當發現某個數據表出現問題時可以使用：

myisamchk tablename.MYI

進行檢測，如果需要修復的話，可以使用：

myisamchk -of tablename.MYI

關於myisamchk的詳細參數說明，可以參見它的使用幫助。需要注意的時在進行修改時必須確保MySQL伺服器沒有訪問這個數據表，保險的情況下是最好在進行檢測時把MySQL伺服器Shutdown掉。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

另外可以把下面的命令放在你的rc.local裡面啟動MySQL伺服器前：

[ -x /tmp/mysql.sock ] /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI

其中的/tmp/mysql.sock是MySQL監聽的Sock文件位置，對於使用RPM安裝的用戶應該是/var/lib/mysql/mysql.sock，對於使用源碼安裝則是/tmp/mysql.sock可以根據自己的實際情況進行變更，而pathtochk則是myisamchk所在的位置，DATA_DIR是你的MySQL資料庫存放的位置。

需要注意的時，如果你打算把這條命令放在你的rc.local裡面，必須確認在執行這條指令時MySQL伺服器必須沒有啟動！檢測修復所有資料庫(表)

如何實現監控mysql，並將有變動的數據表寫入指定的文件夾？

首先介紹下 pt-stalk，它是 Percona-Toolkit 工具包中的一個工具，說起 PT 工具包大家都不陌生，平時常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自於這個工具包，這裡就不多介紹了。

pt-stalk 的主要功能是在出現問題時收集 OS 及 MySQL 的診斷信息，這其中包括：

1. OS 層面的 CPU、IO、內存、磁碟、網路等信息；

2. MySQL 層面的行鎖等待、會話連接、主從複製，狀態參數等信息。

而且 pt-stalk 是一個 Shell腳本，對於我這種看不懂 perl 的人來說比較友好，腳本裡面的監控邏輯與監控命令也可以拿來參考，用於構建自己的監控體系。

三、使用

接著我們來看下如何使用這個工具。

pt-stalk 通常以後台服務形式監控 MySQL 並等待觸發條件，當觸發條件時收集相關診斷數據。

觸發條件相關的參數有以下幾個：

function：

∘ 默認為 status，代表監控 SHOW GLOBAL STATUS 的輸出；

∘ 也可以設置為 processlist，代表監控 show processlist 的輸出；

variable：

∘ 默認為 Threads_running，代表 監控參數，根據上述監控輸出指定具體的監控項；

threshold：

∘ 默認為 25，代表 監控閾值，監控參數超過閾值，則滿足觸發條件；

∘ 監控參數的值非數字時，需要配合 match 參數一起使用，如 processlist 的 state 列；

cycles：

∘ 默認為 5，表示連續觀察到五次滿足觸發條件時，才觸發收集；

連接參數：host、password、port、socket。

其他一些重要參數：

iterations：該參數指定 pt-stalk 在觸發收集幾次後退出，默認會一直運行。

run-time：觸發收集後，該參數指定收集多長時間的數據，默認 30 秒。

sleep：該參數指定在觸發收集後，sleep 多久後繼續監控，默認 300 秒。

interval：指定狀態參數的檢查頻率，判斷是否需要觸發收集，默認 1 秒。

dest：監控數據存放路徑，默認為 /var/lib/pt-stalk。

retention-time ：監控數據保留時長，默認 30 天。

daemonize：以後台服務運行，默認不開啟。

log：後台運行日誌，默認為 /var/log/pt-stalk.log。

collect：觸發發生時收集診斷數據，默認開啟。

∘ collect-gdb：收集 GDB 堆棧跟蹤，需要 gdb 工具。

∘ collect-strace：收集跟蹤數據，需要 strace 工具。

∘ collect-tcpdump：收集 tcpdump 數據，需要 tcpdump 工具。

資料庫mysql創建表格老是出錯，看不懂英文提示？

來自：51CTO（作者：superZS）

我在剛開始學習資料庫的時候，沒少走彎路。經常會遇到各種稀奇古怪的 error 信息，遇到報錯會很慌張，急需一個解決問題的辦法。跟無頭蒼蠅一樣，會不加思索地把錯誤粘到百度上，希望趕緊查找一下有沒有好的處理問題的方法。我想這個應該是剛從事資料庫的小白，都會遇到窘境。

今天就給大家列舉 MySQL 資料庫中，最經典的十大錯誤案例，並附有處理問題的解決思路和方法，希望能給剛入行，或資料庫愛好者一些幫助，今後再遇到任何報錯，我們都可以很淡定地去處理。

學習任何一門技術的同時，其實就是自我修鍊的過程。沉下心，嘗試去擁抱數據的世界！

Top 1：

Too many connections（連接數過多，導致連接不上資料庫，業務無法正常進行）

問題還原

解決問題的思路：

1、首先先要考慮在我們 MySQL 資料庫參數文件裡面，對應的 max_connections 這個參數值是不是設置的太小了，導致客戶端連接數超過了資料庫所承受的最大值。

● 該值默認大小是151，我們可以根據實際情況進行調整。

● 對應解決辦法：set global max_connections=500

但這樣調整會有隱患，因為我們無法確認資料庫是否可以承擔這麼大的連接壓力，就好比原來一個人只能吃一個饅頭，但現在卻非要讓他吃 10 個，他肯定接受不了。反應到伺服器上面，就有可能會出現宕機的可能。

所以這又反應出了，我們在新上線一個業務系統的時候，要做好壓力測試。保證後期對資料庫進行優化調整。

2、其次可以限制 Innodb 的並發處理數量，如果 innodb_thread_concurrency = 0（這種代表不受限制） 可以先改成 16或是64 看伺服器壓力。如果非常大，可以先改的小一點讓伺服器的壓力下來之後,然後再慢慢增大,根據自己的業務而定。個人建議可以先調整為 16 即可。

MySQL 隨著連接數的增加性能是會下降的，可以讓開發配合設置 thread pool，連接復用。在MySQL商業版中加入了thread pool這項功能

另外對於有的監控程序會讀取 information_schema 下面的表，可以考慮關閉下面的參數

innodb_stats_on_metadata=0

set global innodb_stats_on_metadata=0

Top 2：（主從複製報錯類型）

Last_SQL_Errno: 1062 （從庫與主庫數據衝突）

Last_Errno: 1062

Last_Error: Could not execute Write_rows event on table test.t;

Duplicate entry ‘4’ for key ‘PRIMARY’,

Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY;

the event’s master log mysql-bin.000014, end_log_pos 1505

針對這個報錯，我們首先要考慮是不是在從庫中誤操作導致的。結果發現，我們在從庫中進行了一條針對有主鍵表的 sql 語句的插入，導致主庫再插入相同 sql 的時候，主從狀態出現異常。發生主鍵衝突的報錯。

解決方法：

在確保主從數據一致性的前提下，可以在從庫進行錯誤跳過。一般使用 percona-toolkit 中的 pt-slave-restart 進行。

在從庫完成如下操作

[root@zs bin]# ./pt-slave-restart -uroot -proot123

2017-07-20T14:05:30 p=…,u=root node4-relay-bin.000002 1506 1062

之後最好在從庫中開啟 read_only 參數，禁止在從庫進行寫入操作

Last_IO_Errno: 1593（server-id衝突）

Last_IO_Error:

Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids;

these ids must be different for replication to work

(or the –replicate-same-server-id option must be used on slave but this

does not always make sense; please check the manual before using it)

這個報錯出現之後，就看一目了然看到兩台機器的 server-id 是一樣的。

在搭建主從複製的過程中，我們要確保兩台機器的 server-id 是唯一的。這裡再強調一下 server-id 的命名規則（伺服器 ip 地址的最後一位+本 MySQL 服務的埠號）

解決方法：

在主從兩台機器上設置不同的 server-id。

Last_SQL_Errno: 1032（從庫少數據，主庫更新的時候，從庫報錯）

Last_SQL_Error:

Could not execute Update_rows event on table test.t; Can’t find record

in ‘t’, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the

event’s master log mysql-bin.000014, end_log_pos 1708

解決問題的辦法：

根據報錯信息，我們可以獲取到報錯日誌和position號，然後就能找到主庫執行的哪條sql，導致的主從報錯。

在主庫執行：

/usr/local/mysql/bin/mysqlbinlog –no-defaults -v -v –base64-output=decode-rows /data/mysql/mysql-bin.000014 |grep -A 10 1708 1.log

cat 1.log

#170720 14:20:15 server id 3 end_log_pos 1708 CRC32 0x97b6bdec Update_rows: table id 113 flags: STMT_END_F

### UPDATE `test`.`t`

### WHERE

### @1=4 /* INT meta=0 nullable=0 is_null=0 */

### @2=’dd’ /* VARSTRING(60) meta=60 nullable=1 is_null=0 */

### SET

### @1=4 /* INT meta=0 nullable=0 is_null=0 */

### @2=’ddd’ /* VARSTRING(60) meta=60 nullable=1 is_null=0 */

# at 1708

#170720 14:20:15 server id 3 end_log_pos 1739 CRC32 0xecaf1922 Xid = 654

COMMIT/*!*/;

DELIMITER ;

# End of log file

ROLLBACK /* added by mysqlbinlog */;

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

獲取到 sql 語句之後，就可以在從庫反向執行 sql 語句。把從庫缺少的 sql 語句補全，解決報錯信息。

在從庫依次執行：

mysql insert into t (b) values (‘ddd’);

Query OK, 1 row affected (0.01 sec)

mysql stop slave;

Query OK, 0 rows affected (0.00 sec)

mysql exit

Bye

[root@node4 bin]# ./pt-slave-restart -uroot -proot123

2017-07-20T14:31:37 p=…,u=root node4-relay-bin.000005 283 1032

Top 3：MySQL安裝過程中的報錯

[root@zs data]# /usr/local/mysql/bin/mysqld_safe –defaults-file=/etc/my.cnf [1] 3758

[root@zs data]# 170720 14:41:24 mysqld_safe Logging to ‘/data/mysql/error.log’.

170720 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql170720

14:41:25 mysqld_safe mysqld from pid file /data/mysql/node4.pid ended

170720 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql2017-07-20

14:41:25 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated.

Please use –explicit_defaults_for_timestamp server option

(see documentation for more details)./usr/local/mysql/bin/mysqld:

File ‘/data/mysql/mysql-bin.index’ not found (Errcode: 13 – Permission denied)

2017-07-20 14:41:25 4388 [ERROR] Aborting

解決思路：

遇到這樣的報錯信息，我們要學會時時去關注錯誤日誌 error log 裡面的內容。看見了關鍵的報錯點 Permission denied。證明當前 MySQL 資料庫的數據目錄沒有許可權。

解決方法：

[root@zs data]# chown mysql:mysql -R mysql

[root@zs data]# /usr/local/mysql/bin/mysqld_safe –defaults-file=/etc/my.cnf

[1] 4402

[root@zs data]# 170720 14:45:56 mysqld_safe Logging to ‘/data/mysql/error.log’.

170720 14:45:56 mysqld_safe Starting mysqld daemon with databases from /data/mysql

啟動成功。

如何避免這類問題，個人建議在安裝 MySQL 初始化的時候，一定加上–user=mysql，這樣就可以避免許可權問題。

./mysql_install_db –basedir=/usr/local/mysql/ –datadir=/data/mysql/ –defaults-file=/etc/my.cnf –user=mysql

Top 4：資料庫密碼忘記的問題

[root@zs ~]# mysql -uroot -p

Enter password:

ERROR 1045 (28000): Access denied for user ‘root’@’localhost’ (using password: YES)

[root@zs ~]# mysql -uroot -p

Enter password:

ERROR 1045 (28000): Access denied for user ‘root’@’localhost’ (using password: YES)

我們有可能剛剛接手別人的 MySQL 資料庫，而且沒有完善的交接文檔。root 密碼可以丟失或者忘記了。

解決思路：

目前是進入不了資料庫的情況，所以我們要考慮是不是可以跳過許可權。因為在資料庫中，mysql資料庫中user表記錄著我們用戶的信息。

解決方法：

啟動 MySQL 資料庫的過程中，可以這樣執行：

/usr/local/mysql/bin/mysqld_safe –defaults-file=/etc/my.cnf –skip-grant-tables

這樣啟動，就可以不用輸入密碼，直接進入 mysql 資料庫了。然後在修改你自己想要改的root密碼即可。

update mysql.user set password=password(‘root123′) where user=’root’;

Top 5：truncate 刪除數據，導致自動清空自增ID，前端返回報錯 not found。

這個問題的出現，就要考慮下 truncate 和 delete 的區別了。

看下實驗演練：

首先先創建一張表；

CREATE TABLE `t` (

`a` int(11) NOT NULL AUTO_INCREMENT,

`b` varchar(20) DEFAULT NULL,

PRIMARY KEY (`a`),

KEY `b` (`b`)

) ENGINE=InnoDB AUTO_INCREMENT=300 DEFAULT CHARSET=utf8

插入三條數據：

mysql insert into t (b) values (‘aa’);

Query OK, 1 row affected (0.00 sec)

mysql insert into t (b) values (‘bb’);

Query OK, 1 row affected (0.00 sec)

mysql insert into t (b) values (‘cc’);

Query OK, 1 row affected (0.00 sec)

mysql select * from t;

+—–+——+

| a | b |

+—–+——+

| 300 | aa |

| 301 | bb |

| 302 | cc |

+—–+——+

3 rows in set (0.00 sec)

先用 delete 進行刪除全表信息，再插入新值。

結果發現 truncate 把自增初始值重置了，自增屬性從1開始記錄了。當前端用主鍵id進行查詢時，就會報沒有這條數據的錯誤。

個人建議不要使用 truncate 對錶進行刪除操作，雖然可以回收表空間，但是會涉及自增屬性問題。這些坑，我們不要輕易鑽進去。

Top 6：

阿里雲 MySQL 的配置文件中，需要注意一個參數設置就是：

lower_case_table_names = 0;默認情況

lower_case_table_names = 1;是不區分大小寫 . 如果報你小寫的表名找不到, 那你就把遠端資料庫的表名改成小寫 , 反之亦然 . 注意 Mybatis 的 Mapper 文件的所有表名也要相應修改

Top 7：

有同學經常會問張老師，為什麼我的資料庫總會出現中文亂碼的情況。一堆？？？？不知道怎麼回事。當向資料庫中寫入創建表，並插入中文時，會出現這種問題。此報錯會涉及資料庫字符集的問題。

解決思路：

對於中文亂碼的情況，記住老師告訴你的三個統一就可以。還要知道在目前的mysql資料庫中字符集編碼都是默認的UTF8

處理辦法：

1、數據終端，也就是我們連接資料庫的工具設置為 utf8

2、操作系統層面；可以通過 cat /etc/sysconfig/i18n 查看；也要設置為 utf8

3、資料庫層面；在參數文件中的 mysqld 下，加入 character-set-server=utf8。

Emoji 表情符號錄入 mysql 資料庫中報錯。

Caused by: java.sql.SQLException: Incorrect string value: ‘\xF0\x9F\x98\x97\xF0\x9F…’ for column ‘CONTENT’ at row 1

at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1074)

at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4096)

at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4028)

at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490)

at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651)

at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2734)

at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2155)

at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1379)

解決思路：針對錶情插入的問題，一定還是字符集的問題。

處理方法：我們可以直接在參數文件中，加入

vim /etc/my.cnf

[mysqld]

init-connect=’SET NAMES utf8mb4′

character-set-server=utf8mb4

註：utf8mb4 是 utf8 的超集。

Top 8：使用 binlog_format=statement 這種格式，跨庫操作，導致從庫丟失數據，用戶訪問導致出現錯誤數據信息。

當前資料庫二進位日誌的格式為：binlog_format=statement

在主庫設置binlog-do-db=mydb1（只同步mydb1這一個庫）

在主庫執行use mydb2；

insert into mydb1.t1 values (‘bb’);這條語句不會同步到從庫。

但是這樣操作就可以；

use mydb1;

insert into mydb1.t1 values (‘bb’);因為這是在同一個庫中完成的操作。

在生產環境中建議使用binlog的格式為row，而且慎用binlog-do-db參數。

Top 9：MySQL 資料庫連接超時的報錯 ；

org.hibernate.util.JDBCExceptionReporter – SQL Error:0, SQLState: 08S01

org.hibernate.util.JDBCExceptionReporter – The last packet successfully received from the server was43200 milliseconds ago.The last packet sent successfully to the server was 43200 milliseconds ago, which is longer than the server configured value of ‘wait_timeout’. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection ‘autoReconnect=true’ to avoid this problem.

org.hibernate.event.def.AbstractFlushingEventListener – Could not synchronize database state with session

org.hibernate.exception.JDBCConnectionException: Could not execute JDBC batch update

com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Connection.close() has already been called. Invalid operation in this state.

org.hibernate.util.JDBCExceptionReporter – SQL Error:0, SQLState: 08003

org.hibernate.util.JDBCExceptionReporter – No operations allowed after connection closed. Connection was implicitly closed due to underlying exception/error:

** BEGIN NESTED EXCEPTION **

大多數做 DBA 的同學，可能都會被開發人員告知，你們的資料庫報了這個錯誤了。趕緊看看是哪裡的問題。

這個問題是由兩個參數影響的，wait_timeout 和 interactive_timeout。數據默認的配置時間是28800（8小時）意味著，超過這個時間之後，MySQL 資料庫為了節省資源，就會在資料庫端斷開這個連接，Mysql伺服器端將其斷開了，但是我們的程序再次使用這個連接時沒有做任何判斷，所以就掛了。

解決思路：

先要了解這兩個參數的特性；這兩個參數必須同時設置，而且必須要保證值一致才可以。

我們可以適當加大這個值，8小時太長了，不適用於生產環境。因為一個連接長時間不工作，還佔用我們的連接數，會消耗我們的系統資源。

解決方法：

可以適當在程序中做判斷；強烈建議在操作結束時更改應用程序邏輯以正確關閉連接；然後設置一個比較合理的timeout的值（根據業務情況來判斷）

Top 10 ：can’t open file (errno:24)

有的時候，資料庫跑得好好的，突然報不能打開資料庫文件的錯誤了。

解決思路：

首先我們要先查看資料庫的 error log。然後判斷是表損壞，還是許可權問題。還有可能磁碟空間不足導致的不能正常訪問表；操作系統的限制也要關注下；用 perror 工具查看具體錯誤！

linux:/usr/local/mysql/bin # ./perror 24

OS error code 24: Too many open files

超出最大打開文件數限制！ulimit -n查看系統的最大打開文件數是65535，不可能超出！那必然是資料庫的最大打開文件數超出限制！

在 MySQL 里查看最大打開文件數限制命令：show variables like ‘open_files_limit’;

發現該數值過小，改為2048，重啟 MySQL，應用正常

處理方法：

repair table ；

chown mysql許可權

清理磁碟中的垃圾數據