來源：https://jeames.blog.csdn.net/?type=blog

前言

今天就給大家列舉 MySQL 數(shù)據(jù)庫(kù)中，最經(jīng)典的八大錯(cuò)誤案例，并附有處理問題的解決思路和方法，希望能給剛?cè)胄校驍?shù)據(jù)庫(kù)愛好者一些幫助。

?? 1.忘記密碼，無法登陸

?? 1.1 報(bào)錯(cuò)現(xiàn)象

ERROR 1130 (HY000): Host ‘172.18.1.1’ is not allowed to connect to this MySQL server --提示無法登陸

?? 1.2 處理過程

在MySQL中，若密碼丟失則無法直接找回，只能通過特殊方式來修改密碼。
在配置文件中添加如下一行，重啟 MySQL 登錄則不需要密碼。
skip-grant-tables

cat /etc/my.cnf

重啟 MySQL
systemctl start mysqld
[root@binlog2sql ~]# mysql -uroot -p
–此時(shí)空密碼可以進(jìn)入
?? MySQL8修改密碼

mysql> alter user root@‘localhost’ identified with mysql_native_password by ‘root1’;
?? MySQL8以下版本修改密碼

mysql> update mysql.user set authentication_string=password(‘root’) where user=‘root’;
mysql> flush privileges;

最好把/etc/my.cnf中的skip-grant-tables注釋掉，然后重啟mysql，即：service mysqld restart
好了，下面就可以用r新的密碼登錄了！

?? 2.修改簡(jiǎn)易密碼報(bào)錯(cuò)

?? 2.1 報(bào)錯(cuò)現(xiàn)象

alter user root@‘localhost’ identified with mysql_native_password by ‘root’;

ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

?? 2.1 處理過程

查詢密碼策略
mysql> SHOW VARIABLES LIKE ‘validate_password%’;

去除密碼驗(yàn)證策略
–默認(rèn)關(guān)閉，設(shè)置為ON時(shí)可以將密碼設(shè)置成當(dāng)前用戶名
mysql> set global validate_password.check_user_name=OFF;

–密碼強(qiáng)度檢查等級(jí)，0/LOW、1/MEDIUM、2/STRONG。默認(rèn)是1，即MEDIUM，
mysql> set global validate_password_policy=0;
mysql> set global validate_password.length=4;

–特殊字符
mysql> set global validate_password.mixed_case_count=0;
mysql> set global validate_password.number_count=0;

mysql> flush privileges;
–密碼驗(yàn)證策略
0/LOW：只檢查長(zhǎng)度。
1/MEDIUM：檢查長(zhǎng)度、數(shù)字、大小寫、特殊字符
2/STRONG：檢查長(zhǎng)度、數(shù)字、大小寫、特殊字符字典文件。

此時(shí)修改為密碼root則OK，因?yàn)橐呀?jīng)去除密碼策略

?? 3.大小寫的敏感報(bào)錯(cuò)

?? 2.1 報(bào)錯(cuò)現(xiàn)象

最近接了一個(gè)項(xiàng)目跟團(tuán)隊(duì)在開發(fā)，在自己本機(jī)Windows上開發(fā)和測(cè)試過程中一直沒有問題，

臨近項(xiàng)目交付的時(shí)候，部署到Linux服務(wù)器上后，發(fā)現(xiàn)有報(bào)錯(cuò)，日志信息大概是：
MySQLSyntaxErrorException: Table ‘mes_db.student’ doesn’t exist

?? 2.2 處理過程

??在本機(jī)Window環(huán)境查看如下：
mysql> show variables like ‘%case%’;

??在Linux服務(wù)器查看如下：

出現(xiàn)了問題，有點(diǎn)郁悶，本地開發(fā)好好的，怎么部署服務(wù)器就不行了。
有鬼…不過莫慌?？粗e(cuò)誤提示很明顯，不就是student表不存在嗎！

①于是我不慌不忙打開navicat，查看這個(gè)表在不在，一看還真在，
數(shù)據(jù)庫(kù)中顯示的student，不過s是小寫；

②查看代碼發(fā)現(xiàn)代碼中還真把表名寫成Student,就一個(gè)s寫成大寫S了。
問題找到了，原來是不小心寫SQL的時(shí)候沒有寫對(duì)表名，改一下表名就搞定了，功能也一切正常了

從上面的結(jié)果已經(jīng)可以看出不同了
當(dāng) lower_case_table_names 為 0 時(shí)表示區(qū)分大小寫，為 1 時(shí)表示不區(qū)分大小寫
在Windows上，默認(rèn)值為1；在macOS上，默認(rèn)值為2；在Linux上不支持值2;服務(wù)器強(qiáng)制該值為0

0 --大小寫敏感。（Unix，Linux默認(rèn)）
1–大小寫不敏感。（Windows默認(rèn)）
2 --大小寫不敏感（macOS默認(rèn)）

并且官網(wǎng)也提示說：如果在數(shù)據(jù)目錄駐留在不區(qū)分大小寫的文件系統(tǒng)
（例如Windows或macOS）上的系統(tǒng)上運(yùn)行MySQL，
則不應(yīng)將lower_case_table_names設(shè)置為0。

我自己在我的window10環(huán)境嘗試設(shè)置lower_case_table_names為0的時(shí)候，
MySQL的服務(wù)怎么也啟動(dòng)不能，啟動(dòng)服務(wù)報(bào)錯(cuò)，因?yàn)閣indows系統(tǒng)對(duì)大小寫不敏感

而Linux則是區(qū)分大小寫的，因此，建議在開發(fā)測(cè)試環(huán)境下就嚴(yán)格控制代碼大小寫敏感，
提高代碼的兼容和嚴(yán)謹(jǐn)

?? 4.MySQL無法啟動(dòng)

?? 4.1 報(bào)錯(cuò)現(xiàn)象

Windows 無法啟動(dòng)Mysql服務(wù) 錯(cuò)誤1053：服務(wù)沒有及時(shí)響應(yīng)啟動(dòng)或控制請(qǐng)求

?? 4.2 處理過程

?? 結(jié)束進(jìn)程
1、在命令行中敲入tasklist查看進(jìn)程

2、根據(jù)進(jìn)程名殺死進(jìn)程
taskkill /f /t /im 進(jìn)程名稱

1）、計(jì)算機(jī)->管理->本地用戶和組->組 雙擊，效果圖如下：

（2）、雙擊Administrators，并點(diǎn)擊添加,再點(diǎn)擊高級(jí)
（3）、把 NETWORK SERVICE添加到Administrators組

此處記住，重新安裝Mysql就可以，2步操作重新執(zhí)行（刪除原有Mysql文件，全部重新安裝即可）
還有個(gè)坑就是，如果還是啟動(dòng)不了， 記得要開啟這個(gè)服務(wù)Windows Installer

Windows Installer是一種通用的軟件發(fā)布方式，用于安裝軟件。
默認(rèn)情況下，該服務(wù)是手動(dòng)啟動(dòng)，需要進(jìn)入服務(wù)管理中開啟。

右擊開始——運(yùn)行——輸入“services.msc”——Windows Installer——啟動(dòng)

?? 5.導(dǎo)出與導(dǎo)入報(bào)錯(cuò)

?? 5.1 報(bào)錯(cuò)現(xiàn)象

在進(jìn)行數(shù)據(jù)導(dǎo)出的時(shí)候出現(xiàn):
secure-file-priv option so it cannot execute this statement

?? 5.2 處理過程

直需要修改參數(shù)文件即可
echo “secure-file-priv=” >> /etc/my.cnf
secure-file-priv

參數(shù)是用來限制 LOAD DATA, SELECT … OUTFILE, and LOAD_FILE()傳到哪個(gè)指定目錄的。
a.seure_file_priv 的值為 null ，表示限制 mysqld 不允許導(dǎo)入|導(dǎo)出

b.當(dāng) secure_file_priv 的值為/tmp/ ，表示限制 mysqld 的導(dǎo)入|導(dǎo)出只能發(fā)生在/tmp/目錄下
c.當(dāng) secure_file_priv 的值沒有具體值時(shí)，表示不對(duì) mysqld 的導(dǎo)入|導(dǎo)出做限制

修改參數(shù)只能在服務(wù)器參數(shù)文件中修改，修改后重新服務(wù)器：
secure-file-priv=

?? 導(dǎo)出命令
select host,user from mysql.user into outfile ‘/tmp/user.csv’
Fields terminated by ‘,’ enclosed by ‘"’;

逗號(hào)分割,雙引號(hào)閉合
注意：導(dǎo)出的文件只能在服務(wù)器上

?? 6.連接數(shù)過多，無法連接MySQL

?? 6.1 報(bào)錯(cuò)現(xiàn)象

?? 6.2 處理過程

解決問題的思路：
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法確認(rèn)數(shù)據(jù)庫(kù)是否可以承擔(dān)這么大的連接壓力，就好比原來一個(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)整。
2、其次可以限制Innodb 的并發(fā)處理數(shù)量 ，如果 innodb_thread_concurrency = 0（這種代表不受限制） 可以先改成 16或是64 看服務(wù)器壓力。如果非常大，可以先改的小一點(diǎn)讓服務(wù)器的壓力下來之后,然后再慢慢增大,根據(jù)自己的業(yè)務(wù)而定。個(gè)人建議可以先調(diào)整為 16 即可。

?? 7.磁盤爆滿，無法寫二進(jìn)制日志

?? 7.1 報(bào)錯(cuò)現(xiàn)象

Binlog是MySQL中一個(gè)很重要的日志，記錄了對(duì)數(shù)據(jù)庫(kù)進(jìn)行變更的操作，
但是不包括 select操作以及 show 操作，因?yàn)檫@類操作對(duì)數(shù)據(jù)庫(kù)本身沒有沒有修改。

如果想記錄 select和 show 的話，那就需要開啟全查詢?nèi)罩尽?/span>
另外 binlog 還包括了執(zhí)行數(shù)據(jù)庫(kù)更改操作時(shí)間和執(zhí)行時(shí)間等信息。
binlog 是 MySQL Server 層記錄的二進(jìn)制日志文件，邏輯層面

?? 7.2 清理二進(jìn)制日志

mysql> show variables like ‘%binlog_expire_logs_seconds%’ ;

mysql 8開始 expire_logs_days廢棄
啟用binlog_expire_logs_seconds設(shè)置binlog自動(dòng)清除日志時(shí)間
保存時(shí)間 以秒為單位；默認(rèn)2592000 30天

14400 4小時(shí)；86400 1天；259200 3天
##自動(dòng)刪除
mysql> set global binlog_expire_logs_seconds=86400;

mysql> set global binlog_expire_logs_seconds=2592000;
##手動(dòng)刪除
默認(rèn)日志文件達(dá)到 1G 都會(huì)重新生成一個(gè)新的二進(jìn)制日志文件

mysql> select @@max_binlog_size;
#binlog.000025 之前的日志都會(huì)被刪除
mysql> PURGE BINARY LOGS TO ‘binlog.000025’;

#時(shí)間’2020-04-28 23:59:59’之前的日志都會(huì)被刪除
mysql> PURGE BINARY LOGS BEFORE ‘2020-04-28 23:59:59’;

#清空歷史二進(jìn)制日志，從 000001 開始重新
mysql> RESET MASTER;
mysql> select @@binlog_format ;

?? 8.主鍵錯(cuò)誤導(dǎo)致主從復(fù)制報(bào)錯(cuò)

?? 8.1 報(bào)錯(cuò)現(xiàn)象

show slave status\G
Last_SQL_Errno: 1062

Last_SQL_Error: Error ‘Duplicate entry ‘1’ for key ‘PRIMARY’’ on query. Default database:‘test’. Query: ‘insert into test values(1,2,3,4,5,6)’

?? 8.2 處理過程

如果我們了解產(chǎn)生異常的具體事件，而且能夠掌控，
可以通過設(shè)置 sql_slave_skip_counter 參數(shù)來跳過當(dāng)前錯(cuò)誤。

setglobalsql_slave_skip_counter=1; --如果是10，就是跳過接下來的10個(gè)錯(cuò)誤
set global sql_slave_skip_counter=1;
start slave sql_thread;

或者使用 slave_skip_errors 參數(shù)（read only variable），指定跳過某種類型的錯(cuò)誤：
參數(shù)文件中設(shè)置：
slave_skip_errors=1062 #跳過 1062 錯(cuò)誤

遇到錯(cuò)誤時(shí)，不要一通百度后，然后根據(jù)看起來很類似的操作直接來進(jìn)行操作。
因?yàn)榫W(wǎng)上大部分解決 sql_thread 異常的方法是：

a、 直接 set global sql_slave_skip_counter=n;（n 設(shè)置很大的值，即：跳過所有錯(cuò)誤），
b、 設(shè)置 slave_skip_errors=all;跳過所有類型的錯(cuò)誤

c、 直接查看主庫(kù)的 binlog，然后在從庫(kù)上直接執(zhí)行 change master to。
這些方法都會(huì)導(dǎo)致主從數(shù)據(jù)不一致。

最后

IDEA2022.1版本最近發(fā)布了，想要早點(diǎn)嘗鮮的小伙伴，可以去下載了。

????點(diǎn)擊「原文閱讀」，可以獲取最新激活。