1、Too many connections

（連接數(shù)過多，導(dǎo)致連接不上數(shù)據(jù)庫，業(yè)務(wù)無法正常進(jìn)行）
[root@lianjiu ~]# mysql -uzs -p123456 -h 10.0.122.124
ERROR 1040 (00000): Too many connections
解決問題的思路：
1、首先先要考慮在我們 MySQL 數(shù)據(jù)庫參數(shù)文件里面，對(duì)應(yīng)的 max_connections 這個(gè)參數(shù)值是不是設(shè)置的太小了，導(dǎo)致客戶端連接數(shù)超過了數(shù)據(jù)庫所承受的最大值。
該值默認(rèn)大小是 151，我們可以根據(jù)實(shí)際情況進(jìn)行調(diào)整。
對(duì)應(yīng)解決辦法：set global max_connections=500
但這樣調(diào)整會(huì)有隱患，因?yàn)槲覀儫o法確認(rèn)數(shù)據(jù)庫是否可以承擔(dān)這么大的連接壓力，就好比原來一個(gè)人只能吃一個(gè)饅頭，但現(xiàn)在卻非要讓他吃 10 個(gè)，他肯定接受不了。反應(yīng)到服務(wù)器上面，就有可能會(huì)出現(xiàn)宕機(jī)的可能。
所以這又反映出了，我們?cè)谛律暇€一個(gè)業(yè)務(wù)系統(tǒng)的時(shí)候，要做好壓力測試。保證后期對(duì)數(shù)據(jù)庫進(jìn)行優(yōu)化調(diào)整。
2、其次可以限制 InnoDB的并發(fā)處理數(shù)量，如果 innodb_thread_concurrency = 0（這種代表不受限制） 可以先改成 16 或是 64 看服務(wù)器壓力。
如果非常大，可以先改的小一點(diǎn)讓服務(wù)器的壓力下來之后，然后再慢慢增大，根據(jù)自己的業(yè)務(wù)而定，個(gè)人建議可以先調(diào)整為 16 即可。
MySQL 隨著連接數(shù)的增加性能是會(huì)下降的，在 MySQL 5.7 之前都需要讓開發(fā)配合設(shè)置 thread pool，連接復(fù)用。MySQL 5.7 之后數(shù)據(jù)庫自帶 thread pool 了，連接數(shù)問題也得到了相應(yīng)的解決。
另外對(duì)于有的監(jiān)控程序會(huì)讀取 information_schema 下面的表，可以考慮關(guān)閉下面的參數(shù)：
innodb_stats_on_metadata=0
set global innodb_stats_on_metadata=0

2、can't open file (errno:24)

有的時(shí)候，數(shù)據(jù)庫跑得好好的，突然報(bào)不能打開數(shù)據(jù)庫文件的錯(cuò)誤了。

解決思路：
首先我們要先查看數(shù)據(jù)庫的error log。然后判斷是表損壞，還是權(quán)限問題。還有可能磁盤空間不足導(dǎo)致的不能正常訪問表；操作系統(tǒng)的限制也要關(guān)注下；用 perror 工具查看具體錯(cuò)誤！

linux:/usr/local/mysql/bin # ./perror 24OS error code 24: Too many open files
超出最大打開文件數(shù)限制！ulimit -n查看系統(tǒng)的最大打開文件數(shù)是65535，不可能超出！那必然是數(shù)據(jù)庫的最大打開文件數(shù)超出限制！在 MySQL 里查看最大打開文件數(shù)限制命令：show variables like 'open_files_limit';發(fā)現(xiàn)該數(shù)值過小，改為2048，重啟 MySQL，應(yīng)用正常

3、MySQL 數(shù)據(jù)庫連接超時(shí)的報(bào)錯(cuò)

這個(gè)問題是由兩個(gè)參數(shù)影響的，wait_timeout 和 interactive_timeout。數(shù)據(jù)默認(rèn)的配置時(shí)間是28800（8小時(shí)）意味著，超過這個(gè)時(shí)間之后，MySQL 數(shù)據(jù)庫為了節(jié)省資源，就會(huì)在數(shù)據(jù)庫端斷開這個(gè)連接，Mysql服務(wù)器端將其斷開了，但是我們的程序再次使用這個(gè)連接時(shí)沒有做任何判斷，所以就掛了。

解決思路：
先要了解這兩個(gè)參數(shù)的特性；這兩個(gè)參數(shù)必須同時(shí)設(shè)置，而且必須要保證值一致才可以。我們可以適當(dāng)加大這個(gè)值，8小時(shí)太長了，不適用于生產(chǎn)環(huán)境。因?yàn)橐粋€(gè)連接長時(shí)間不工作，還占用我們的連接數(shù)，會(huì)消耗我們的系統(tǒng)資源。

解決方法：
可以適當(dāng)在程序中做判斷；強(qiáng)烈建議在操作結(jié)束時(shí)更改應(yīng)用程序邏輯以正確關(guān)閉連接；然后設(shè)置一個(gè)比較合理的timeout的值（根據(jù)業(yè)務(wù)情況來判斷）

4、數(shù)據(jù)庫總會(huì)出現(xiàn)中文亂碼的情況

解決思路：
對(duì)于中文亂碼的情況，記住老師告訴你的三個(gè)統(tǒng)一就可以。還要知道在目前的mysql數(shù)據(jù)庫中字符集編碼都是默認(rèn)的UTF8

處理辦法：
1、數(shù)據(jù)終端，也就是我們連接數(shù)據(jù)庫的工具設(shè)置為 utf8
2、操作系統(tǒng)層面；可以通過 cat /etc/sysconfig/i18n 查看；也要設(shè)置為 utf8
3、數(shù)據(jù)庫層面；在參數(shù)文件中的 mysqld 下，加入 character-set-server=utf8。

5、truncate 刪除數(shù)據(jù)，導(dǎo)致自動(dòng)清空自增ID，前端返回報(bào)錯(cuò) not found。

這個(gè)問題的出現(xiàn)，就要考慮下truncate 和 delete 的區(qū)別了。

看下實(shí)驗(yàn)演練：

首先先創(chuàng)建一張表；

先用 delete 進(jìn)行刪除全表信息，再插入新值。
結(jié)果發(fā)現(xiàn)truncate把自增初始值重置了，自增屬性從1開始記錄了。當(dāng)前端用主鍵id進(jìn)行查詢時(shí)，就會(huì)報(bào)沒有這條數(shù)據(jù)的錯(cuò)誤。個(gè)人建議不要使用truncate對(duì)表進(jìn)行刪除操作，雖然可以回收表空間，但是會(huì)涉及自增屬性問題