InnoDB全文索引基础

全文索引：

官方文档：

https://dev.mysql.com/doc/refman/5.6/en/fulltext-search.html

参考：

http://blog.csdn.net/u011734144/article/details/52817766

http://www.cnblogs.com/olinux/p/5169282.html

全文检索通常使用的是倒排索引。

内容详见姜大神的InnoDB存储引擎2 书上 Page231~Page248

InnoDB存储引擎从1.2.x开始支持全文索引技术，其采用full inverted index的方式。在InnoDB存储引擎中，将(DocumentID,Postition)视为一个ilist。因此在全文检索的表中，有两个列，一个是word字段，一个是ilist字段。并且在word字段上有设索引。此外，由于InnoDB存储引擎在ilist字段上存放了Position信息，故可以进行Proximity Search，而MyISAM不支持该特性

如之前所说，倒排索引需要将word存放在一个表中，这个表称为Auxiliary Table(辅助表)在InnoDB存储引擎中，为了提高全文检索的并发性。共有6张Auxiliary Table，每张表根据word的Latin编码进行分区

Auxiliary Table是持久的表，存放在磁盘上，然而在InnoDB存储引擎的全文索引中，还有另外一个重要的概念FTS Index Cache(全文检索索引缓存)，其用来提高全文检索的性能

FTS Index Cache是一个红黑树结构，其根据(word,ilist)进行排序，这意味着插入的数据已更新了对应的表，但是对全文索引的更新可能在分词操作后还在FTS Index Cache中，Auxiliary Table可能没有更新。InnoDB存储引擎会批量对 Auxiliary Table 进行更新。而不是每次插入后更新一次Auxiliary Table。当全文检索进行查询时,Auxiliary Table首先会将在FTS Index Cache 中对应的word字段合并到Auxiliary Table中，然后进行查询。这种merge操作非常类似之前的Insert Buffer功能。不同的是Insert Buffer是个持久性的对象，并且是B+树结构，然后FTS Index Cache的作用又和Insert Buffer类似，它提高了InnoDB存储引擎的性能，并且由于其根据红黑树排序后进行批量插入，其产生的Auxiliary Table相对较小。

InnoDB存储引擎允许用户查看指定倒排索引的Auxiliary Table分词的信息，可以通过设置innodb_ft_aux_table来观察倒排索引的 Auxiliary Table 下面的SQL 语句设置查看test架构下表fts_a的Auxiliary Table:

SET GLOBAL innodb_ft_aux_table=‘test/fts_a‘;

设置后，可以在information_schema架构下的表INNODB_FT_INDEX_TABLE得到表fts_a中的分词信息。

对于InnoDB存储引擎而言，其总是在事务提交时将分词写入到FTS Index Cache,然后通过批量写入到磁盘。虽然InnoDB存储引擎通过一种延时的、批量的写入方式来提高数据库的性能，但是上述操作仅在事务提交时发生。

当数据库关闭时，在FTS Index Cache中的数据库会同步到磁盘上的Auxiliary Table中。如果当数据库发生宕机时，一些FTS Index Cache中的数据可能未同步到磁盘上，那么下次重启数据库时，当用户对表进行全文检索(查询、插入)时,InnoDB存储引擎会自动读取未完成的文档，然后进行分词操作，再将分词结果放到FTS Index Cache中。

参数 innodb_ft_cache_size 用来控制FTS Index Cache的大小，默认值是32M。当该缓存满时，会将其中的(word,ilist)分词信息同步到磁盘的Auxiliary Table中。增大该参数可以提高全文检索性能。但是在宕机时候，未同步到磁盘中的索引信息可能需要更长的时间进行恢复。

为了支持全文检索，必须有一个列与word进行映射。在InnoDB中这个列被命名成FTS_DOC_ID，其类型为BIGINT UNSIGNED NOT NULL，并且InnoDB存储引擎自动会在该列加上一个名为FTS_DOC_ID_INDEX的Unique Index。这些操作由存储引擎自己完成，用户也可以在建表时自动添加FTS_DOC_ID,以及对应的Unique Index。由于列名FTS_DOC_ID聚友特殊意义，因此在创建时必须注意相应的类型，否则会报错。

文档中的分词的插入操作是在事务提交时完成，但是对于删除操作，其在事务提交时，不删除磁盘Auxiliary Table的记录，而只是删除FTS Cache Index记录，对于Auxiliary Table中被删除的记录，存储引擎会记录其FTS DOCUMENT ID ,并将其保存在DELETE auxiliary table中，在设置参数innodb_ft_aux_table后，用户可以访问information_schema架构下的表INNODB_FT_DELETED来观察删除的FTS Document ID

由于文档的DML操作实际并不删除索引中的数据，相反还会在对应的DELETED表中插入记录，因此随着应用程序的允许，索引会变得越来越大，即使索引中的有些数据已经被删除，查询也不会选择这类记录，为此，InnoDB提供了一种方式，允许用户手工将已删除的记录从索引中彻底删除，这就是OPTIMIZE TABLE。因为OPTIMIZE TABLE还会进行一些其他的操作。如Cardinality重新统计，若用户希望对倒排索引进行操作，可以通过innodb_optimize_fulltext_only设置

SET GLOBAL innodb_optimize_fulltext_only=1;

OPTIMIZE TABLE fts_a;

若被删除的文档很多，那么OPTIMIZE TABLE操作可能占用非常多的时间，会影响到程序并发性，并极大的降低用户的响应时间，用户可以通过参数innodb_ft_num_word_optimize来限制每次实际删除的分词数量，默认为2000

例子：

> use test;

> CREATE TABLE fts_a(

FTS_DOC_ID BIGINT UNSIGNED AUTO_INCREMENT NOT NULL,

body TEXT,

PRIMARY KEY(FTS_DOC_ID)

);

INSERT INTO fts_a SELECT NULL,‘pease porridge in the pot‘;

INSERT INTO fts_a SELECT NULL,‘pease porridge hot,pease porridge cold‘;

INSERT INTO fts_a SELECT NULL,‘Nine days old‘;

INSERT INTO fts_a SELECT NULL,‘Some like it hot,some like it cold‘;

INSERT INTO fts_a SELECT NULL,‘Some like it the pot‘;

INSERT INTO fts_a SELECT NULL,‘Nine days old‘;

INSERT INTO fts_a SELECT NULL,‘I like code days‘;

CREATE FULLTEXT INDEX idx_fts ON fts_a(body);

查看数据：

> select * from fts_a;

+------------+----------------------------------------+

| FTS_DOC_ID | body                                   |

+------------+----------------------------------------+

|          1 | pease porridge in the pot             |

|          2 | pease porridge hot,pease porridge cold |

|          3 | Nine days old                          |

|          4 | Some like it hot,some like it cold     |

|          5 | Some like it the pot                   |

|          6 | Nine days old                          |

|          7 | I like code days                       |

+------------+----------------------------------------+

7 rows in set (0.00 sec)

> set global innodb_ft_aux_table=‘test/fts_a‘;

Query OK, 0 rows affected (0.00 sec)

> SELECT * FROM information_schema.`INNODB_FT_INDEX_TABLE`;

+----------+--------------+-------------+-----------+--------+----------+

| WORD     | FIRST_DOC_ID | LAST_DOC_ID | DOC_COUNT | DOC_ID | POSITION |

+----------+--------------+-------------+-----------+--------+----------+

| code     |            7 |           7 |         1 |      7 |        7 |

| cold     |            2 |           4 |         2 |      2 |       34 |

| cold     |            2 |           4 |         2 |      4 |       30 |

| days     |            3 |           7 |         3 |      3 |        5 |

| days     |            3 |           7 |         3 |      6 |        5 |

| days     |            3 |           7 |         3 |      7 |       12 |

| hot      |            2 |           4 |         2 |      2 |       15 |

| hot      |            2 |           4 |         2 |      4 |       13 |

| like     |            4 |           7 |         3 |      4 |        5 |

| like     |            4 |           7 |         3 |      4 |       17 |

| like     |            4 |           7 |         3 |      5 |        5 |

| like     |            4 |           7 |         3 |      7 |        2 |

| nine     |            3 |           6 |         2 |      3 |        0 |

| nine     |            3 |           6 |         2 |      6 |        0 |

| old      |            3 |           6 |         2 |      3 |       10 |

| old      |            3 |           6 |         2 |      6 |       10 |

| pease    |            1 |           2 |         2 |      1 |        0 |

| pease    |            1 |           2 |         2 |      2 |        0 |

| pease    |            1 |           2 |         2 |      2 |       19 |

| porridge |            1 |           2 |         2 |      1 |        6 |

| porridge |            1 |           2 |         2 |      2 |        6 |

| porridge |            1 |           2 |         2 |      2 |       19 |

| post     |            1 |           1 |         1 |      1 |       22 |

| pot      |            5 |           5 |         1 |      5 |       17 |

| some     |            4 |           5 |         2 |      4 |        0 |

| some     |            4 |           5 |         2 |      4 |       17 |

| some     |            4 |           5 |         2 |      5 |        0 |

+----------+--------------+-------------+-----------+--------+----------+

可以看到每个word对应一个DOC_ID和POSITION。此外，还记录了FIRST_DOC_ID、LAST_DOC_ID、DOC_COUNT分别代表该word第一次出现文档的ID,最后一次出现的文档ID，以及该word在多少个文档中存在。

若此时执行下面的SQL语句，会删除FTS_DOC_ID为7的文档

> DELETE FROM fts_a WHERE FTS_DOC_ID=7;

InnoDB存储引擎并不会直接删除索引中对应的记录，而是将删除的文档ID插入到DELETED表

> SELECT * FROM information_schema.`INNODB_FT_DELETED`;

+--------+

| DOC_ID |

+--------+

|      7 |

+--------+

如果用户想要彻底删除倒排索引中该文档的分词信息，可以执行：

> SET GLOBAL innodb_optimize_fulltext_only=1;

> OPTIMIZE TABLE fts_a;

+------------+----------+----------+----------+

| Table      | Op       | Msg_type | Msg_text |

+------------+----------+----------+----------+

| iot2.fts_a | optimize | status   | OK       |

+------------+----------+----------+----------+

验证；

> SELECT * FROM information_schema.`INNODB_FT_DELETED`;

+--------+

| DOC_ID |

+--------+

|    7 |

+--------+

> SELECT * FROM information_schema.`INNODB_FT_BEING_DELETED`;

+--------+

| DOC_ID |

+--------+

|    7 |

+--------+

> SELECT count(*) FROM information_schema.`INNODB_FT_INDEX_TABLE`;   -- INNODB_FT_INDEX_TABLE表里面剩余的行数

+----------+

| count(*) |

+----------+

|     24 |

+----------+

运行OPTIMIZE TABLE 可以将记录彻底删除，并且彻底删除的文档ID会记录到INNODB_FT_BEGIN_DELETED中。

此外，由于FTS_DOC_ID为7的这个文档已经被删除，因此不允许在插入这个文档ID，否则会抛出异常

> INSERT INTO fts_a SELECT 7,‘I like this days‘;

ERROR 182 (HY000): Invalid InnoDB FTS Doc ID

stopword列表(stopword list)是本节最后阐述的一个概念，其表示该列表中的word不需要对其进行索引分词操作。例如，对于the这个单词，由于其不具有具体的意义，因此将其视为stopword，InnoDB存储引擎有一张默认的stopword列表，在information_schema架构下，表名为INNODB_FT_DEFAULT_STOPWORD，默认为36个stopword可以通过参数 innodb_ft_server_stopword_table 来定义stopword列表，如

> CREATE TABLE test.user_stopword (value VARCHAR(30) NOT NULL DEFAULT ‘‘ ) ENGINE=INNODB DEFAULT CHARSET=utf8;  #此处必须为utf8不然会碰到bug

> SET GLOBAL innodb_ft_server_stopword_table=‘test/user_stopword‘;

这样的话，

使用全文检索还有以下限制：

1 每张表只能有一个全文检索的索引

2 由多列组合而成的全文检索的索引必须使用相同的字符集与排序规则

3 不支持没有单词界定符delimiter的语言，如中文 日文汉语等。

全文检索语法：

MATCH (col1,col2,...) AGAINST (expr [search_modifier])

MATCH指定了需要被查询的列。AGAINST指定了使用何种方法去进行查询。

查询模式有3种：Natural Language 、 Boolean  、 Query Expansion

1、Natural Language （默认的全文检索查询模式）

test> SELECT * FROM fts_a WHERE MATCH(body) AGAINST (‘Porridge‘ in natural language mode);

+--------------+----------------------------------------------+

|   FTS_DOC_ID | body                           |

|--------------+----------------------------------------------|

|            2 | pease porridge hot,pease porridge cold |

|            1 | pease porridge in the post         |

+--------------+----------------------------------------------+

传统查询：

test> explain extended SELECT * from fts_a where body like ‘%Porridge%‘;

+------+---------------+---------+--------+-----------------+--------+-----------+--------+--------+------------+-------------+

|   id | select_type   | table   | type   |   possible_keys |    key |   key_len |    ref |   rows |   filtered | Extra       |

|------+---------------+---------+--------+-----------------+--------+-----------+--------+--------+------------+-------------|

|    1 | SIMPLE        | fts_a   | ALL    |          <null> | <null> |    <null> | <null> |      6 |        100 | Using where |

+------+---------------+---------+--------+-----------------+--------+-----------+--------+--------+------------+-------------+

全文索引查询：

test> explain extended SELECT * from fts_a where match(body) against (‘Porridge‘ in natural language mode);

+------+---------------+---------+----------+-----------------+---------+-----------+--------+--------+------------+-------------+

|   id | select_type   | table   | type     | possible_keys   | key     |   key_len |    ref |   rows |   filtered | Extra       |

|------+---------------+---------+----------+-----------------+---------+-----------+--------+--------+------------+-------------|

|    1 | SIMPLE        | fts_a   | fulltext | idx_fts         | idx_fts |         0 | <null> |      1 |        100 | Using where |

+------+---------------+---------+----------+-----------------+---------+-----------+--------+--------+------------+-------------+

可以看到用到了全文索引。

在WHERE条件中使用MATCH函数，查询返回的结果是根据相关性进行排序的，即相关性最高的结果放在第一位。0表示没有任何的相关性。

相关性的计算依赖下面4个条件：

1、word是否在文档中出现

2、word在文档中出现的次数

3、word在索引列中的数量

4、多少个文档包含该word

上面的那个select 查询中，文档2中porridge出现了2次，因此排在上面。

查询相关性的SQL语句：

test> SELECT fts_doc_id,body , match(body) AGAINST (‘Porridge‘ in natural language mode) as Relevance from fts_a ORDER BY Relevance DESC;

+--------------+-------------------------------------------------------------+-------------+

|   fts_doc_id | body                                                        |   Relevance |

|--------------+-------------------------------------------------------------+-------------|

|           29 | i am porridge ,and you is porridge,and we are all porridge. |   0.271857  |

|            2 | pease porridge hot,pease porridge cold                      |   0.181238  |

|            1 | pease porridge in the post                                  |   0.0906191 |

|            3 | Nine days old                                               |   0         |

|            6 | Nine days old                                               |   0         |

|           27 | I like this days                                            |   0         |

|           28 | hello world                                                 |   0         |

+--------------+-------------------------------------------------------------+-------------+

对于全文检索，还需要考虑以下的因素：

查询的word在stopword列中，忽略该字符串的查询。

查询的word的字符长度是否在区间[innodb_ft_min_token_size, innodb_ft_max_token_size]内。(默认是3-84个字符长度)

如：test> SELECT fts_doc_id,body , match(body) AGAINST (‘the‘ in natural language mode) as Relevance from fts_a ORDER BY Relevance desc ;

+--------------+-------------------------------------------------------------+-------------+

|   fts_doc_id | body                                                        |   Relevance |

|--------------+-------------------------------------------------------------+-------------|

|            1 | pease porridge in the post                                  |           0 |

|            2 | pease porridge hot,pease porridge cold                      |           0 |

|            3 | Nine days old                                               |           0 |

|            6 | Nine days old                                               |           0 |

|           27 | I like this days                                            |           0 |

|           28 | hello world                                                 |           0 |

+--------------+-------------------------------------------------------------+-------------+

2、Boolean Language

test> SELECT * from fts_a where match(body) against(‘+Pease - hot‘ in boolean mode);

+--------------+----------------------------+

|   FTS_DOC_ID | body                       |

|--------------+----------------------------|

|            1 | pease porridge in the post |

+--------------+----------------------------+

boolean全文检索支持以下的几种操作符：

官网文档：https://dev.mysql.com/doc/refman/5.6/en/fulltext-boolean.html

1 加号表示必须出现

2 减号表示一定不能出现

3 (no operator) 表示该word是可选的，但是如果出现，其相关性会更高

4 @distance 表示查询的多个单词之间的距离是否在distance之内，distance的单位是单词。这种全文索引的查询也称为proximity Search。

如MATCH(body)AGAINST(‘"Pease pot"@20‘ IN BOOLEAN MODE) 表示字符串Pease和pot之间的距离需在20个单词范围内。

5 > 表示出现该单词时增加相关性

6 < 表示出现该单词时降低相关性

7 ~ 表示运行出现该单词，但是出现时相关性为负

8 * 表示以该单词开头的单词，如lik* 可以表示lik、like、likes之类的。

9 " 表示短语。

"例子：

找出有Pease且有hot的文档：

test> SELECT * from fts_a where match(body) against(‘+Pease +hot‘ in boolean mode);

+--------------+----------------------------------------+

|   FTS_DOC_ID | body                                   |

|--------------+----------------------------------------|

|            2 | pease porridge hot,pease porridge cold |

+--------------+----------------------------------------+

找出有Pease或者hot的文档：

test> SELECT * from fts_a where match(body) against(‘Pease hot‘ in boolean mode);

+--------------+----------------------------------------+

|   FTS_DOC_ID | body                                   |

|--------------+----------------------------------------|

|            2 | pease porridge hot,pease porridge cold |

|            1 | pease porridge in the post             |

+--------------+----------------------------------------+

找出2个单词之间距离不超过8的文档：

test> SELECT * from fts_a where match(body) against(‘"lirulei days" @8‘ in boolean mode);

+--------------+-----------------------------------------------------+

|   FTS_DOC_ID | body                                                |

|--------------+-----------------------------------------------------|

|           31 | i am lirulei, and happy qixi days                   |

+--------------+-----------------------------------------------------+

根据是否有单词like或者pot进行相关性统计，并把出现pot的文档的相关性提高。（文档4中虽然有2个like，但是没有pot，因此相关性没有文档1和5高）

test> SELECT fts_doc_id, body,  match(body) against(‘like > pot‘ in boolean mode) as Relevance from fts_a ORDER BY Relevance desc ;

+--------------+----------------------------------------+-------------+

|   fts_doc_id | body                                   |   Relevance |

|--------------+----------------------------------------+-------------|

|            5 | Some like it the pot                   |    1.43142  |

|            1 | pease porridge in the pot              |    1.29601  |

|            4 | Some like it hot,some like it cold     |    0.270814 |

|            7 | I like code days                       |    0.135407 |

|            2 | pease porridge hot,pease porridge cold |    0        |

|            3 | Nine days old                          |    0        |

|            6 | Nine days old                          |    0        |

+--------------+----------------------------------------+-------------+

对上面的查询增加个降低出现some的文档的权重的查询条件：

test> SELECT fts_doc_id, body,  match(body) against(‘like >hot <some‘ in boolean mode) as Relevance from fts_a ORDER BY Relevance desc ;

+--------------+----------------------------------------+-------------+

|   fts_doc_id | body                                   |   Relevance |

|--------------+----------------------------------------+-------------|

|            2 | pease porridge hot,pease porridge cold |    1.29601  |

|            4 | Some like it hot,some like it cold     |    1.15884  |

|            7 | I like code days                       |    0.135407 |

|            1 | pease porridge in the pot              |    0        |

|            3 | Nine days old                          |    0        |

|            6 | Nine days old                          |    0        |

|            5 | Some like it the pot                   |   -0.568583 |

+--------------+----------------------------------------+-------------+

找出cod开头的文档：

test> SELECT fts_doc_id, body,  match(body) against(‘cod*‘ in boolean mode) as Relevance from fts_a ORDER BY Relevance desc ;

+--------------+----------------------------------------+-------------+

|   fts_doc_id | body                                   |   Relevance |

|--------------+----------------------------------------+-------------|

|            7 | I like code days                       |    0.714191 |

|            1 | pease porridge in the pot              |    0        |

|            2 | pease porridge hot,pease porridge cold |    0        |

|            3 | Nine days old                          |    0        |

|            4 | Some like it hot,some like it cold     |    0        |

|            5 | Some like it the pot                   |    0        |

|            6 | Nine days old                          |    0        |

+--------------+----------------------------------------+-------------+

短语查找（注意要加上引号，不然查询结果是不正确的）

test> SELECT * from fts_a where  match(body) against(‘"days old"‘ in boolean mode)  ;

+--------------+---------------+

|   FTS_DOC_ID | body          |

|--------------+---------------|

|            3 | Nine days old |

|            6 | Nine days old |

+--------------+---------------+

3、Query Expansion

参见姜的书上Page247-248

官方文档：https://dev.mysql.com/doc/refman/5.6/en/fulltext-query-expansion.html

时间： 2024-11-08 21:44:32

InnoDB全文索引基础的相关文章

InnoDB全文索引停止词（stopwords）设计的缺陷

全文索引FULLTEXT首次运用在了InnoDB引擎上,最近在研究过程中发现停止词(stopwords)设计的缺陷. 何为停止词?就是指不想用户在搜索的时候能搜到'李洪志大师'.'法轮大法'等词汇,需要事先定义好停止词,这样就不会被搜索到.但设计的缺陷是,你必须事先就定义好,假如日后还想再定义停止词'活摘器官',必须重建一次全文索引,如果表很大的话,相当耗费时间. 下面我们看例子,截图如下: 结论:官方MySQL5.6.16和MariaDB10.0.10均有此缺陷,希望在后面的版本里,可以做调整

MySQL 5.7 innodb全文索引

由于模糊搜索的需求越来越多,所以在从库上创建全文索引来应付各种搜索需求.现在创建一个用户名的全文搜索,全表大小为1100W条记录左右. 1.表结构查询 mysql> desc ucenter_member; +------------------+------------------+------+-----+------------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------

MySQL内核：InnoDB存储引擎 卷1

MySQL内核:InnoDB存储引擎卷1(MySQL领域Oracle ACE专家力作,众多MySQL Oracle ACE力捧,深入MySQL数据库内核源码分析,InnoDB内核开发与优化必备宝典) 姜承尧 蒋鸿翔 饶珑辉 温正湖 著   ISBN 978-7-121-22908-4 2014年5月出版 定价:69.00元 360页 16开 编辑推荐 预售前100位读者送MySQL 5.6 InnoDB存储引擎的架构图 l  <高性能MySQL>配套深度阅读数据库内核解析篇 l  网易资深数据

MySQL全文索引 FULLTEXT索引和like的区别

1.概要 InnoDB引擎对FULLTEXT索引的支持是MySQL5.6新引入的特性,之前只有MyISAM引擎支持FULLTEXT索引.对于FULLTEXT索引的内容可以使用MATCH()-AGAINST语法进行查询. 为了在InnoDB驱动的表中使用FULLTEXT索引MySQL5.6引入了一些新的配置选项和INFORMATION_SCHEMA表.比如,为了监视一个FULLTEXT索引中文本处理过程的某一方面可以查询INNODB_FT_CONFIG,INNODB_FT_INDEX_TABLE,

全文索引的原理及定义

全文索引时将存储在数据库中的整本书或整篇文章中的任意内容信息查找出来的技术.它可以根据需要获取全文中有关章,节,段,句,词等信息,也可以进行各种统计和分析. 之前的MySQL数据库中,INNODB存储引擎并不支持全文索引技术,大多数的用户转向MyISAM存储引擎,不过这可能进行表的拆分,并需要将进行全文索引的数据存储为MyIsam表.这样的确能够解决逻辑业务的需求,但是却丧失了INNODB存储引擎的事务性,而这在生产环境应用中同样是非常关键的. 从INNODB1.2.x版本开始,INNODB存储

Servlet过滤器介绍之原理分析

zhangjunhd 的BLOG   写留言去学院学习发消息 加友情链接进家园 加好友 博客统计信息 51CTO博客之星 用户名:zhangjunhd文章数:110 评论数:858访问量:1923464无忧币:6720博客积分:6145博客等级:8注册日期:2007-02-03 热门专题更多>> Linux系统基础之菜鸟进阶 阅读量:2359 ARM驱动之Linux驱动程序设计入门 阅读量:2252 HTML5入门教程 阅读量:1392 深入浅出学MySQL 阅读量:1558 热门文章 基于T

mysql5.7新增参数配置解释

1:binlog_group_commit_sync_delay 全局动态变量,单位微妙,默认0,范围:0-1000000(1秒). 表示binlog提交后等待延迟多少时间再同步到磁盘,默认0,不延迟.设置延迟可以让多个事务在用一时刻提交,提高binlog组提交的并发数和效率,提高slave的吞吐量. 2:binlog_group_commit_sync_no_delay_count 全局动态变量,单位个数,默认0,范围:0-1000000. 表示等待延迟提交的最大事务数,如果上面参数的时间没到

xtrabackup 备份恢复测试过程

参考: http://blog.csdn.net/justdb/article/details/17054579# MySQL备份与恢复之percona-xtrabackup软件的使用 http://blog.csdn.net/justdb/article/details/17054667# MySQL备份与恢复之percona-xtrabackup实现增量备份及恢复 http://devliangel.blog.51cto.com/469347/1374232# 使用innobackupex在

[MySQL Reference Manual] 8 优化

8.优化 8.优化... 1 8.1 优化概述... 1 8.2 优化SQL语句... 1 8.2.1 优化SELECT语句... 1 8.2.1.1 SELECT语句的速度... 1 8.2.1.2 WHERE子句优化... 1 8.2.1.3 Range优化... 1 8.2.1.4 索引合并(Index Merge)优化... 1 8.2.1.5 引擎Pushdown条件优化... 1 8.2.1.6 索引条件Pushdown优化... 1 8.2.1.7 使用索引扩展... 1 8.2.