@无名啊，你在75楼的计算应该是正确的，看起来非索引数据的长度确实会影响INNODB主键B+树的层数。INNODB默认使用主键进行聚簇索引存储。

@大尨，78楼，三个 key，是额外建立了3个索引？不知道MySQL会不会根据每个索引辨识度（count(*) / count(distinct uid或type或wxid)）来选择用哪个索引

@大尨，

KEY `uid` (`uid`,`type`,`appid`)

--该索引在以下查询中效果最好：
where uid=? and type=? and appid=?
--在以下查询中可以发挥作用
where uid=? and type=?
where uid=?

   KEY `uid` (`uid`),
   KEY `type` (`type`),
   KEY `wxid` (`wxid`)

-- 这是三个索引，第一个仅能用于
where uid=?
where uid=? and ...
-- 第二个仅能用于
where type=?
where type=? and ...
-- 第三个仅能用于
where wxid=?
where wxid=? and ...

-- 那么对于以下查询，会用到上述哪个索引
where uid=? and type=? and wxid=?
-- 答案是不知道，但肯定只能任选其一，三个索引不能同时发挥作用，因为它们互相之间没有关系
-- 如果想针对这个查询进行优化，可以考虑创建以下索引
key `xxx`(uid, type, wxid)
-- 或者如果你认为相同uid的wxid较少，还可以只创建以下索引
key `xxx`(uid, type)

@老虎会游泳，

非索引数据的长度确实会影响INNODB主键B+树的层数

嗯，是这个意思

你在75楼的计算应该是正确的

好像不正确，因为那是假设“B表用自增ID做主键。uid, type, wxid走索引取主键ID，再取行记录页号，再取数据，导致300W行后变为4层B+树”所计算出来的extend长度

但如你所说，实际是“uid, type, wxid走索引取页号，再取数据”

所以我很好奇，300W数据的索引，就变为4层B+树了？

可惜我没查到索引叶子结构长啥样，否则可以算一算

@无名啊，这篇文章赞同了你的观点

https://blog.csdn.net/dieaixia5129/article/details/122322502

非聚簇索引
InnoDB中，除了聚簇索引以外，其余的索引都可以称为非聚簇索引，非聚簇索引的叶子节点存放主键索引，而不是所有数据。通过非聚簇索引查找数据，其流程是先通过非聚簇索引查找到数据的主键，再通过主键查找对应的数据。

@老虎会游泳，？？？到底索引存主键ID，还是存页号？？？

@无名啊，

https://blog.csdn.net/fengyuyeguirenenen/article/details/122797873

1、MyISAM存储引擎的非主键索引与InnoDB存储引擎的非主键索引数据结构是一样的，但是最底层叶节点存储的数据和指针信息是不同的。

MyISAM存储引擎的非主键索引最底层叶节点存储的是索引信息及数据指向文件的指针信息。

InnoDB存储引擎的非主键索引最底层叶节点存储的是索引信息及指向主键索引的指针信息。

2、MyISAM存储引擎的数据文件跟索引文件是两个文件。InnoDB存储引擎的数据文件跟索引文件是一个文件。所以找到了主键索引位置也就找到了数据位置。所以InnoDB主键索引被称为聚合索引。

所以是我搞错了，我所描述的是MyISAM的情况，你所描述的才是InnoDB的情况。

@老虎会游泳，我说清楚一下，我上述单独出现的索引，皆指“非聚簇索引”

所以，INNODB的非聚簇索引，都是存主键ID？

@无名啊，看起来是的。

@老虎会游泳，那@大尨 300W后就卡，似乎就解释的通了

@老虎会游泳，其实我觉得，非聚簇索引存页号，更精妙。。

是不是数据页（叶节点）分裂起来，更新索引里的页号有压力（要更新可能几十成百上千个行记录的页号，就看一个数据页能存多少行数据了）。。

@无名啊，我比你更不了解InnoDB，看起来我无法回答此类问题。

@老虎会游泳，不对，我又想错了，自增ID，数据页为嘛要经常分裂？？

我想成uid, type, wxid作为主键，导致随机插入时要经常分裂了

那75楼又要重新算了。。懒得算了，extend差不多是2~3KB这样吧

@老虎会游泳，别，我很多是今天刚查的

@大尨，可以用以下SQL显示表的统计数据

show table status like 'hu60_bbs_topic_content'

@无名啊，虎绿林的行大小还是太小了，数据量还没有达到让树变高的程度，所以我才感知不强

@老虎会游泳，应该是，那种大型论坛才成天喊着分库分表

@无名啊，我确实没想到非索引数据的长度居然和主键查询性能有关系。这确实颠覆了我对数据库的直觉。

这篇文章也解决了我的另一个疑惑：为什么有时InnoDB的count(*)操作特别慢，甚至可以触发MySQL死锁。原来需要进行全表扫描

https://blog.csdn.net/qq_35642036/article/details/82820178