今天給大家列舉 MySQL 數據庫中，最經典的八大錯誤案例，并附有處理問題的解決思路和方法，希望能給剛入行，或數據庫愛好者一些幫助。
忘記密碼，無法登陸
報錯現象
ERROR 1130 (HY000): Host ‘172.18.1.1’ is not allowed to connect to this MySQL server --提示無法登陸
處理過程
在MySQL中，若密碼丟失則無法直接找回，只能通過特殊方式來修改密碼。
在配置文件中添加如下一行，重啟 MySQL 登錄則不需要密碼。
skip-grant-tables
cat /etc/my.cnf
重啟 MySQL
systemctl start mysqld
[root@binlog2sql ~]# mysql -uroot -p
–此時空密碼可以進入
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新的密碼登錄了！
修改簡易密碼報錯
報錯現象
alter user root@‘localhost’ identified with mysql_native_password by ‘root’;
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
處理過程
查詢密碼策略
mysql> SHOW VARIABLES LIKE ‘validate_password%’;
去除密碼驗證策略
–默認關閉，設置為ON時可以將密碼設置成當前用戶名
mysql> set global validate_password.check_user_name=OFF;
–密碼強度檢查等級，0/LOW、1/MEDIUM、2/STRONG。默認是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;
–密碼驗證策略
0/LOW：只檢查長度。
1/MEDIUM：檢查長度、數字、大小寫、特殊字符
2/STRONG：檢查長度、數字、大小寫、特殊字符字典文件。
此時修改為密碼root則OK，因為已經去除密碼策略
大小寫的敏感報錯
報錯現象
最近接了一個項目跟團隊在開發，在自己本機windows上開發和測試過程中一直沒有問題，
臨近項目交付的時候，部署到linux服務器上后，發現有報錯，日志信息大概是：
MySQLSyntaxErrorException: Table ‘mes_db.student’ doesn’t exist
處理過程
在本機Window環境查看如下：
mysql> show variables like ‘%case%’;
在Linux服務器查看如下：
出現了問題，有點郁悶，本地開發好好的，怎么部署服務器就不行了。
有鬼…不過莫慌。看著錯誤提示很明顯，不就是student表不存在嗎！
①于是我不慌不忙打開navicat，查看這個表在不在，一看還真在，
數據庫中顯示的student，不過s是小寫；
②查看代碼發現代碼中還真把表名寫成Student,就一個s寫成大寫S了。
問題找到了，原來是不小心寫SQL的時候沒有寫對表名，改一下表名就搞定了，功能也一切正常了
從上面的結果已經可以看出不同了
當 lower_case_table_names 為 0 時表示區分大小寫，為 1 時表示不區分大小寫
在Windows上，默認值為1；在macOS上，默認值為2；在Linux上不支持值2;服務器強制該值為0
0 --大小寫敏感。（Unix，Linux默認）
1–大小寫不敏感。（Windows默認）
2 --大小寫不敏感（macOS默認）
并且官網也提示說：如果在數據目錄駐留在不區分大小寫的文件系統
（例如Windows或macOS）上的系統上運行MySQL，
則不應將lower_case_table_names設置為0。
我自己在我的window10環境嘗試設置lower_case_table_names為0的時候，
MySQL的服務怎么也啟動不能，啟動服務報錯，因為windows系統對大小寫不敏感
而Linux則是區分大小寫的，因此，建議在開發測試環境下就嚴格控制代碼大小寫敏感，
提高代碼的兼容和嚴謹
導出與導入報錯
報錯現象
在進行數據導出的時候出現:
secure-file-priv option so it cannot execute this statement
處理過程
直需要修改參數文件即可
echo “secure-file-priv=” >> /etc/my.cnf
secure-file-priv
參數是用來限制 LOAD DATA, SELECT … OUTFILE, and LOAD_FILE()傳到哪個指定目錄的。
a.seure_file_priv 的值為 null ，表示限制 mysqld 不允許導入|導出
b.當 secure_file_priv 的值為/tmp/ ，表示限制 mysqld 的導入|導出只能發生在/tmp/目錄下
c.當 secure_file_priv 的值沒有具體值時，表示不對 mysqld 的導入|導出做限制
修改參數只能在服務器參數文件中修改，修改后重新服務器：
secure-file-priv=
導出命令
select host,user from mysql.user into outfile ‘/tmp/user.csv’
Fields terminated by ‘,’ enclosed by ‘"’;
逗號分割,雙引號閉合
注意：導出的文件只能在服務器上
連接數過多，無法連接MySQL
報錯現象
處理過程
解決問題的思路：
1、首先先要考慮在我們 MySQL 數據庫參數文件里面，對應的 max_connections 這個參數值是不是設置的太小了，導致客戶端連接數超過了數據庫所承受的最大值。
● 該值默認大小是151，我們可以根據實際情況進行調整。
● 對應解決辦法：set global max_connections=500
但這樣調整會有隱患，因為我們無法確認數據庫是否可以承擔這么大的連接壓力，就好比原來一個人只能吃一個饅頭，但現在卻非要讓他吃 10 個，他肯定接受不了。反應到服務器上面，就有可能會出現宕機的可能。
所以這又反應出了，我們在新上線一個業務系統的時候，要做好壓力測試。保證后期對數據庫進行優化調整。
2、其次可以限制Innodb 的并發處理數量 ，如果 innodb_thread_concurrency = 0（這種代表不受限制） 可以先改成 16或是64 看服務器壓力。如果非常大，可以先改的小一點讓服務器的壓力下來之后,然后再慢慢增大,根據自己的業務而定。個人建議可以先調整為 16 即可。
磁盤爆滿，無法寫二進制日志
報錯現象
Binlog是MySQL中一個很重要的日志，記錄了對數據庫進行變更的操作，
但是不包括 select操作以及 show 操作，因為這類操作對數據庫本身沒有沒有修改。
如果想記錄 select和 show 的話，那就需要開啟全查詢日志。
另外 binlog 還包括了執行數據庫更改操作時間和執行時間等信息。
binlog 是 MySQL Server 層記錄的二進制日志文件，邏輯層面
清理二進制日志
mysql> show variables like ‘%binlog_expire_logs_seconds%’ ;
mysql 8開始 expire_logs_days廢棄
啟用binlog_expire_logs_seconds設置binlog自動清除日志時間
保存時間 以秒為單位；默認2592000 30天
14400 4小時；86400 1天；259200 3天
##自動刪除
mysql> set global binlog_expire_logs_seconds=86400;
mysql> set global binlog_expire_logs_seconds=2592000;
##手動刪除
默認日志文件達到 1G 都會重新生成一個新的二進制日志文件
mysql> select @@max_binlog_size;
#binlog.000025 之前的日志都會被刪除
mysql> PURGE BINARY LOGS TO ‘binlog.000025’;
#時間’2020-04-28 23:59:59’之前的日志都會被刪除
mysql> PURGE BINARY LOGS BEFORE ‘2020-04-28 23:59:59’;
#清空歷史二進制日志，從 000001 開始重新
mysql> RESET MASTER;
mysql> select @@binlog_format ;
主鍵錯誤導致主從復制報錯
報錯現象
show slave statusG
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)’
處理過程
如果我們了解產生異常的具體事件，而且能夠掌控，
可以通過設置 sql_slave_skip_counter 參數來跳過當前錯誤。
setglobalsql_slave_skip_counter=1; --如果是10，就是跳過接下來的10個錯誤
set global sql_slave_skip_counter=1;
start slave sql_thread;
或者使用 slave_skip_errors 參數（read only variable），指定跳過某種類型的錯誤：
參數文件中設置：
slave_skip_errors=1062 #跳過 1062 錯誤
遇到錯誤時，不要一通百度后，然后根據看起來很類似的操作直接來進行操作。
因為網上大部分解決 sql_thread 異常的方法是：
a、 直接 set global sql_slave_skip_counter=n;（n 設置很大的值，即：跳過所有錯誤），
b、 設置 slave_skip_errors=all;跳過所有類型的錯誤
c、 直接查看主庫的 binlog，然后在從庫上直接執行 change master to。
這些方法都會導致主從數據不一致。
