今天就給大家列舉 MySQL 數(shù)據(jù)庫(kù)中臊旭，最經(jīng)典的十大錯(cuò)誤案例，并附有處理問題的解決思路和方法锨能，希望能給剛?cè)胄谐对伲驍?shù)據(jù)庫(kù)愛好者一些幫助，今后再遇到任何報(bào)錯(cuò)址遇，我們都可以很淡定地去處理熄阻。學(xué)習(xí)任何一門技術(shù)的同時(shí)，其實(shí)就是自我修煉的過程倔约。沉下心秃殉，嘗試去擁抱數(shù)據(jù)的世界！
Top 1：Too many connections（連接數(shù)過多浸剩，導(dǎo)致連接不上數(shù)據(jù)庫(kù)钾军，業(yè)務(wù)無(wú)法正常進(jìn)行）
問題還原:
解決問題的思路：
1、首先先要考慮在我們 MySQL 數(shù)據(jù)庫(kù)參數(shù)文件里面乒省，對(duì)應(yīng)的max_connections 這個(gè)參數(shù)值是不是設(shè)置的太小了，導(dǎo)致客戶端連接數(shù)超過了數(shù)據(jù)庫(kù)所承受的最大值畦木。
● 該值默認(rèn)大小是151袖扛，我們可以根據(jù)實(shí)際情況進(jìn)行調(diào)整。
● 對(duì)應(yīng)解決辦法：set global max_connections=500
但這樣調(diào)整會(huì)有隱患十籍，因?yàn)槲覀儫o(wú)法確認(rèn)數(shù)據(jù)庫(kù)是否可以承擔(dān)這么大的連接壓力蛆封，就好比原來(lái)一個(gè)人只能吃一個(gè)饅頭，但現(xiàn)在卻非要讓他吃 10 個(gè)勾栗，他肯定接受不了惨篱。反應(yīng)到服務(wù)器上面，就有可能會(huì)出現(xiàn)宕機(jī)的可能围俘。
所以這又反應(yīng)出了砸讳，我們?cè)谛律暇€一個(gè)業(yè)務(wù)系統(tǒng)的時(shí)候，要做好壓力測(cè)試界牡。保證后期對(duì)數(shù)據(jù)庫(kù)進(jìn)行優(yōu)化調(diào)整簿寂。【Mysql高性能優(yōu)化規(guī)范建議】
2宿亡、其次可以限制Innodb 的并發(fā)處理數(shù)量常遂，如果 innodb_thread_concurrency = 0（這種代表不受限制） 可以先改成 16或是64 看服務(wù)器壓力。如果非常大挽荠，可以先改的小一點(diǎn)讓服務(wù)器的壓力下來(lái)之后,然后再慢慢增大,根據(jù)自己的業(yè)務(wù)而定克胳。個(gè)人建議可以先調(diào)整為 16 即可平绩。
MySQL 隨著連接數(shù)的增加性能是會(huì)下降的，可以讓開發(fā)配合設(shè)置 thread pool漠另，連接復(fù)用捏雌。在MySQL商業(yè)版中加入了thread pool這項(xiàng)功能,另外對(duì)于有的監(jiān)控程序會(huì)讀取 information_schema 下面的表，可以考慮關(guān)閉下面的參數(shù)
Top 2：（主從復(fù)制報(bào)錯(cuò)類型）
Last_SQL_Errno: 1062 ?（從庫(kù)與主庫(kù)數(shù)據(jù)沖突）
針對(duì)這個(gè)報(bào)錯(cuò)酗钞，我們首先要考慮是不是在從庫(kù)中誤操作導(dǎo)致的腹忽。結(jié)果發(fā)現(xiàn)，我們?cè)趶膸?kù)中進(jìn)行了一條針對(duì)有主鍵表的 sql 語(yǔ)句的插入砚作，導(dǎo)致主庫(kù)再插入相同 sql 的時(shí)候窘奏，主從狀態(tài)出現(xiàn)異常。發(fā)生主鍵沖突的報(bào)錯(cuò)葫录。
解決方法：
在確保主從數(shù)據(jù)一致性的前提下着裹，可以在從庫(kù)進(jìn)行錯(cuò)誤跳過。一般使用 percona-toolkit 中的 pt-slave-restart 進(jìn)行米同。
在從庫(kù)完成如下操作
之后最好在從庫(kù)中開啟 read_only 參數(shù)骇扇，禁止在從庫(kù)進(jìn)行寫入操作
Last_IO_Errno: 1593（server-id沖突）
在搭建主從復(fù)制的過程中，我們要確保兩臺(tái)機(jī)器的 server-id 是唯一的面粮。這里再?gòu)?qiáng)調(diào)一下 server-id 的命名規(guī)則（服務(wù)器 ip 地址的最后一位+本 MySQL 服務(wù)的端口號(hào)）【MySQL 主從復(fù)制與讀寫分離概念及架構(gòu)分析】
解決方法：
在主從兩臺(tái)機(jī)器上設(shè)置不同的 server-id少孝。
Last_SQL_Errno: 1032（從庫(kù)少數(shù)據(jù)，主庫(kù)更新的時(shí)候熬苍，從庫(kù)報(bào)錯(cuò)）
解決問題的辦法：
根據(jù)報(bào)錯(cuò)信息稍走，我們可以獲取到報(bào)錯(cuò)日志和position號(hào)，然后就能找到主庫(kù)執(zhí)行的哪條sql柴底，導(dǎo)致的主從報(bào)錯(cuò)婿脸。
在主庫(kù)執(zhí)行：
獲取到 sql 語(yǔ)句之后，就可以在從庫(kù)反向執(zhí)行 sql 語(yǔ)句柄驻。把從庫(kù)缺少的 sql 語(yǔ)句補(bǔ)全狐树，解決報(bào)錯(cuò)信息『枧В【一千行 MySQL 學(xué)習(xí)筆記】
在從庫(kù)依次執(zhí)行：
Top 3：MySQL安裝過程中的報(bào)錯(cuò)
解決思路：
遇到這樣的報(bào)錯(cuò)信息抑钟，我們要學(xué)會(huì)時(shí)時(shí)去關(guān)注錯(cuò)誤日志 error log 里面的內(nèi)容∫翱蓿看見了關(guān)鍵的報(bào)錯(cuò)點(diǎn)Permission denied味赃。證明當(dāng)前 MySQL 數(shù)據(jù)庫(kù)的數(shù)據(jù)目錄沒有權(quán)限。
解決方法：
如何避免這類問題虐拓，個(gè)人建議在安裝MySQL初始化的時(shí)候心俗，一定加上--user=mysql，這樣就可以避免權(quán)限問題。
Top 4：數(shù)據(jù)庫(kù)密碼忘記的問題
解決思路：
目前是進(jìn)入不了數(shù)據(jù)庫(kù)的情況城榛，所以我們要考慮是不是可以跳過權(quán)限揪利。因?yàn)樵跀?shù)據(jù)庫(kù)中，mysql數(shù)據(jù)庫(kù)中user表記錄著我們用戶的信息狠持。
解決方法：
啟動(dòng) MySQL 數(shù)據(jù)庫(kù)的過程中疟位，可以這樣執(zhí)行：
Top 5：truncate 刪除數(shù)據(jù)，導(dǎo)致自動(dòng)清空自增ID喘垂，前端返回報(bào)錯(cuò) not found甜刻。
這個(gè)問題的出現(xiàn)，就要考慮下truncate 和 delete 的區(qū)別了正勒。
看下實(shí)驗(yà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ì)涉及自增屬性問題蜕径。這些坑，我們不要輕易鉆進(jìn)去败京。
Top 6：阿里云 MySQL 的配置文件中兜喻，需要注意一個(gè)參數(shù)設(shè)置就是：
Top 7：數(shù)據(jù)庫(kù)總會(huì)出現(xiàn)中文亂碼的情況
解決思路：
對(duì)于中文亂碼的情況，記住老師告訴你的三個(gè)統(tǒng)一就可以赡麦。還要知道在目前的mysql數(shù)據(jù)庫(kù)中字符集編碼都是默認(rèn)的UTF8【徹底解決MySQL中文亂碼】
處理辦法：
1朴皆、數(shù)據(jù)終端，也就是我們連接數(shù)據(jù)庫(kù)的工具設(shè)置為 utf8
2隧甚、操作系統(tǒng)層面车荔；可以通過 cat /etc/sysconfig/i18n 查看渡冻；也要設(shè)置為 utf8
3戚扳、數(shù)據(jù)庫(kù)層面；在參數(shù)文件中的 mysqld 下族吻，加入 character-set-server=utf8帽借。
Emoji 表情符號(hào)錄入 mysql 數(shù)據(jù)庫(kù)中報(bào)錯(cuò)。
解決思路：針對(duì)表情插入的問題超歌，一定還是字符集的問題砍艾。
處理方法：我們可以直接在參數(shù)文件中，加入
Top 8：使用 binlog_format=statement 這種格式巍举，跨庫(kù)操作脆荷，導(dǎo)致從庫(kù)丟失數(shù)據(jù)，用戶訪問導(dǎo)致出現(xiàn)錯(cuò)誤數(shù)據(jù)信息。
Top 9：MySQL 數(shù)據(jù)庫(kù)連接超時(shí)的報(bào)錯(cuò)?
這個(gè)問題是由兩個(gè)參數(shù)影響的蜓谋，wait_timeout 和 interactive_timeout梦皮。數(shù)據(jù)默認(rèn)的配置時(shí)間是28800（8小時(shí)）意味著，超過這個(gè)時(shí)間之后桃焕，MySQL 數(shù)據(jù)庫(kù)為了節(jié)省資源剑肯，就會(huì)在數(shù)據(jù)庫(kù)端斷開這個(gè)連接，Mysql服務(wù)器端將其斷開了观堂，但是我們的程序再次使用這個(gè)連接時(shí)沒有做任何判斷让网，所以就掛了。
解決思路：
先要了解這兩個(gè)參數(shù)的特性师痕；這兩個(gè)參數(shù)必須同時(shí)設(shè)置溃睹，而且必須要保證值一致才可以。
我們可以適當(dāng)加大這個(gè)值七兜，8小時(shí)太長(zhǎng)了丸凭，不適用于生產(chǎn)環(huán)境。因?yàn)橐粋€(gè)連接長(zhǎng)時(shí)間不工作腕铸，還占用我們的連接數(shù)惜犀，會(huì)消耗我們的系統(tǒng)資源。
解決方法：
可以適當(dāng)在程序中做判斷狠裹；強(qiáng)烈建議在操作結(jié)束時(shí)更改應(yīng)用程序邏輯以正確關(guān)閉連接虽界；然后設(shè)置一個(gè)比較合理的timeout的值（根據(jù)業(yè)務(wù)情況來(lái)判斷）
Top 10 ：can't open file (errno:24)
有的時(shí)候，數(shù)據(jù)庫(kù)跑得好好的涛菠，突然報(bào)不能打開數(shù)據(jù)庫(kù)文件的錯(cuò)誤了莉御。
解決思路：
首先我們要先查看數(shù)據(jù)庫(kù)的error log。然后判斷是表?yè)p壞俗冻，還是權(quán)限問題礁叔。還有可能磁盤空間不足導(dǎo)致的不能正常訪問表；操作系統(tǒng)的限制也要關(guān)注下迄薄；用 perror 工具查看具體錯(cuò)誤琅关！
超出最大打開文件數(shù)限制！ulimit -n查看系統(tǒng)的最大打開文件數(shù)是65535讥蔽，不可能超出涣易！那必然是數(shù)據(jù)庫(kù)的最大打開文件數(shù)超出限制！
在MySQL里查看最大打開文件數(shù)限制命令：
show variables like 'open_files_limit';
處理方法：
擴(kuò)展閱讀
軟件開發(fā)團(tuán)隊(duì)最常見的錯(cuò)誤冶伞，你遇到過嗎新症？
Java程序員最常犯的錯(cuò)誤盤點(diǎn)之Top 10
書寫「簡(jiǎn)歷」時(shí)，需要規(guī)避的錯(cuò)誤
MySQL數(shù)據(jù)庫(kù)的多表查詢以及外鍵約束
SpringBoot+MyBatis+MySQL讀寫分離（實(shí)例）
來(lái)源：https://blog.51cto.com/sumongodb/1949426
