從mysql5.6版本開始支援innodb引擎的全文索引，文法層面上大多數相容之前myisam的全文索引模式。 所謂全文索引，是一種通過建立反向索引，快速比對文檔的方式。mysql支援三種模式的全文檢索模式：
第一種是自然語言模式（in natural language mode），即通過match against 傳遞某個特定的字元串來進行檢索。
第二種是布爾模式（in boolean mode），可以為檢索的字元串增加操作符，例如“+”表示必須包含，“-”表示不包含，“*”表示通配符（這種情況，即使傳遞的字元串較小或出現在停詞中，也不會被過濾掉），其他還有很多特殊的布爾操作符，可以通過如下參數控制：
第三種是查詢擴充模式（with query expansion）, 這種模式是自然語言模式下的一個變種，會執行兩次檢索，第一次使用給定的短語進行檢索，第二次是結合第一次相關性比較高的行進行檢索。
目前mysql支援在char、varchar、text類型的列上定義全文索引。
本文隻是簡單的分析了全文索引涉及到的代碼子產品以及5.7的一些新特性，源碼部分基于mysql5.7.8-rc版本。更細節的部分并未深入。
如下例所示，一個簡單的建立帶全文索引表的sql：
磁盤上會産生多個檔案：
除了t1.frm和t1.ibd外，共分為以下幾類表
a)
fts_000000000000010b_0000000000000154_index_1~6.ibd這6個檔案用于存儲反向索引，存儲的是分詞和位置以及docment id，根據分詞的第一個字元值進行分區，映射到不同的檔案中。
檔案的命名規則為fts_{table_id}_{index_id}_index_{n}.ibd
b)
fts_000000000000010b_deleted.ibd 包含已經被删除的doc_id，但還沒從全文索引資料中删掉;
fts_000000000000010b_deleted_cache.ibd 是前者的記憶體緩存（但是搜尋了下代碼，隻有當fts_cache_t::deleted_doc_ids被使用時，才會在sync時轉儲到該表中，但并沒有發現任何地方使用這個對象）
c)
fts_000000000000010b_being_deleted_cache.ibd
fts_000000000000010b_being_deleted.ibd
包含了已經被删除索引記錄并且正在從全文索引中移除的doc id， 前者是後者的記憶體版本，這兩個表主要用于輔助進行optimize table時将deleted/deleted_cached表中的記錄轉儲到其中。
d)
fts_000000000000010b_config.ibd
包含全文索引的内部資訊，最重要的存儲是fts_synced_doc_id，表示已經解析并刷到磁盤的doc id. 在崩潰恢複時，可以根據這個值判斷哪些該重新解析并加入到索引cache中。
建全文索引輔助表函數參考：
當對一個已經存在的表上建立全文索引時，innodb采用了fork多個線程進行并發建構全文索引項的方法，并發度由參數 <code>innodb_ft_sort_pll_degree</code> 控制。是以在restore一個全文索引表時，我們建議先建表、導入資料，再在表上建立全文索引。
參考函數：<code>row_merge_read_clustered_index --> row_fts_start_psort</code>
線程回調函數為fts_parallel_tokenization。
當表上存在全文索引時，就會隐式的建立一個名為fts_doc_id的列，并在其上建立一個唯一索引，用于辨別分詞出現的記錄行。你也可以顯式的建立一個名為fts_doc_id的列，但需要和隐式建立的列類型保持一緻。
為了維護表上的全文索引資訊，全文索引子產品定義了大量的類來進行管理，總的來說，如下圖所示：
我們可以通過innodb_ft_index_cache來檢查插入記錄的分詞：
在插入一條記錄時，對應的堆棧如下：
在向原表上插入完成記錄後，會去判斷表上是否有全文索引（dict_tf2_fts），如果有的話，則将插入記錄對應的doc id提取出來(fts_get_doc_id_from_row)，并緩存到事務對象中。
删除操作不會直接從全文索引裡直接删除，是以依然可以從innodb_ft_index_cache中查到分詞資訊
相關堆棧：
更新非全文索引列，不會修改fts_doc_id列的值。如果更新了全文索引列，在innodb的實作是删除老的doc，并插入新的doc
堆棧為：
可見所有dml的操作，都走接口函數<code>fts_trx_add_op</code>，劃分為兩種操作:fts_insert及fts_delete；目前事務涉及的doc id被存儲到trx->fts_trx中，在執行sql的過程中并沒有更新全文索引，而是在事務送出時進行的。
在緩存操作時，維護了兩個結構，一個是trx->fts_trx->savepoints，維護了事務全局的全文索引操作，另外一個是trx->fts_trx->last_stmt，維護的是目前sql操作的doc id，前者在事務結束時處理，後者在sql結束時清空。
對于全文索引的查詢，采用新的接口函數，分為兩步
第一步，根據檢索詞搜集符合條件的doc id
在搜集滿足查詢條件的doc id時，首先讀取deleted表中記錄的doc id，這些doc id随後被用做過濾。
第二步，根據搜集到的doc id，找到對應的記錄，使用的索引是dict_table_t::fts_doc_id_index，也就是建立在隐藏列fts_doc_id上的唯一索引。
通常查詢傳回的結果是根據rank排序的，innodb的全文檢索排序規則和sphinx類似，基于 bm25 和 tf-idf算法。
rank的計算算法如下：
idf的計算參閱函數：<code>fts_query_calculate_idf</code>
ranking計算：<code>fts_query_calculate_ranking</code>
如果使用多個單詞比對到，則把各個單詞各自的rank累加起來。官方部落格有一篇文章專門對此進行了介紹。
事務内復原
正在事務内復原某個語句，或者復原到某個savepoint時，需要将對應的操作記錄也要删除。維護了trx->fts_trx->last_stmt，在單條sql結束時釋放(trx_mark_sql_stat_end )。如果sql復原，就根據last_stmt中維護的doc id從全局savepoints中清理掉本條sql的doc id。
復原到savepoint
事務送出
在調用fts_commit時，會根據不同的操作類型，調用fts_add增加全文索引項，調用fts_delete删除全文索引項。
由于在插入記錄時，先分詞、分解成多個詞插入輔助表中，是以一條insert可能産生多個小的插入。這種寫入放大可能是不可承受的。innodb采用了一種優化的方案：建立一個記憶體cache,臨時緩存插入操作，當cache滿時再批量刷到磁盤，這樣做的好處是：
避免重複存儲相同的單詞
cache size 通過參數innodb_ft_cache_size控制
查詢會将cache和磁盤資料進行merge
在事務送出時，調用函數<code>fts_add_doc_by_id</code>：
首先根據doc id，使用doc_id所在的索引進行查詢，找到剛剛插入的記錄項對應的聚集索引記錄。
周遊表上全部的聚集索引，根據全文索引對應的fts_get_doc_t(fts_cache_t::get_docs)建構fts_doc_t，對文檔根據選擇的parser進行分詞(fts_tokenize_document函數或者fts_tokenize_document_next)，具體的文檔存儲到fts_doc_t::text中。
将上一步獲得的分詞加入到cache中（fts_cache_add_doc）
如果目前cache的大小超過配置的<code>innodb_ft_cache_size</code>，或者全局cache的大小超過<code>innodb_ft_total_cache_size</code>(fts_need_sync被設定為true)，則進行一次sync，将該表緩存的資料刷到全文索引檔案中(fts_sync)，并清空cache。
和插入相似，删除操作也可能産生大量小的删除操作， 為了避免這種情況，維持一個表，來記錄被删除的doc id， 但記錄依然存在于原檔案中。删除操作的送出函數為fts_delete，将被删除的記錄doc_id插入到deleted輔助表中。
事務子產品涉及的幾個關鍵類包括：
在滿足一定條件時，全文索引需要進行一次sync操作，将資料同步到全文索引檔案中，大概包含以下集中情況需要sync：
cache資料占用的記憶體超過限制
背景線程fts_optimize_thread在shutdown調用，将所有表進行一次sync。
ha_innobase::optimize調用（執行optimize table）
row_merge_read_clustered_index：建立一個新的臨時表并讀入資料後，進行一次sync調用
同步操作的入口函數為fts_sync，大體流程為：
針對每個索引，調用函數fts_sync_index：通過函數fts_select_index計算寫入的索引檔案，再将分詞節點資訊寫入到檔案（函數fts_write_node）, 反向索引的記錄内容使用結構體fts_node_t進行描述，存儲結構如下圖所示：
調用fts_sync_commit送出sync操作：
更新config表記錄的最大sync的doc id（fts_cmp_set_sync_doc_id）；
若fts_cache_t::deleted_doc_ids不為空，将其加入到deleted_cache輔助表中（<code>fts_sync_add_deleted_cache</code>）
清空cache 并重新初始化
當你修改了某些配置（例如最小token size時），或者希望重組全文索引時，可以執行optimize table。由于原始optimize table操作會産生整個表的重建，耗時太久，是以innodb引入了一個參數<code>innodb_optimize_fulltext_only</code>來控制該行為。當開啟該選項時，如果執行optimize table，就隻優化全文索引，而不會去重建表，入口函數為ha_innobase::optimize：
首先調用函數<code>fts_sync_table</code>，将表上在記憶體中cache的資料刷到全文索引檔案中；
然後調用函數<code>fts_optimize_table</code>，我們主要分析集中在第二步。
fts_optimize_table函數流程如下：
如果beging_deleted表中沒有資料（例如第一次調用optimized table），則将deleted表中的資料轉儲到being_deleted表中，相當于拿到了一個快照，執行的sql操作為：
參考函數：<code>fts_optimize_create_deleted_doc_id_snapshot</code>
從being_deleted/being_deleted_cache表中讀取已經被删除的doc id，這些doc id在随後的索引優化中将被忽略掉。
參考函數：<code>fts_optimize_read_deleted_doc_id_snapshot</code>
調用fts_optimize_indexes 對每個索引進行優化，相關堆棧如下：
當在所有索引上完成optimize後，調用fts_optimize_purge_snapshot，主要操作包括：
從delete和delete_cache表中将doc id删除，參考函數fts_optimize_purge_deleted_doc_ids
從being_deleted及being_deleted_cache中删除對應的doc id。
參考函數： <code>fts_optimize_purge_deleted_doc_id_snapshot</code>
innodb啟動時，會建立一個背景線程，線程函數為<code>fts_optimize_thread</code>，工作隊列為<code>fts_optimize_wq</code>，其主要目的是在滿足一定條件時，對表自動進行optimize操作。
在如下兩種情況，會向<code>fts_optimize_wq</code>中增加元組：
fts_optimize_add_table: 建立或打開一個新的帶全文索引的表時，建立一個類型為<code>fts_msg_add_table</code>并包含表對象指針的msg，加入到<code>fts_optimize_wq</code>中，這些表禁止被從資料詞典中驅逐。
fts_optimize_remove_table: 删除表、ddl、釋放表對象(<code>dict_mem_table_free</code>)、删除全文索引(<code>fts_drop_index</code>)等操作時，會建立一個類型為<code>fts_msg_del_table的meg</code>，加入到<code>fts_optimize_wq</code>隊列中。
fts optimize線程對于fts_msg_add_table類型的會将相應的表加入到排程隊列，對于fts_msg_del_table，則從排程隊列中删除。其排程隊列的成員類型為fts_slot_t。
當表上删除的資料量超過一千萬(fts_optimize_threshold)行時，就會觸發一次自動optimize table，但兩次optimize的間隔不應低于300秒（fts_optimize_interval_in_secs）。
我們可以通過幾個information_schema下的全文索引表來監控全文索引狀态。
想要從information_schema表中查詢資訊，需要先設定變量innodb_ft_aux_table，值為你要查詢表的"dbname/tablename"。
停詞(stop word)用于在分詞時忽略那些常見的不重要的單詞，innodb目前内建的停詞可以從information_schema.innodb_ft_default_stopword讀取，使用者也可以自己定義停詞清單，方法很簡單：建立一個和nformation_schema.innodb_ft_default_stopword一模一樣的表，将你想要的停詞加入到其中，然後設定innodb_ft_server_stopword_table值為你建立的表名："dbname/tabname"。
你也可以使用會話級别的參數innodb_ft_user_stopword_table來指定你想要的停詞表。和上述建立規則一緻。具體的參閱官方文檔
另外配置項<code>innodb_ft_min_token_size</code>及<code>innodb_ft_max_token_size</code> 用于表示一個單詞的字元長度範圍，在這個範圍的連續字元串才會被當作一個單詞。 然而如果使用ngram解析器的話，有效單詞長度受參數ngram_token_size控制。
可以關閉參數innodb_ft_enable_stopword，這樣在分詞時也會把預設的停詞考慮進去。
從mysql 5.7.3開始innodb支援全文索引插件，使用者可以以plugin的模式來定義自己的分詞規則，或是引入社群開發的全文索引解析器，例如某些專業領域的分詞，可能具有不同的規則。
全文索引插件有兩種角色：第一種是替換内建的parser，讀取輸入文檔，進行解析後，将分詞傳送給server； 另一種角色是作為内建parser的協作者，可以把輸入文檔處理過後，再傳送給内建parser。
如果你已經有一個基于myisam的全文索引插件了，也可以根據這篇官方文檔的介紹，将其修改成innodb全文索引插件。
從mysql5.7.6版本開始提供了一種内建的全文索引ngram parser，可以很好的支援clk字元集（中文，韓文，日文），clk有個共同點就是單詞不像英語習慣那樣根據空格進行分解的，是以傳統的内建分詞方式無法準确的對類似中文進行分詞。
ngram parser内建在代碼中，該解析器默安裝，你可以通過指定索引屬性（<code>with parser ngram</code>）來利用該parser，例如：
n-gram使用一種特殊的方式來進行分詞，舉個簡單的例子，假設要對單詞'abcd'進行分詞，那麼其分詞結果為：
n取決于ngram_token_size`的設定，預設值為2.
對于停詞的處理， n-gram和内建的parser不同，即隻要每個token包含了（而不是精确比對）停詞，就不對其進行索引； 另外空格總是作為一個停詞，是以在分詞取token時，空格會被忽略掉。
在執行查詢時，使用者傳遞的搜尋詞也會基于n-gram進行分解後進行檢索。 具體的例子可以參閱官方部落格的描述。
除了n-gram parser外，官方也支援了另外一種名為mecab parser的插件，主要用于日語分詞，但需要手動安裝。