連接mysql數據庫連接報錯（數據庫連接錯誤）

本文目錄一覽：

• 1、使用jdbc連接mysql為什麼報錯？
• 2、mysql5.7.12報錯如下情況導致無法連接數據庫應該怎麼辦？
• 3、連接mysql數據庫失敗怎麼辦
• 4、連接內網服務器上的mysql報錯
• 5、mysql連接數據庫失敗，請確定數據庫用戶名，密碼設置正確

使用jdbc連接mysql為什麼報錯？

當我用JDBC連接MySql數據庫時，編譯報了如下錯誤：

錯誤1：

Loading class `com.mysql.jdbc.Driver’. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver’. The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary.

這要求我們註冊驅動時，把Class.forName(“com.mysql.jdbc.Driver”);改成 Class.forName(“com.mysql.cj.jdbc.Driver”);

當我信息滿滿的修改之後重新編譯時，再次出現了錯誤：

錯誤2：

Fri Feb 22 08:55:38 CST 2019 WARN: Establishing SSL connection without server’s identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be established by default if explicit option isn’t set. For compliance with existing applications not using SSL the verifyServerCertificate property is set to ‘false’. You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for server certificate verification.

這要求我們在設置url參數時，將useSSL=false，修改後 jdbc:mysql://localhost:3306/ds3?useSSL=false

當我修改後，本以為這下應該沒問題了，沒想到，再一次出現了問題

錯誤3：

Exception in thread “main” java.sql.SQLException: The server time zone value ‘Öйú±ê׼ʱ¼ä’ is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.

這要求我們修改時區，修改成jdbc:mysql://localhost:3306/ds3?useSSL=falseserverTimezone=UTC

終於，不在報錯誤了。

錯誤4：當我們配置xml文件時，要把轉為其本身的轉義字符

配置properties文件的urlurl=jdbc:mysql:///ds3?useSSL=falseserverTimezone=UTC配置xml文件的urlproperty name=”url”jdbc:mysql://localhost:3306/ds3?useSSL=falseserverTimezone=UTC/property

mysql5.7.12報錯如下情況導致無法連接數據庫應該怎麼辦？

一、mysqld 進程沒有正常運行遇到這種情況首先到服務器上看看 mysqld 進程是否活着，採用的命令：

二、客戶端不能和進程 mysqld 通信如果 MySQL 服務器上的 mysqld 進程運行正常，我們再看看客戶端能不能和 mysqld 進行通信，使用下面的命令進行網絡連通的測試：telnet localhost 3306

如果本地能通，再到客戶端的機器上把 localhost 換成 MySQL 服務器的 ip 地址進行測試。如果不能通，通常有兩種原因，一種原因是 OS 或網絡的問題，或者是防火牆；另一種原因是 mysqld 自身根本沒有偵聽客戶端的連接請求， mysqld 啟動後對於客戶端的偵聽是分三種情況。

第一種情況

是使用參數 –skip-networking 跳過偵聽客戶端的網絡連接，用下面的命令我們可以看到 MySQL 根本沒有偵聽 3306 端口。

第二種情況

使用參數 –bind-address 後面增加對客戶端訪問 IP 地址的限制，例如只偵聽本地的連接

三、賬戶密碼的問題最後一種情況是賬戶密碼的問題，應付這種情況我們有個有力的工具就是查看 MySQL 的 error log， error log 記載信息的詳細程度上由參數 –log-error-verbosity 進行控制的

連接mysql數據庫失敗怎麼辦

1 mysql 錯誤 ERROR 2003 (HY000): Can’t connect to MySQL server on ‘localhost’

解決辦法：關閉防火牆，linux下命令

[root@etl01 bin]# chkconfig –list | grep -i iptables ====check fire wall

iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off

[root@etl01 bin]# /sbin/service iptables stop ====stop fire wall

Flushing firewall rules: [ OK ]

Setting chains to policy ACCEPT: nat filter [ OK ]

Unloading iptables modules: [ OK ]

2 報錯:1130-host … is not allowed to connect to this MySql server

解決辦法：

授權形式

比如賬戶為root,密碼為root

use mysql;

用root賬戶從任何主機上訪問mysql數據庫了

GRANT ALL PRIVILEGES ON *.* TO ‘root’@’%’ IDENTIFIED BY ‘root’ WITH GRANT OPTION;

如果你想允許用戶zz從ip為192.168.1.3的主機連接到mysql服務器，並使用123456作為密碼

GRANT ALL PRIVILEGES ON *.* TO ‘root’@’192.168.1.3’ IDENTIFIED BY ‘123456’ WITH GRANT OPTION;

連接內網服務器上的mysql報錯

錯誤原因是：本地IP（xxx.xxx.xxx.xxx）沒有訪問遠程數據庫的權限。

於是下面開啟本地IP（xxx.xxx.xxx.xxx）對遠程mysql數據庫的訪問權限。

首先遠程連接進入服務器，在cms中輸入mysql -u root -p，然後回車，輸入密碼後回車進入mysql命令行。

輸入use mysql;

輸入select user,password,host from user;

可以看到host中只有localhost主機。我們需要將xxx.xxx.xxx.xxx也添加到這裡才對。

添加方法如下：

輸入

grant all privileges on *.* to root@”xxx.xxx.xxx.xxx” identified by “密碼”;

這相當於是給IP-xxx.xxx.xxx.xxx賦予了所有的權限，包括遠程訪問權限。

然後再輸入

flush privileges;

這相當於是重新加載一下mysql權限，這一步必須有。

再次輸入select user,password,host from user;

可以看到host中已經有了新加的IP。

現在再次用Navicat for MySQl訪問遠程mysql數據庫，已經能正常打開了。

問題解決。

不過還有一個問題，發現雙擊打開某張表的時候很慢，至少要3秒。

原因是：

當遠程訪問mysql時, mysql會解析域名, 所以會導致訪問速度很慢, 會有2,3秒延時！

解決辦法：

修改mysql安裝目錄下的my.ini，加上下面這個配置可解決此問題。在[mysqld]下加入：skip-name-resolve

保存退出後重啟mysql服務。

然後訪問速度就和本地一樣快啦。

mysql連接數據庫失敗，請確定數據庫用戶名，密碼設置正確

現象

一線的工程師反映了一個奇怪的現象，剛剛從 MySQL 官網上下載了一個 MySQL 5.7.31。安裝完成後，發現使用任何密碼都能登陸 MySQL，修改密碼也不管用，重新啟動 MySQL 也不能解決。

分析

懷疑使用了 –skip-grant-tables 使用 mysqld –print-defaults 檢查，沒有發現。

檢查登陸用戶，都是 root@localhost，說明和 proxy user 沒有關係。

使用 mysql –print-defaults 檢查客戶端是否設置默認的用戶和密碼，沒有發現。

檢查數據庫中的用戶和密碼的相關字段：

發現一切都正常，再檢查 plugin 字段，發現只有 root 用戶是 auth_socket ，其它的用戶都是 mysql_native_password，問題可能就出在這兒。

對 auth_socket 驗證插件不了解，感覺是這個插件不安全，使用下面的命令修改後，問題解決：

update user set plugin=”mysql_native_password” where user=’root’;

auth_socket 驗證插件的使用場景

問題解決後，又仔細研究了一下 auth_socket 這個插件，發現這種驗證方式有以下特點：

首先，這種驗證方式不要求輸入密碼，即使輸入了密碼也不驗證。這個特點讓很多人覺得很不安全，實際仔細研究一下這種方式，發現還是相當安全的，因為它有另外兩個限制；

只能用 UNIX 的 socket 方式登陸，這就保證了只能本地登陸，用戶在使用這種登陸方式時已經通過了操作系統的安全驗證；

操作系統的用戶和 MySQL 數據庫的用戶名必須一致，例如你要登陸MySQL 的 root 用戶，必須用操作系統的 root用戶登陸。

auth_socket 這個插件因為有這些特點，它很適合我們在系統投產前進行安裝調試的時候使用，而且也有相當的安全性，因為系統投產前通常經常同時使用操作系統的 root 用戶和 MySQL 的 root 用戶。當我們在系統投產後，操作系統的 root 用戶和 MySQL 的 root 用戶就不能隨便使用了，這時可以換成其它的驗證方式，可以使用下面的命令進行切換：

ALTER USER ‘root’@’localhost’ IDENTIFIED WITH mysql_native_password BY ‘test’;