MySQL：为什么我的索引长度是 0.0 字节？

Question

我有一个包含 4 列的简单表格。

A 栏 (int)、B 栏 (int)、C 栏 (int)、D 栏 (int)

我已经在（B 列、A 列、C 列）上构建了一个索引，它在性能方面运行良好。我的表包含 500 万行，使用索引选择所需的行可以立即生效（<0.00 秒）。

但是，在检查表时，我发现我的索引长度为 0.0 字节。为什么？我的索引怎么能完全不占用内存？

信息：

显示创建表 kpi_store_hour

CREATE TABLE kpi_store_hour( kpiIDint(11) NOT NULL, companyIDint(11) NOT NULL, timestampint(11) NOT NULL, valuefloat NOT NULL, PRIMARY KEY ( kpiID, companyID, timestamp) ) ENGINE=InnoDB DEFAULT CHARSET=utf8

显示表状态

名称：kpi_store_hour

引擎：InnoDB

版本：10

Row_format：紧凑

行数：4973952

平均行长度：95

数据长度：476037120

最大数据长度：0

索引长度：0

无数据：6291456

自动增量：NULL

创建时间：2015-03-04 11:14:06

更新时间：NULL

检查时间：NULL

整理：utf8_general_ci

校验和：NULL

SELECT * FROM kpi.kpi_store_hour WHERE kpiID = 0 AND companyID = 1 AND timestamp < 1353792707;

持续时间/获取：0.000 秒 / 0.000 秒

说明 SELECT * FROM kpi.kpi_store_hour WHERE kpiID = 0 AND companyID = 1 AND timestamp < 1353792707;

编号：1

选择类型：简单

表：kpi_store_hour

类型：范围

可能的键：主要

关键：主要

key_len: 12

参考： NULL

行数：743

额外：使用 where

Answer 1

在 InnoDB 中，PRIMARY KEY数据与数据“聚集在一起”。换句话说，数据存储在由 PK 排序的 BTree 中。由于两者（数据和 PK）共存，因此它们的大小以Data_length(476MB)计，而在Index_length. 如果您有任何“辅助”键，它们将被计入Index_length.

该表有 4 个 4 字节的字段，因此理论上一行应该只占用 16 个字节。注意Avg_row_length是 95。这是因为

• 每列的开销
• 每行的开销
• BTree 的开销
• 以及 PRIMARY KEY 的一些开销。

key_len: 12 -- 这意味着使用了 PK 中的 3 个 4 字节字段......

WHERE kpiID = 0 AND companyID = 1 AND timestamp < 1353792707可以使用 快速在 BTree 中向下钻取到第一行kpiID = 0 AND companyID = 1，然后扫描直到timestamp < 1353792707失败。并且估计会遇到 743 行。