**背景** 客戶使用mysqldump導出一張表，然后使用mysql -e 'source test.dmp'的過程中client進程crash，爆出內存的segment fault錯誤，導致無法導入數據。 **問題定位** test.dmp文件大概50G左右，查看了一下文件的前幾行內容，發現： ~~~ A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database If you don't want to restore GTIDs pass set-gtid-purged=OFF. To make a complete dump, pass... -- MySQL dump 10.13 Distrib 5.6.16, for Linux (x86_64) -- -- Host: 127.0.0.1 Database: carpath -- ------------------------------------------------------ -- Server version 5.6.16-log /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; ~~~ 問題定位到第一行出現了不正常warning的信息，是由于客戶使用mysqldump命令的時候，重定向了stderr。即: mysqldump ...>/test.dmp 2>&1 導致error或者warning信息都重定向到了test.dmp, 最終導致失敗。 **問題引申** 問題雖然定位到了，但卻有幾個問題沒有弄清楚： 問題1\. 不正常的sql，執行失敗，報錯出來就可以了，為什么會導致crash？ mysql.cc::add_line函數中，在讀第一行的時候，讀取到了don't,發現有一個單引號，所以程序死命的去找匹配的另外一個單引號，導致不斷的讀取文件，分配內存，直到crash。 假設沒有這個單引號，mysql讀到第六行，發現;號，就會執行sql，并正常的報錯退出。 問題2\. 那代碼中對于大小的邊界到底是多少？比如insert語句支持batch insert時，語句的長度多少，又比如遇到clob字段呢？ 1\. 首先clob字段的長度限制 clob家族類型的column長度受限于max_allowed_packet的大小，MySQL 5.5中，對于max_allowd_packet的大小限制在(1024, 1024*1024*1024)之間。 2\. mysqldump導出insert語句的時候，如何分割insert語句？ mysqldump時候支持insert t1 value(),(),();這樣的batch insert語句。 mysqldump其實是根據opt_net_buffer_length來進行分割，當一個insert語句超過這個大小，就強制分割到下一個insert語句中，這樣更多的是在做網絡層的優化。 又如果遇到大的clob字段怎么辦？ 如果一行就超過了opt_net_buffer_length，那就強制每一行都分割。 3\. mysql client端讀取dump文件的時候, 到底能分配多大的內存？ mysql.cc中定義了: `#define MAX_BATCH_BUFFER_SIZE (1024L * 1024L * 1024L)` 也就是mysql在執行語句的時候，最多只能分配1G大小的緩存。 所以，正常情況下，max_allowed_packet現在的最大字段長度和MAX_BATCH_BUFFER_SIZE限制的最大insert語句，是匹配的。 **RDS問題修復原則** 從問題的定位上來看，這一例crash屬于客戶錯誤使用mysqldump導致的問題，Aliyun RDS分支對內存導致的crash問題，都會定位并反饋給用戶。 但此例不做修復，而是引導用戶正確的使用mysqldump工具。