将字符串列存储在索引中是否切实可行?

gaR*_*Rex 11 mysql indexing innodb

假设我们有这个示例结构/数据:

@see在http://sqlfiddle.com/#!8/1f85e/1小提琴

-- SET GLOBAL innodb_file_per_table=1;
DROP TABLE IF EXISTS mysql_index_reading_myisam;
CREATE TABLE IF NOT EXISTS mysql_index_reading_myisam (
    id INT NOT NULL AUTO_INCREMENT
  , str VARCHAR(50) NOT NULL
  , enm ENUM('thatis', 'thequestion') NOT NULL
  , cnt TINYINT NOT NULL

  , PRIMARY KEY (id)
  , INDEX str_cnt (str, cnt)
  , INDEX enm_cnt (enm, cnt)

) ENGINE=MyISAM CHARSET=Latin1;
INSERT INTO mysql_index_reading_myisam (str, enm, cnt) VALUES
    ('Tobeornottobe', 'Thatis', 1)
  , ('toBeornottobe', 'thatIs', 2)
  , ('tobeOrnottobe', 'ThatIs', 3)
  , ('tobeorNottobe', 'thatis', 4)
  , ('tobeornotTobe', 'THATIS', 5)
;
DROP TABLE IF EXISTS mysql_index_reading_innodb;
CREATE TABLE mysql_index_reading_innodb LIKE mysql_index_reading_myisam;
ALTER TABLE mysql_index_reading_innodb ENGINE InnoDB;
INSERT INTO mysql_index_reading_innodb SELECT * FROM mysql_index_reading_myisam;

EXPLAIN SELECT cnt FROM mysql_index_reading_myisam WHERE str = 'tobeornottobe';
EXPLAIN SELECT cnt FROM mysql_index_reading_innodb WHERE str = 'tobeornottobe';
EXPLAIN SELECT cnt FROM mysql_index_reading_myisam WHERE enm = 'thatis';
EXPLAIN SELECT cnt FROM mysql_index_reading_innodb WHERE enm = 'thatis';
Run Code Online (Sandbox Code Playgroud)

我们来看看它内部的存储方式

# egrep --ignore-case --only-matching --text '(tobeornottobe|thatis)' *
mysql_index_reading_innodb.frm:thatis
mysql_index_reading_innodb.ibd:Tobeornottobe
mysql_index_reading_innodb.ibd:toBeornottobe
mysql_index_reading_innodb.ibd:tobeOrnottobe
mysql_index_reading_innodb.ibd:tobeorNottobe
mysql_index_reading_innodb.ibd:tobeornotTobe
mysql_index_reading_innodb.ibd:Tobeornottobe
mysql_index_reading_innodb.ibd:toBeornottobe
mysql_index_reading_innodb.ibd:tobeOrnottobe
mysql_index_reading_innodb.ibd:tobeorNottobe
mysql_index_reading_innodb.ibd:tobeornotTobe
mysql_index_reading_myisam.frm:thatis
mysql_index_reading_myisam.MYD:Tobeornottobe
mysql_index_reading_myisam.MYD:toBeornottobe
mysql_index_reading_myisam.MYD:tobeOrnottobe
mysql_index_reading_myisam.MYD:tobeorNottobe
mysql_index_reading_myisam.MYD:tobeornotTobe
mysql_index_reading_myisam.MYI:Tobeornottobe
mysql_index_reading_myisam.MYI:toBeornottobe
Run Code Online (Sandbox Code Playgroud)
  • 在两个引擎中,枚举都存储在*.frm中.好.
  • 在两个引擎中存储数据和数据/索引文件的数据.好.
  • 在MyISAM索引中有两条记录.
  • 在InnoDB索引中,所有五个记录都是正确的.

我已经找到了什么

http://dev.mysql.com/doc/refman/5.1/en/mysql-indexes.html

在某些情况下,可以优化查询以在不咨询数据行的情况下检索值.如果查询仅使用表中的数字列并且形成某个键的最左前缀,则可以从索引树中检索所选值以获得更快的速度:

SELECT key_part3 FROM tbl_name WHERE key_part1 = 1

http://www.mysqlperformanceblog.com/2009/09/12/3-ways-mysql-uses-indexes/

使用索引读取数据某些存储引擎(包括MyISAM和Innodb)也可以使用索引来读取数据,从而避免读取行数据本身.这不仅仅是节省了每个索引条目有2个读取而不是一个,但在某些情况下它可以节省IO数量级 - 索引被排序(至少在页面边界上)所以进行索引范围扫描通常会得到许多索引条目相同的页面,但行本身可以分散在许多需要大量IO的页面上.最重要的是,如果你只需要访问几列,索引可以比数据小得多,这是覆盖索引有助于加速查询的原因之一,即使数据在内存中也是如此.如果MySQL只读取索引而不访问行,则会在EXPLAIN输出中看到"using index".

然后在sql_select.cc的源代码中:http://bazaar.launchpad.net/~mysql/mysql-server/5.1/view/head:/sql/sql_select.cc#L12834

/*
  We can remove binary fields and numerical fields except float,
  as float comparison isn't 100 % secure
  We have to keep normal strings to be able to check for end spaces
*/
if (field->binary() &&
    field->real_type() != MYSQL_TYPE_STRING &&
    field->real_type() != MYSQL_TYPE_VARCHAR &&
    (field->type() != MYSQL_TYPE_FLOAT || field->decimals() == 0))
{
  return !store_val_in_field(field, right_item, CHECK_FIELD_WARN);
}
Run Code Online (Sandbox Code Playgroud)

所以我的问题是

  1. 存储在索引字符串列中是否可行,只需要作为数据?例如,包含20列的表,我们经常需要strcolumn,由intcolumn搜索.创建像(intcolumn,strcolumn)这样的索引或者我们真的只需要(intcolumn)吗?

  2. innodb引擎中的mysql是否真的为检索数据做了一些额外的操作(当我们看到"使用where;使用索引"时)?

  3. ENUM也是如此.它发生了,因为Enum_field的real_type返回MYSQL_TYPE_STRING.枚举是否也这样做?

  4. 我们可以假设,枚举是超级邪恶的,我们应该总是使用简单的参考表吗?

  5. 对于MyISAM而言,它是不可取的,因为它存储在索引中而不是所有值.但那么为什么它会存储两个值 - 而不是一个?

  6. 如果这一切都真的发生了 - 它只是当前的mysql内核的重构,那不依赖于具体的处理程序实现吗?

ps:我看到这个问题是巨大的.如果有人帮助重新制定/打破它 - 这将是很好的.


Update1:​​添加另一个关于"使用索引"和"使用索引;使用where"的SQL

@see在http://sqlfiddle.com/#!8/3f287/2小提琴

DROP TABLE IF EXISTS tab;
CREATE TABLE IF NOT EXISTS tab (
    id INT NOT NULL AUTO_INCREMENT
  , num1 TINYINT NOT NULL
  , num2 TINYINT
  , str3 CHAR(1) NOT NULL

  , PRIMARY KEY (id)
  , INDEX num1_num2 (num1, num2)
  , INDEX num1_str3 (num1, str3)
  , INDEX num2_num1 (num2, num1)
  , INDEX str3_num1 (str3, num1)

) ENGINE=InnoDB;
INSERT INTO tab (num1, num2, str3) VALUES
    (1, 1, '1')
  , (2, 2, '2')
  , (3, 3, '3')
  , (4, 4, '4')
  , (5, 5, '5')
  , (6, 6, '6')
  , (7, 7, '7')
  , (8, 8, '8')
  , (9, 9, '9')
  , (0, 0, '0')
;
INSERT INTO tab (num1, num2, str3) SELECT num1, num2, str3 FROM tab;

-- Using index
EXPLAIN SELECT num2 FROM tab WHERE num1 =  5;
EXPLAIN SELECT str3 FROM tab WHERE num1 =  5;
-- Using where; Using index
EXPLAIN SELECT num1 FROM tab WHERE num2 =  5;
EXPLAIN SELECT num1 FROM tab WHERE str3 = '5';
Run Code Online (Sandbox Code Playgroud)

问题#2

  1. 为什么在没有null的情况下搜索我们只看到"使用索引"?

  2. 但是在可以为空的int OR字符串的情况下 - 我们也看到"使用where"?

  3. mysql做了哪些额外的操作?

egg*_*yal 7

  1. 存储在索引字符串列中是否可行,只需要作为数据?例如,包含20列的表,我们经常需要strcolumn,由intcolumn搜索.创建像(intcolumn,strcolumn)这样的索引或者我们真的只需要(intcolumn)吗?

    这被称为覆盖指数 ; 它具有能够从索引文件中检索所选列而不必从表数据中的记录中查找值的性能优势.

    与所有事物一样,它的使用是一种权衡,在某些情况下可能是适当的,但在其他情况下却不适用.

  2. innodb引擎中的mysql是否真的为检索数据做了一些额外的操作(当我们看到"使用where;使用索引"时)?

    您的问题链接显示Using where; Using index的所有四个查询的sqlfiddle .如EXPLAIN额外信息中所述:

    ExtraEXPLAIN输出包含MySQL解决查询的额外信息.以下列表说明了此列中可能出现的值.

    [ deletia ]
    • Using index

      仅使用索引树中的信息从表中检索列信息,而不必另外寻找读取实际行.当查询仅使用属于单个索引的列时,可以使用此策略.

      如果Extra列也说Using where,则表示索引用于执行键值的查找.如果没有Using where,优化器可能正在读取索引以避免读取数据行但不使用它进行查找.例如,如果索引是查询的覆盖索引,则优化器可以扫描它而不使用它进行查找.

    因此,无论使用何种存储引擎,您的所有查询都使用覆盖索引进行查找和数据检索.

    当你说" innodb引擎确实为检索数据做了一些额外的操作 "时,我不清楚你所指的是什么.EXPLAIN我可以看到输出的唯一区别是InnoDB查询在列中显示较低的Rows; 但是,据记载:

    rows列指示MySQL认为必须检查以执行查询的行数.

    对于InnoDB表格,此数字是估算值,可能并不总是准确的.

  3. ENUM也是如此.它发生了,因为Enum_field的real_type返回MYSQL_TYPE_STRING.枚举是否也这样做?

    同样,当你说" 同样的事情发生 " 时,我不清楚你所指的是什么.然而,如上所述,Using where; Using index仅表示覆盖索引已用于查找和数据检索.

    此外,ENUM领域都有real_typeMYSQL_TYPE_ENUM,没有MYSQL_TYPE_STRING.见sql/field.h:1873:

      enum_field_types real_type() const { return MYSQL_TYPE_ENUM; }
    
    Run Code Online (Sandbox Code Playgroud)
  4. 我们可以假设,枚举是超级邪恶的,我们应该总是使用简单的参考表吗?

    许多理由可以避免ENUM,但我认为你的问题没有触及其中的任何一个.

  5. 对于MyISAM而言,它是不可取的,因为它存储在索引中而不是所有值.但那么为什么它会存储两个值 - 而不是一个?

    egrep结果导致你画得出错误的结论.仅仅因为对模式的不区分大小写的搜索"tobeornottobe".myi文件找到两个匹配的字符串并不意味着MyISAM索引有两个记录.数据结构是一棵树,如下所示:

                  /\
                 /  \
    Tobeornottobe    toBeornottobe
                       /\
                      /  \
         tobeOrnottobe    tobeorNottobe
                           \
                            \
                             tobeornotTobe
    

    从查看所有字符串.myi索引文件中获得一个提示:

    $ strings mysql_index_reading_myisam.MYI
    Tobeornottobe
    toBeornottobe
    beOrnottobe
    orNottobe
    notTobe
    

    因此,如果您对模式执行(不区分大小写)搜索"nottobe",您将找到五个匹配而不是两个匹配.

    您可以在" .MYI文件"中阅读有关MyISAM索引结构的存储格式的更多信息.

  6. 如果这一切都真的发生了 - 它只是当前的mysql内核的重构,那不依赖于具体的处理程序实现吗?

    我担心我不知道这里有什么问题.