1、MySQL數據庫遠程連接很慢的解決方案

[mysqld]
skip-name-resolve

原因是由於mysql對連接的客戶端進行DNS反向解析。

注意

在增加該配置參數後，mysql的授權表中的host字段就不能夠使用域名而只能夠使用 ip地址了，因為這是禁止了域名解析的結果。

2、MySQL遠程連接不上

vim /etc/mysql/mysql.conf.d/mysqld.cnf

bind-address=127.0.0.1  139.196.197.138 0.0.0.1

msyql默認的bind-address是127.0.0.1

解決方法:bind-address後面增加遠程訪問IP地址或者禁掉。

3、MySQL數據庫亂碼

查看配置是否字符集統一，不統一根據自行調整即可。

mysql> show variables like 'character_set_%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set

例如：

/etc/mysql/mysql.conf.d/mysqld.cnf
character-set-server=utf8

4、1153 錯誤 導入數據報錯 (1153 – Got a packet bigger than ‘max_allowed_packet’ bytes)

MySQL默認讀取執行的SQL文件最大為16M

1 臨時解決方案：

set global max_allowed_packet = 210241024*10
show VARIABLES like 『%max_allowed_packet%』;

2 更改配置項（my.cnf）

 [mysqld]
 max_allowed_packet=400M 

5、1055 錯誤 (1055 – Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column ……)

完整提示如下：

1055 - Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 『information_schema.PROFILING.SEQ』 which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

only_full_group_by的語義就是確定select target list中的所有列的值都是明確語義，在此模式下，target list中的值要麼是來自於聚合函數（sum、avg、max等）的結果，要麼是來自於group by list`中的表達式的值。

可以修改sql_mode

-- 查看SQL_MODE
SELECT @@sql_mode;
-- 修改SQL_MODE
SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));

如果是只查詢某個字段出現可以使用any_value()函數來抑制ONLY_FULL_GROUP_BY值被拒絕.

6、Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage; increase this mysqld variable and try again

原因：
max_binlog_cache_size這個參數指定了全部可以使用的binlog的cache(包括內存和硬盤)，也就是單個事務最大允許的binlog大小，當超出這個值時，SQL會出現當前報錯。

處理方法：
1.拆分單個SQL的影響行數進行分批提交，控制單個SQL語句產生的binlog日誌大小
a）常規的有在SQL語句後加上limit，如每個SQL訂正影響行數limit 1000；
b） 一個數據變更可以提交多個SQL，即工單仍為一個審批也僅一次；但SQL需要拆分為多條。
2.如果是整個表的數據清理，可以考慮轉換為truncate table {your_table_name};

7、Incorrect prefix key; the used key part isn’t a string, the used length is longer than the key part, or the storage engine doesn’t support unique prefix keys

背景：

MySQL在索引變更時，支持對字符串字段進行前綴索引設置，設置的原因主要有兩點：

1：MySQL對索引內單個字段的存儲位元組數有長度767位元組的限制，具體可回復關鍵詞「767位元組」詳細了解
2：該索引字段在實際場景中通過一定長度的前綴數據即可進行有效索引，不需要完整字段創建索引可一定程度節省索引空間。
設置前綴索引報錯的原因：

MySQL只針對varchar字符類型的字段支持，對其他數值、時間等類型是不支持的要確保類型準確否則會遇到失敗。MySQL對varchar字符類型的字段定義長度不能超過字段本身的定義。例如字段定義「column_a varchar(128)」定義索引是「key idx_a(column_a(129))」那會遇到失敗。

處理方法：

a) 確保非varchar類型的字段沒有設置前綴索引長度。

b) 確保設置的長度沒有超過列定義的長度。

8、Data truncated for column

在做DDL變更時，遇到這個錯誤可以檢查一下目標字段的結構定義長度，當前表上該字段存儲的內容長度已大於將要修改的字段長度（一般出現在字段長度改小的場景）

處理方法：

確認表字段是否要改小長度，原則上對已經上線的表在【結構設計】內是不支持改小長度的。其他途徑改小的話需要先把表上超長的數據先 DELETE掉。

9、The MySQL server is running with the –read-only option

由於元數據無法切換到主庫實例進行變更或本來註冊在DMS的實例就是只讀備庫，所操作的數據庫為備庫或者開了只讀配置，無法執行DML及DDL操作。

10、Incorrect string value

查詢或變更所涉及的數據字符集存在不兼容（需要的字符集大於實際支持的字符集），在數據寫入和數據查詢時都有可能遇到。

處理方法：

1）檢查確保所寫SQL無隱藏字符（一般在從其他地方拷貝SQL執行時容易出現）

11、Data truncation: Truncated incorrect

原因1：

遇到此類報錯的原因是表上的字段定義和執行的SQL存在類型不符合，常見的場景為表上定義是字符串類型，SQL中用了數值類型的寫法

處理方法：

保持定義一致的書寫

原因2：

遇到此類報錯的原因表上該字段存在NULL值記錄無法直接被改為NOT NULL

處理方法：

訂正表上對應字段數據的NULL值為某個默認值 或者 刪掉對應字段值為NULL的記錄

12、Data truncation:Data too long

指定寫入該字段的值長度超過了表結構定義的對應字段長度；無法正確寫入導致了截斷的報錯

處理方法：

檢查表結構定義及DML需求，確認是調整表結構該字段的長度還是修改DML語句的字段內容使其長度滿足原有定義

13、ERROR 1799 (HY000): Creating index 『XXX』 required more than’innodb_online_alter_log_max_size’ bytes of modification log. Please try XXX.XXX

innodb_online_alter_log_max_size參數是MySQL5.6.6新加入的一個參數，用以指定對InnoDB表做在線DDL操作時所使用的臨時日誌文件的最大大小（以位元組為單位，默認128M）。在創建索引或者ALTER表時會使用該臨時文件。該文件記錄了DDL操作期間插入、更新、刪除的數據。在必要的時候該日誌文件的大小會根據innodb_sort_buffer_size的值增加容量直至達到innodb_online_alter_log_max_size指定的最大值。若臨時表的大小超出此上限則ALTER表的操作會失敗，當前所有未提交的DML操作會回滾。因此，一個較大的值允許在線DDL操作期間有更多的DML被執行，但是過大的值會使DDL操作結束後表被鎖定起來以應用日誌中的數據時花很長的時間。

也就是說，在任務執行過程中有過多的新增數據進來，導致臨時文件放不下了，臨時修改該參數的大小SET GLOBAL innodb_online_alter_log_max_size=1280000000;

14、Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs

雖然InnoDB內部支持行長大於65,535位元組，但是MySQL限制了所有列的組合長度；

1)將表上的一些varchar大字段改類型為TEXT或者BLOB類型

2)將表上的一些varcahr大字段根據業務實際需求縮小長度定義節省行長

15、Duplicate entry: XXXX

此類錯誤分為三種：

原因：

DML數據insert、update遇到，此時是表上存在的唯一約束/索引已有對應數據；

處理方法：

確認唯一約束/索引的合理性、原唯一鍵值數據是否合理，若均合理的話再確認當前需求是否需要調整。

原因：

DDL的加唯一約束/索引、調整唯一約束/索引（包含在唯一約束/索引內的組成字段的調整），此時要看錶上調整或新增的唯一約束/索引已存在重複數據；

處理方法：

確認唯一約束/索引的合理性，合理則需要先清理好重複數據再繼續重啟失敗的任務執行

原因：

DDL不涉及唯一約束/索引的調整（也不涉及唯一約束/索引的組成字段的調整），此時屬於mysql的onlineDDL機制在目標表存在高並發訪問情況下出現的BUG。

處理方法：

RDS實例 在業務低峰期下反覆重試或者非RDS實例 可以使用無鎖數據變更，也可以請聯繫 DBA 幫你處理。

PS：

唯一索引的衝突計算的是包含在索引定義內的長度，即假如字段定義為 “name varchar(255) “但是定義在該字段上的唯一索引定義了前綴為”uk(name(5))”，那麼表上存在記錄name=’abcdef………’ 再寫入name=’abcdef’就會因為前5個字符相同而失敗。

16、The MySQL server is running with the –log_bin_use_old_datetime_format option so it cannot execute this statement

當前數據庫實例版本限制了 log_bin_use_old_datetime_format=on；此時不能定義datetime類型增加默認值。

處理方法：

1）如果需要使用datetime類型則默認值需要取消改由程序代碼指定更新；

2）如果必須要數據庫指定默認值，可以嘗試改用timestamp字段類型；

3）如果必須用datetime類型並不希望代碼改造，需要聯繫業務DBA評估參數修改「 set global log_bin_use_old_datetime_format=off；」

17、Communications link failure The last packet sent successfully to the server was XXX milliseconds ago. The driver has not received any packets from the server.

原因1

如果was XXX milliseconds ago的XXX是0，那麼意味數據庫連不上了。可能的原因有兩個：1、數據庫發生了遷移，原數據源地址不可用 2、數據庫掛了。

處理方法：

1、確認數據源是否已存在，或者發生配置更新

2、檢查數據庫本身是否異常導致不可用直接聯繫DBA確認。

原因2：

如果was XXX milliseconds ago的XXX是大於0的一個值，那麼當前執行的SQL可能被數據庫KILL掉了。

處理方法：

直接聯繫你的DBA確認數據庫情況。如果數據庫是ob類型，並且XXX約等於30S，請告訴你的DBA集群信息，他會對數據庫進行擴容。

18、Specified key was too long; max key length is 767 bytes

mysql的「字符串類型」(varchar、char等)字段作為索引時，有一個約束單個索引字段存儲長度不能超過767位元組。

按照表為utf8mb4字符集時，一個字符需要4個位元組存儲。那麼最大定義索引前綴為 767/4=191.即字段a varchar(500)要建立索引時需要定義前綴索引 a(191)，不能超過191的一個值。

處理方法：

utf8為3個位元組存儲一個字符，gbk為2個位元組存儲一個字符，依次類推得到對應字符串類型字段的前綴索引長度修正即可。結構設計修改路徑：索引=》包含列=》前綴長度，進行設置。

如果是【庫表同步】請直接聯繫你的DBA修改為和【源】數據庫一致的編碼。

19、The consensus follower/leader is not allowed to to do current operation

當前實例不允許當前執行的操作。多數為主備角色錯誤導致不可讀、或不可寫。

處理方法：

此類錯誤一般情況下在10分鐘內會自動修復，請在10分鐘後重試執行任務即可。如果超時10分鐘仍然不成功，請提供工單id、對應數據庫的連接串文本信息，直接聯繫對應業務DBA同學確認是否有運維操作導致主備角色的改變。

20、Communications link failure during commit(). Transaction resolution unknown

均為實例宕機引起。

處理方法：

此類錯誤一般情況下在10分鐘內會自動修復，請在10分鐘後重試執行任務即可。如果超時10分鐘仍然不成功，直接聯繫對應業務DBA同學確認。

21、Too many connections

多出現在日常庫，業務同學調試或者代碼有缺陷導致鏈接被佔滿。

處理方法：

如果本地有調試，或者測試環境有代碼缺陷，可以嘗試把連上這個DB的服務重啟，這樣服務端就會釋放掉一些鏈接。服務重啟仍然不解決問題，直接聯繫對應業務DBA同學kill掉服務器上的鏈接或者重啟DB。

22、Duplicate column name ‘XXXXX’

報這個錯誤表示列已經存在了。

23、No operations allowed after connection closed

均為實例宕機引起。

處理方法：

此類錯誤一般情況下在10分鐘內會自動修復，請在10分鐘後重試執行任務即可。如果超時10分鐘仍然不成功，請提供工單id、對應數據庫的連接串文本信息，直接聯繫對應業務DBA同學確認是否有運維操作導致主備角色的改。