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 下面的表，可以考慮關閉下面的引數

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

處理辦法：

1、資料終端，也就是我們連線資料庫的工具設定為 utf8

2、作業系統層面；可以通過 cat /etc/sysconfig/i18n 檢視；也要設定為 utf8

3、資料庫層面；在引數檔案中的 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';

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

處理方法：

今後還會繼續總結 MySQL 中的各種報錯處理思路與方法，希望跟各位老鐵們，同學們一起努力。多溝通多交流！

看到這裡的各位老司機們，把此文轉發出去吧，讓更多的人成為老司機。