information_schema系列十_ZenDei技術網路在線

1：INNODB_FT_CONFIG 這張表存的是全文索引的信息，查詢前可以先通過以下語句查詢一下開啟全文索引的表： show variables like 'innodb_ft_aux_table'; 只有兩個列還是相當的簡單的： name Description KEY The name des ...

1：INNODB_FT_CONFIG 這張表存的是全文索引的信息，查詢前可以先通過以下語句查詢一下開啟全文索引的表： show variables like 'innodb_ft_aux_table'; 只有兩個列還是相當的簡單的：

name	Description
KEY	The name designating an item of metadata for an InnoDB table containing a FULLTEXT index.
VALUE	The value associated with the corresponding KEY column, reflecting some limit or current value for an aspect of a FULLTEXT index for an InnoDBtable.

2：INNODB_FT_BEING_DELETED 和INNODB_FT_DELETED INNODB_FT_BEING_DELETED 這張表是INNODB_FT_DELETED的一個快照。而且只在OPTIMIZE TABLE 的時候才會使用。OPTIMIZE TABLE 下麵會好好講一下。每次開始執行OPTIMIZE TABLE的時候，INNODB_FT_BEING_DELETED都會被清空，這個表的生命周期是很短的。只有指定innodb_ft_aux_table的時候才會有值，一般情況下都是空的（INNODB_FT_DELETED也是）。 INNODB_FT_DELETED這個表就比較屌了，能夠記錄有全文索引的INNODB表被刪除的行記錄。這個表主要是為了避免DML語句執行的時候昂虧的索引充足才會記錄被刪除的行記錄信息。刪除的記錄不會被立即清除，而是存儲在了INNODB_FT_DELETED中，只有當OPTIMIZE TABLE發生的時候才會被清除掉。這個表只有一個DOC__ID列，是指向innodb_ft_index_table 這張表。 3：INNODB_FT_INDEX_TABLE 這個表存儲的是關於INNODB表有全文索引的索引使用信息的，同樣這個表也是要設置innodb_ft_aux_table以後才能夠使用的，一般情況下是空的。SET GLOBAL

innodb_optimize_fulltext_only=ON;

mysql> use test;
mysql> CREATE TABLE articles (
      id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
      title VARCHAR(200),
      body TEXT,
      FULLTEXT (title,body)
    ) ENGINE=InnoDB;

mysql> INSERT INTO articles (title,body) VALUES
    ('MySQL Tutorial','DBMS stands for DataBase ...'),
    ('How To Use MySQL Well','After you went through a ...'),
    ('Optimizing MySQL','In this tutorial we will show ...'),
    ('1001 MySQL Tricks','1. Never run mysqld as root. 2. ...'),
    ('MySQL vs. YourSQL','In the following database comparison ...'),
    ('MySQL Security','When configured properly, MySQL ...');

mysql> SET GLOBAL innodb_optimize_fulltext_only=ON;
Query OK, 0 rows affected (0.00 sec)

mysql> OPTIMIZE TABLE articles;
+---------------+----------+----------+----------+
| Table         | Op       | Msg_type | Msg_text |
+---------------+----------+----------+----------+
| test.articles | optimize | status   | OK       |
+---------------+----------+----------+----------+
1 row in set (0.00 sec)

mysql> SET GLOBAL innodb_ft_aux_table = 'test/articles';
Query OK, 0 rows affected (0.00 sec)

mysql> USE INFORMATION_SCHEMA;

mysql> SELECT word, doc_count, doc_id, position FROM INNODB_FT_INDEX_TABLE LIMIT 5;
+------------+-----------+--------+----------+
| word       | doc_count | doc_id | position |
+------------+-----------+--------+----------+
| 1001       |         1 |      4 |        0 |
| after      |         1 |      2 |       22 |
| comparison |         1 |      5 |       44 |
| configured |         1 |      6 |       20 |
| database   |         2 |      1 |       31 |
+------------+-----------+--------+----------+

INNODB_FT_DEFAULT_STOPWORD這個表存放的是stopword 的信息，怎麼定義stopword 的信息可以以後補充一下： 5：INNODB_FT_INDEX_CACHE 這張表存放的是插入前的記錄信息，也是為了避免DML時候昂貴的索引重組。我們可以通過設置以下兩個變數來設置大小： innodb_ft_cache_size 和 innodb_ft_total_cache_size. 下麵詳細看一下OPTIMEZE TABLE 首先看一下語法:

OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL] TABLE tbl_name [, tbl_name] ...

我們知道mysql存儲引擎裡面的數據和索引數據都是物理存儲的,所以說為了減少空間使用和訪問表的時候能有更好的IO表現,所以說當表執行OPTIMIZE TABLE的時候,是會發生切實的變化的. 一般以下集中情況下,我們會使用OPTIMIZE TABLE來進行優化: 1:在大量的插入,更新,或者刪除INNODB表以後,我們再執行是很有必要的.此時如果執行OPTIMIZE TABLE的話,整表和表上所有的索引都會重組,而且不使用的表空間會被回收給操作系統. 2:在大量的插入,更新,或者刪除有全文索引的INNODB表的欄位以後,不過要首先設置innodb_optimize_fulltext_only=1,也可以通過指定innodb_ft_num_word_optimize 的值來指定能在索引裡面更新多少記錄.記錄數滿的時候就要通過OPTIMIZE TABLE來優化表. 3:在 MyISAM和 ARCHIVE 表做大量的刪除的時候就需要執行OPTIMIZE TABLE,或者是 MyISAM和 ARCHIVE 表做了欄位長度的更改,如果此時表中有大欄位的話,就更需要執行OPTIMIZE TABLE 來優化表了.因為被刪除的記錄的位置還是會保存,並不會進行回收,等待新紀錄插入,或者OPTIMIZE TABLE 進行重組才回回收.而且最重要的一點是OPTIMIZE TABLE以後性能會得到很大的提升,特別是表做過較大的變更以後在執行,性能提升會非常的明顯. OPTIMEZE TABLE 需要的許可權: 對錶insert 和 select許可權. 而且OPTIMIZE TABLE 對分區表也是支持的,具體的語法是 ALTER TABLE t1 OPTIMIZE PARTITION p0, p1; 從上面就可以看出來OPTIMEZE TABLE對於INNODB,MyISAM和 ARCHIVE 的表都是適用的,對於其他引擎的數據表都是不適用的,如果想要使用OPTIMIZE TABLE 優化表,就要在啟動mysqld的時候使用--skip-new參數啟動. OPTIMIZE TABLE 可以線上DDL,通過指定(ALGORITHM=INPLACE) ,不過這個只支持INNODB表,普通表和分區表都是支持的.表重建的方式有兩種,OPTIMIZE TABLE 和 ALTER TABLE ... FORCE兩種方式都可以觸發表重建. OPTIMIZE TABLE 也有適用於 ALGORITHM=COPY的一些條件: 1:當old_alter_table參數設置為ON的時候,OPTIMIZE並不會重建,而是使用一個臨時表先把記錄插進去來做處理.這個時候就要使用ALGORITHM=COPY來處理了. 2:當mysqld以--skip-new 為方式啟動的時候 3:當INNODB表含有全文索引的時候 ,就只能夠使用ALGORITHM=COPY來進行優化了 INNODB的數據存儲是按照page-allocation的方式存儲的,這和MYASIM引擎是不相同的,所以當我們考慮要OPTIMEZE一張表的時候,一定要先考慮以下的幾個問題: 1:INNODB表的索引碎片是有所保留的,一般情況下是最多只能夠占用93%的,剩餘的一些是要保留起來用於update更新時候的頁分裂來分配空間 2:刪除操作會留下一部分的空間,只有當OPTIMIZE TABLE的時候才會重新的回收. 3:update的記錄等於是對原有的數據頁進行重新的寫入,這和數據類型和行格式是有很大關係的.這個是有前提條件的,就是原有的頁有足夠的空間能夠書寫新數據. 4:高併發的情況下,會造成索引的間隙,這個產生的主要原因就是因為MySQL的事物是基於MVCC來實現的. OPTIMIZE TABLE 對於MYASIM表的支持: 1:如果表有刪除或者行拆分的話,就要repair table 2:如果索引頁沒有劃分,就會重新劃分索引頁 3:統計信息如果不准確的話,就會重新更新統計信息 OPTIMIZE TABLE 返回信息尅看一下:

Column	Value
Table	The table name
Op	Always optimize
Msg_type	status, error, info, note, or warning
Msg_text	An informational message

但是還要記住一點就是5.7.4以前的版本OPTIMIZE TABLE的時候會鎖定全表,之後版本的INNODB表就就可以線上OPTIMIZE 了.而且更重要的是OPTIMIZE TABLE 會記錄二進位日誌,所以說對於複製的機器是會傳送到slave上的.而且他對R-TREE結構的索引是不起作用的. 快速分析mysql的表信息,MYASIM引擎:

myisamchk --quick --check-only-changed --sort-index --analyze

重新組織表:

ALTER TABLE [tbl_name] TYPE=innodb

修改表行格式:

alter table your_table row_format=compressed