項目的mysql數據庫版本由5.1.x更換爲5.7.x後出現了一些問題，現將其中的一些問題記錄一下
其中大部分問題都需要修改數據庫的配置文件進行解決，所以先將如何找到mysql配置文件記錄下來，如下
1. 執行 which mysql 命令，通過此命令找到mysql的安裝位置
比如：/usr/bin/mysql
2. 執行 /usr/bin/mysql --verbose --help | grep -A 1 'Default options' 命令
（其中“/usr/bin/mysql”爲上一步中找到的路徑），結果類似如下信息：
Default options are read from the following files in the given order:
/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf
** 這個信息的意思是： 服務器首先讀取的是/etc/mysql/my.cnf文件，如果前一個文件不存在
則繼續讀/etc/my.cnf文件，如若還不存在便會去讀~/.my.cnf文件
3. 根據上邊的提示，找到對應的配置文件，執行 vim /***/my.cnf 即可進入修改
問題1：項目啓動後，一些sql語句報如下錯誤：
### Error querying database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException:
Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column
'xxx.db.xxxxx' which is not functionally dependent on columns in GROUP BY
clause; this is incompatible with sql_mode=only_full_group_by
錯誤原因爲：
MySQL 5.7.5及以上功能依賴檢測功能。如果啓用了ONLY_FULL_GROUP_BY SQL模式（默認情況下），MySQL將拒絕選擇列表，HAVING條件或ORDER BY列表的查詢引用在GROUP BY子句中既未命名的非集合列，也不在功能上依賴於它們。
解決辦法：
① 執行查詢 （可在mysql命令行中執行或者通過navcat等工具執行）
select @@global.sql_mode
結果如下：
ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
② 修改mysql配置文件，在配置文件中增加如下配置：
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
③ 修改後保存退出，然後重啓mysql服務即可
service mysql restart
問題二：格式化後的時間比當前時間晚8個小時
問題描述：
代碼中用了System.currentTimeMillis()這種方法，前端格式化時間後，顯示的時間比當前時間晚8個小時
錯誤原因：
數據庫版本不同，默認使用的時區不同導致的
解決辦法：
① 執行查詢，查看當前數據庫使用的時區：
SHOW VARIABLES LIKE ‘%time_zone%’;
類似結果如下：
② 執行設置，將mysql全局時區修改爲北京時間，即我們所在的東8區：
set global time_zone = ‘+8:00’; ##設置
flush privileges; ##使設置生效
注意 此方法修改只是臨時起作用，數據庫服務重啓後會失效
可通過修改數據庫配置使設置永久生效，修改數據庫配置文件，在配置文件中添加如下內容即可：
default-time_zone = ‘+8:00’
修改後重啓數據庫服務，時間問題解決
問題三：啓動服務時報由於許多連接錯誤而被阻止
問題描述：
啓動後臺服務，日誌中報如下錯誤：
ERROR c.a.d.p.DruidDataSource - [run,2471] - create connection SQLException,
url: jdbc:mysql://192.168.x.xxx:3306/xxx-db?useUnicode=true&characterEncoding=utf8
&zeroDateTimeBehavior=convertToNull&useSSL=false, errorCode 1129, state HY000
java.sql.SQLException: null,
message from server: "Host '192.168.x.xxx' is blocked because of many connection errors;
unblock with 'mysqladmin flush-hosts'"
錯誤原因：
同一個ip在短時間內產生太多（超過mysql數據庫max_connect_errors的最大值）中斷的數據庫連接而導致的阻塞
解決辦法：
① 最直接快速的辦法是，執行以下命令將max_connect_errors的計數器值清零：
flush hosts ##執行此命令後即可解決以上問題
② 可查看當前數據庫max_connect_errors的值，一般默認值是10，如果過小，可以將其設置大：
show variables like ‘max_connect_errors’; ##查詢max_connect_errors值
set global max_connect_errors = 100; ##設置 max_connect_errors值（100可以是任意整數，默認值爲10）
問題四：啓動服務時報某數據庫表找不到（區分了表名的大小寫）
問題描述：
啓動後臺服務，日誌中報如下錯誤：
ERROR o.s.s.q.LocalDataSourceJobStore - [manage,3926] - ClusterManager:
Error managing cluster: Failure obtaining db row lock: Table 'xxx-db.AAA_TAB'
doesn't exist
org.quartz.impl.jdbcjobstore.LockException: Failure obtaining db row lock:
Table 'xxx-db.AAA_TAB' doesn't exist
其中xxx-db.AAA_TAB是你對應數據庫中的某個表，不過這個表名實際爲小寫（xxx-db.aaa_tab）
錯誤原因：
數據庫在磁盤中存儲的表名爲小寫，比較的時候區分了大小寫
解決辦法：
① 先查看當前的讀取策略：
SHOW VARIABLES LIKE ‘%case%’; ##執行此查詢，根據結果進行查看
lower_case_table_names = 1 表名存儲在磁盤是小寫的，但是比較的時候不區分大小寫
lower_case_table_names = 0 表名存儲在磁盤可以是大小寫，但是比較的時候區分大小寫
lower_case_table_names = 2 表名存儲在磁盤可以是大小寫，但是比較的時候是小寫的
② 修改數據庫配置文件，在配置文件中添加 lower_case_table_names=1的配置即可：
lower_case_table_names=1
其他問題待發現後更新…