MySQL數據庫「十宗罪」【十大經典錯誤案例】

Top 1：Too many connections（鏈接數過多，致使鏈接不上數據庫，業務沒法正常進行）

問題還原:

解決問題的思路：

• 一、首先先要考慮在咱們 MySQL 數據庫參數文件裏面，對應的max_connections 這個參數值是否是設置的過小了，致使客戶端鏈接數超過了數據庫所承受的最大值。
  ● 該值默認大小是151，咱們能夠根據實際狀況進行調整。
  ● 對應解決辦法：set global max_connections=500
  但這樣調整會有隱患，由於咱們沒法確認數據庫是否能夠承擔這麼大的鏈接壓力，就比如原來一我的只能吃一個饅頭，但如今卻非要讓他吃 10 個，他確定接受不了。反應到服務器上面，就有可能會出現宕機的可能。
  因此這又反應出了，咱們在新上線一個業務系統的時候，要作好壓力測試。保證後期對數據庫進行優化調整。

• 二、其次能夠限制Innodb 的併發處理數量，若是 innodb_thread_concurrency = 0（這種表明不受限制） 能夠先改爲 16或是64 看服務器壓力。若是很是大，能夠先改的小一點讓服務器的壓力下來以後,而後再慢慢增大,根據本身的業務而定。我的建議能夠先調整爲 16 便可。
  MySQL 隨着鏈接數的增長性能是會降低的，可讓開發配合設置 thread pool，鏈接複用。在MySQL商業版中加入了thread pool這項功能,另外對於有的監控程序會讀取 information_schema 下面的表，能夠考慮關閉下面的參數

 

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

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

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

解決方法：

在確保主從數據一致性的前提下，能夠在從庫進行錯誤跳過。通常使用 percona-toolkit 中的 pt-slave-restart 進行。
在從庫完成以下操做

• 以後最好在從庫中開啓 read_only 參數，禁止在從庫進行寫入操做

Last_IO_Errno: 1593（server-id衝突）

在搭建主從複製的過程當中，咱們要確保兩臺機器的 server-id 是惟一的。這裏再強調一下 server-id 的命名規則（服務器 ip 地址的最後一位+本 MySQL 服務的端口號）

解決方法：

在主從兩臺機器上設置不一樣的 server-id。

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

解決問題的辦法：

根據報錯信息，咱們能夠獲取到報錯日誌和position號，而後就能找到主庫執行的哪條sql，致使的主從報錯。
在主庫執行：

獲取到 sql 語句以後，就能夠在從庫反向執行 sql 語句。把從庫缺乏的 sql 語句補全，解決報錯信息。
在從庫依次執行：

 

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

解決思路：

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

解決方法：

如何避免這類問題，我的建議在安裝MySQL初始化的時候，必定加上--user=mysql，這樣就能夠避免權限問題。

 

Top 4：數據庫密碼忘記的問題

解決思路：

目前是進入不了數據庫的狀況，因此咱們要考慮是否是能夠跳過權限。由於在數據庫中，mysql數據庫中user表記錄着咱們用戶的信息。

解決方法：

啓動 MySQL 數據庫的過程當中，能夠這樣執行：

 

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

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

看下實驗演練：

結果發現truncate把自增初始值重置了，自增屬性從1開始記錄了。當前端用主鍵id進行查詢時，就會報沒有這條數據的錯誤。
我的建議不要使用truncate對錶進行刪除操做，雖然能夠回收表空間，可是會涉及自增屬性問題。這些坑，咱們不要輕易鑽進去。

 

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

 

Top 7：數據庫總會出現中文亂碼的狀況

解決思路：

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

處理辦法：

一、數據終端，也就是咱們鏈接數據庫的工具設置爲 utf8
二、操做系統層面；能夠經過 cat /etc/sysconfig/i18n 查看；也要設置爲 utf8
三、數據庫層面；在參數文件中的 mysqld 下，加入 character-set-server=utf8。

Emoji 表情符號錄入 mysql 數據庫中報錯。

解決思路：針對表情插入的問題，必定仍是字符集的問題。
處理方法：咱們能夠直接在參數文件中，加入

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

 

Top 9：MySQL 數據庫鏈接超時的報錯 

這個問題是由兩個參數影響的，wait_timeout 和 interactive_timeout。數據默認的配置時間是28800（8小時）意味着，超過這個時間以後，MySQL 數據庫爲了節省資源，就會在數據庫端斷開這個鏈接，Mysql服務器端將其斷開了，可是咱們的程序再次使用這個鏈接時沒有作任何判斷，因此就掛了。

解決思路：

先要了解這兩個參數的特性；這兩個參數必須同時設置，並且必需要保證值一致才能夠。
咱們能夠適當加大這個值，8小時太長了，不適用於生產環境。由於一個鏈接長時間不工做，還佔用咱們的鏈接數，會消耗咱們的系統資源。

解決方法：

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

 

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

有的時候，數據庫跑得好好的，忽然報不能打開數據庫文件的錯誤了。

解決思路：

首先咱們要先查看數據庫的error log。而後判斷是表損壞，仍是權限問題。還有可能磁盤空間不足致使的不能正常訪問表；操做系統的限制也要關注下；用 perror 工具查看具體錯誤！

超出最大打開文件數限制！ulimit -n查看系統的最大打開文件數是65535，不可能超出！那必然是數據庫的最大打開文件數超出限制！
在MySQL裏查看最大打開文件數限制命令：

show variables like 'open_files_limit';

處理方法：

 

原文做者：張甦

來源：http://blog.51cto.com/sumongodb

https://mp.weixin.qq.com/s/DVoBlBBwcvZ3zqhvflTWTg