索引键的长度对查询性能的影响

先看数据表

其中红色框圈住的是新加的字段以及索引

这张表的主要作用是，存储每种类型的doc的操作日志，用于审计用。其中每个doc_type_name代表某种类型的实体，而doc_id则是这个实体在对应的表里的主键ID。

由于admin有分页的需求，因此这张表的一种查询case是

select count(id) from slow_query_tmp_tbl where doc_type_name='biz_prefix_hot_search_keyword'.

LIVE环境这个sql语句命中了120w+行，耗时偶尔会超过500ms，超过了数据库读超时设定的500ms限制，直接导致接口报错。

我们需要在测试环境分析这个问题，上图是的数据情况，LIVE环境的数据更多一些（表里总数据行数2kw+），不过由于测试环境的MySQL数据库服务器性能更糟糕，因此测试环境可以用来分析问题以及优化方案。

有个背景信息需要说下，就是doc_type_name和doc_type_code一一对应。最初这张表里没有idx_doc_type_code_and_id这个索引，也没有doc_type_code字段。

毫无疑问，最初这张表的设计是不合理的。

我们首先Explain下这个语句：

1. 我们可以看到，key_len=258(尽管我们用的是varchar(64)，但是数据库引擎为索引键分配了定长的存储空间)，这说明这个索引的效率并不高。

2. 这张表的查询场景决定了，应该建一个联合索引(doc_type_name, doc_id)，因为这样适用于两种查询：一是同时制定了doc_type_name和doc_id，另外一个是仅仅指定了doc_type_name。

3. 数据库查询只可能使用一个索引加速（表的创建者可能没有意识到这一点）。

3. 如果进一步优化，这张表应该维护一个联合索引足够idx_doc_type_code_and_id(doc_type_code, doc_id)，先别提主键。因为我们创建索引时，应该尽量让索引的key的长度足够短，提高索引效率。