轉載自：yuque.com/dmsqiyebanvipfuwu/gmknz6/mr7br8#fe63399c
https://yuque.antfin-inc.com/canpqc/ob19qq/ansmeo#tyf8du
一、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：如果是【數據變更】工單，請使用【數據變更-大表DML】功能進行變更。
2：拆分單個SQL的影響行數進行分批提交，控制單個SQL語句產生的binlog日志大小
a）常規的有在SQL語句后加上limit，如每個SQL訂正影響行數limit 1000；
b） 一個數據變更可以提交多個SQL，即工單仍為一個審批也僅一次；但SQL需要拆分為多條。
3：如果是整個表的數據清理，可以考慮轉換為truncate table {your_table_name};
二、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) 確保設置的長度沒有超過列定義的長度。
三、Data truncated for column
原因：在做DDL變更時，遇到這個錯誤可以檢查一下目標字段的結構定義長度，當前表上該字段存儲的內容長度已大於將要修改的字段長度（一般出現在字段長度改小的場景）
處理方法：確認表字段是否要改小長度，原則上對已經上線的表在【結構設計】內是不支持改小長度的。其他途徑改小的話需要先把表上超長的數據先 DELETE掉。
四、The MySQL server is running with the --read-only option
原因：由於元數據無法切換到主庫實例進行變更或本來注冊在DMS的實例就是只讀備庫，所操作的數據庫為備庫或者開了只讀配置，無法執行DML及DDL操作。
此類錯誤一般情況下在10分鍾內會自動修復，請在10分鍾后重試執行任務即可。如果超時10分鍾仍然不成功，請提供工單id、對應數據庫的連接串文本信息，直接聯系對應業務DBA同學確認是否有運維操作導致主備角色的改變。
五、Incorrect string value
原因：查詢或變更所涉及的數據字符集存在不兼容（需要的字符集大於實際支持的字符集），在數據寫入和數據查詢時都有可能遇到。
處理方法：
1）檢查確保所寫SQL無隱藏字符（一般在從其他地方拷貝SQL執行時容易出現）可以先 SQL格式化
2）若在SQLConsole進行查詢 ，單物理庫下的操作，可以嘗試右上角“顯示設置”=》切換目標字符集進行嘗試【問題一定可以解決】
六、Data truncation: Truncated incorrect
原因：【數據變更】遇到此類報錯的原因是表上的字段定義和執行的SQL存在類型不符合，常見的場景為表上定義是字符串類型，SQL中用了數值類型的寫法
處理方法：保持定義一致的書寫
原因：【結構變更】遇到此類報錯的原因表上該字段存在NULL值記錄無法直接被改為NOT NULL
處理方法：訂正表上對應字段數據的NULL值為某個默認值 或者 刪掉對應字段值為NULL的記錄
七、Data truncation:Data too long
原因：【數據變更】、【SQLConsole】執行DML語句遇到此類報錯的原因是，指定寫入該字段的值長度超過了表結構定義的對應字段長度；無法正確寫入導致了截斷的報錯
處理方法：檢查表結構定義及DML需求，確認是調整表結構該字段的長度還是修改DML語句的字段內容使其長度滿足原有定義
八、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;
九、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大字段根據業務實際需求縮小長度定義節省行長
十、Duplicate entry: XXXX
此類錯誤分為三種：
原因：【數據變更】的DML數據insert、update遇到，此時是表上存在的唯一約束/索引已有對應數據；
處理方法：確認唯一約束/索引的合理性、原唯一鍵值數據是否合理，若均合理的話再確認當前需求是否需要調整。
原因：【結構設計】的DDL的加唯一約束/索引、調整唯一約束/索引（包含在唯一約束/索引內的組成字段的調整），此時要看表上調整或新增的唯一約束/索引已存在重復數據；
處理方法：確認唯一約束/索引的合理性，合理則需要先清理好重復數據再繼續重啟失敗的任務執行
原因：【結構設計】的DDL不涉及唯一約束/索引的調整（也不涉及唯一約束/索引的組成字段的調整），此時屬於mysql的onlineDDL機制在目標表存在高並發訪問情況下出現的BUG。
處理方法1：RDS實例 在業務低峰期下反復重試，或聯系DBA處理。
處理方法2：非RDS實例 可以使用無鎖數據變更，請聯系 DBA 幫你處理。
PS：
唯一索引的沖突計算的是包含在索引定義內的長度，即假如字段定義為 "name varchar(255) "但是定義在該字段上的唯一索引定義了前綴為"uk(name(5))"，那么表上存在記錄name='abcdef.........' 再寫入name='abcdef'就會因為前5個字符相同而失敗。
十一、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；”
十二、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、確認DBA是否做了遷移操作，新的數據源在DMS上是否已存在？
1.1 如果發生了遷移並且新的配置已存在，那么提供出錯的數據源地址給值班人員並告知新配置；
DMS值班人員可將原地址遷移至新地址，將數據源權限等依賴數據遷移，避免開發人員重新申請權限
1.2 如果發生了遷移但新的配置在DMS上未存在，那么提供出錯的數據源地址給值班人員並告知新配置；
DMS值班人員與DBA確認，或從天際中查看最新主備將配置修改為新的再通知開發人員刷新重試
2、DBA未做遷移操作，檢查數據庫本身是否異常導致不可用直接聯系DBA確認
原因2：如果was XXX milliseconds ago的XXX是大於0的一個值，那么當前執行的SQL可能被數據庫KILL掉了。
處理方法2：如果數據庫是ob類型，並且XXX約等於30S，請告訴你的DBA集群信息，他會對數據庫進行擴容。
十三、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修改為和【源】數據庫一致的編碼。
十四、The consensus follower/leader is not allowed to to do current operation
原因：當前實例不允許當前執行的操作。多數為主備角色錯誤導致不可讀、或不可寫。
處理方法： 此類錯誤一般情況下在10分鍾內會自動修復，請在10分鍾后重試執行任務即可。如果超時10分鍾仍然不成功，請提供工單id、對應數據庫的連接串文本信息，直接聯系對應業務DBA同學確認是否有運維操作導致主備角色的改變。
十五、Communications link failure during commit(). Transaction resolution unknown
原因： 均為實例宕機引起。
處理方法： 此類錯誤一般情況下在10分鍾內會自動修復，請在10分鍾后重試執行任務即可。如果超時10分鍾仍然不成功，請提供工單id、對應數據庫的連接串文本信息，直接聯系對應業務DBA同學確認是否有運維操作導致主備角色的改變
十六、Too many connections
原因： 多出現在日常庫，業務同學調試或者代碼有缺陷導致鏈接被占滿。
處理方法： 如果本地有調試，或者測試環境有代碼缺陷，可以嘗試把連上這個DB的服務重啟，這樣服務端就會釋放掉一些鏈接。服務重啟仍然不解決問題，直接聯系對應業務DBA同學kill掉服務器上的鏈接或者重啟DB
十七、Duplicate column name 'XXXXX'
原因：報這個錯誤表示列已經存在了。
處理方法1：如果您在執行DDL的時候，預期就是添加這個列，那么就意味這個列已經存在了，原因可能是已經執行過了這個SQL，也可能是表上本身就存在這個SQL。處理方法是：在“執行詳情”中找到這條報錯的SQL，點擊“跳過”然后重試任務即可跳過執行當前SQL。
實例：insert into unit_employee_authority(id, unit_id, user_level, authority_amount, status, version_number, created_by, last_updated_by)
select 1001, id, 'M2', 20000 , 1, 1, 1, 1 from sys_department where department_code = '51591' ;
錯誤原因：Duplicate column name '1'
解決辦法：加別名
insert into unit_employee_authority(id, unit_id, user_level, authority_amount, status, version_number, created_by, last_updated_by)
select 1001, id, 'M2', 20000 , 1 a, 1 b, 1 c, 1 d from sys_department where department_code = '51591' ;
十八、No operations allowed after connection closed
原因： 均為實例宕機引起。
處理方法： 此類錯誤一般情況下在10分鍾內會自動修復，請在10分鍾后重試執行任務即可。如果超時10分鍾仍然不成功，請提供工單id、對應數據庫的連接串文本信息，直接聯系對應業務DBA同學確認是否有運維操作導致主備角色的改變。