image

ZERO

背景

本文主要是介紹在MySQL使用運維過程中所遇到的一些坑爹的地方，予自己以做記錄！

前言

因操作系統重裝之后，安裝了mysql5.7，而由此帶來了一系列的問題，現將解決這些mysql坑的過程中一些解決辦法記錄下來，既是為自己后續查找問題提供方便，也是希望能夠給各位猿友減少一些踩坑的過程！

正記二

數據庫中的datetime數據顯示與實際時間相差14個小時，而通過java應用插入和查詢的同一條記錄，實際顯示的是正確的時間 => 因此，是mysql相關配置的問題

vim /etc/my.cnf

default-time-zone = '+8:00' #在 [mysqld] 之下

systemtcl restart mysqld #重啟mysql

正記一

ERROR-1

for error : max_allowed_packet

【ANSWER FOR ERROR-1】:

** (1)在mysql-cmd模式下，執行SQL命令“set global max_allowed_packet = 2*1024*102410;”；*

** (2)并且重啟mysql服務(windows下win+R -> services.msc找到MySQL重啟即可；linux下執行shell命令“service mysqld restart”)**

ERROR-2

for error: Incorrect string value: '\xF0\x9F...' for column 'XXX' at row

【ANSWER FOR ERROR-2】:

** (1)這是由于linux下mysql執行create table建表命令時默認采用的時latin1字符集建表的，導致一些中文字符的寫入而出現的異常信息；但是在windows下，mysql默認所建的表字符是utf8的，這也是為何相同的SQL語句由windows->linux下mysql中運行拋出該異常的原因**

** (2)解決該問題的是需要養成一個習慣，也即無論是什么時候什么環境下執行create table創建mysql數據庫表時，務必指定特定的字符集和引擎，如SQL命令(含ENGINE=InnoDB DEFAULT CHARSET=utf8)**

DROP TABLE IF EXISTS `db_test`;

CREATE TABLE `db_test` (

`db_test_id` VARCHAR(100) NOT NULL COMMENT '測試Id',

`db_test_text` VARCHAR(255) NOT NULL COMMENT '測試文本',

`status` VARCHAR(2) DEFAULT '1' COMMENT '狀態，1啟用(默認)，-1禁用',

`update_time` datetime DEFAULT NULL COMMENT '更新時間',

`create_time` datetime NOT NULL COMMENT '創建時間',

PRIMARY KEY (`db_test_id`)

)ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='測試表';

ERROR-3

詭異描述(其實是自我錯覺)之“在Springboot+Mybatis+MySQL系統架構下，某個接口的一條查詢語句預期正常情況下是可以成功查詢到1條返回結果的，但是只要在sql-where條件中對某個字段INDUSTRIENAME進行篩選時查詢過來的結果總是0條數據，并且在navicat下手動執行該一模一樣SQL語句及where條件是有1條結果的”

=》 經過一整天的折騰：從懷疑SQL的正確性，將SQL不斷拆分 -> 去除各種where條件查詢均可以有結果且只要加上該字段的篩選就是0條 -> 懷疑mybatis的配置有問題 -> 結果返回java對象的映射有問題->連接的數據庫地址不正確->poatman傳過來的數據不是預期的那個條件值->應用控制臺將SQL語句以及條件值打印出來->重啟IDE、重啟mysql、重啟電腦->……歷經了一整天的崩潰過程，一度懷疑人生一度懷疑自己的程序猿生涯之路將就此終結，萬萬沒有想到的是自己并沒有錯，錯的居然是因為查詢的條件傳過來的值是中文，，，注意是中文、中文、中文，重要的事情強調三遍 -> 于是在建立數據源連接的地方，指定字符集utf8方解決這折騰了自己一整整天的“詭異”問題，歸根結底還是自己定位查問題的方式需要優化，如果能夠直接去查看mysql的log將問題很快就會被發現和解決！！

【ANSWER FOR ERROR-3】:

** (0)留個心眼----尤其是MySQL數據庫版本更新以及自主安裝的MySQL中，特別注意當前出現的問題或者異常中有沒有環節中是有中文、中文、中文的！！！！**

** (1)養成良好的msyql數據源配置習慣，如：**

jdbc:mysql://127.0.0.1:3306/test?characterEncoding=UTF-8

另外，需要注意的是數據源連接配置的幾個選項“&autoReconnect=true&useSSL=true&useUnicode=true”等的含義及引發的問題；同時，若是中文在數據庫中顯示是“？”或者更新中文文字到數據庫中出現異常，則是數據庫的默認字符集問題，可通過SQL命令“show VARIABLES LIKE '%character%'”查看當前character-set-server的值

** (2)不僅僅要開啟的是應用的SQL-log日志，更需要去開啟mysql自身log以實時查看或者落日志文件，保證能夠查看到最終mysql中是實際執行的SQL語句，如果這個LOG開啟了，只要一查看該log就能夠知道該問題是由于java-mysql連接數據源的時候未指定字符集而導致的針對中文字符串為值得查詢條件時，實際執行的查詢語句并非是預期的那個中文字符串而是亂碼(未設置utf8導致的mysql實際接收到是亂碼)**

**#Issue 1:

InnoDB: The innodb_system data file 'ibdata1' must be writable**

按照菜鳥教程上的MySQL教程，在CentOS7上利用RPM包安裝好MySQL后第一次啟動服務：

systemctl start mysqld.service

結果啟動失敗，查看mysql服務的啟動日志：

日志位置：var/log/mysqld.log

2018-07-10T03:28:38.289394Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.11) starting as process 10959

2018-07-10T03:28:38.502207Z 1 [ERROR] [MY-012271] [InnoDB] InnoDB: The innodb_system data file 'ibdata1' must be writable

2018-07-10T03:28:38.502279Z 1 [ERROR] [MY-012278] [InnoDB] InnoDB: The innodb_system data file 'ibdata1' must be writable

2018-07-10T03:28:38.502331Z 1 [ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine

2018-07-10T03:28:38.502619Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.

2018-07-10T03:28:38.502667Z 0 [ERROR] [MY-010119] [Server] Aborting

2018-07-10T03:28:38.521513Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.11) MySQL Community Server - GPL.

注意到第一個Error：[InnoDB] InnoDB: The innodb_system data file 'ibdata1' must be writable，可能是權限不夠的原因，于是修改'ibdata1'所在文件夾的權限：

MySQL data默認路徑：/var/lib/mysql

chmod -R 777 /var/lib/mysql

再次啟動服務，終于啟動成功。

總結

以上是生活随笔為你收集整理的mysql运维工资_MySQL运维踩坑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。