@老虎会游泳，噢，索引应该存的是页号，直接拿到行记录数据，里面也有主键ID了

@老虎会游泳，那看来，页分裂的代价很大啊，要重写很多索引的页号

@无名啊，如果帖子内容的长度会影响插入和查询的性能，虎绿林早就感知强烈了。

@老虎会游泳，我一直以为查索引拿主键ID，再去拿实际数据来着

@老虎会游泳，索引表一行记录的结构，也是变长字段长度, 记录头信息, 事务ID, 回滚指针, 列1, 列2, ...吗？

@无名啊，不要套用不了解的名词。比如我很简单就能想到该怎么进行高效更新（我不了解MySQL是怎么做的，但是如果是我，我会选择这样做）：

1. 始终保持一行的记录在页中连续。
2. 如果原始位置存不下修改后的数据，就把整行移到末尾空闲页。这样只需要修改两个索引里的两个位置记录而已。
3. 建立一个闲置记录列表，如果以后新插入的数据足够放在步骤2产生的闲置空间，就放进去。

这样就完全不需要进行大范围数据移动了。

@老虎会游泳，我只是很奇怪，为啥B表300W数据性能就下降了，会不会是索引字段过长（主要是那wxid）

@无名啊，我不了解你所说的名词，我不掌握MySQL的内部数据结构。但既然我能想到代价低廉的数据更新方法，MySQL开发者肯定更能想到。所以我相信他们做了正确的决定，实现了非索引数据长度和索引查询性能无关。

@老虎会游泳，我也不了解记录头信息, 事务ID, 回滚指针（都是今天刚查的），只需要它们的长度即可

@老虎会游泳，还有，为何盛传MySQL单表不要超过2KW行？是索引表的B+树变4层了？

@无名啊，index(uid, type, wxid)索引规模增长（层数变高）导致查询性能下降是完全有可能的。但是这只和uid, type, wxid这三个字段有关系啊，和extend这样完全不在索引里的字段有什么关系呢？

而且我们其实不知道@大尨 创建了什么样的索引，也许@大尨 应该告诉我们一下。

@无名啊，盛传MySQL单表不要超过2KW行

做为主键的自增id通常是4字节，你可以计算一下2KW行的索引高度。

@老虎会游泳，已承认走索引时和extend等非索引字段无关，是我想错了查询过程

以为：查索引→拿主键→查数据表（此时和extend等非索引字段有关）→拿数据
实际：查索引→拿页号→拿数据

@老虎会游泳，我算算

另外，B表不要自增id，直接把uid, type, wxid作为主键，会咋样？

@无名啊，你就没有想过，主键也是一个索引，所以也可以像其他索引一样处理，找到主键后就直接找到数据的存储位置吗？

因为MySQL的主键类型默认并不是聚簇索引啊，数据的存放位置和主键无关啊。主键的树里应该只有主键本身，以及数据在磁盘的位置而已，就和其他索引一样。

@老虎会游泳，我想问，反正都要走index(uid, type, wxid)拿到行记录所在页号，进而拿到数据，

为何不直接一步到位，将uid, type, wxid作为主键，还少了维护多一个索引的代价

@无名啊，@大尨 说这是日志表，所以同一个用户也可以多次交易啊，所以index(uid, type, wxid)并不唯一。
但是对于索引来说，这只是叶结点里面对应的记录变多了而已，并不会导致索引层数增加。

@老虎会游泳，

所以index(uid, type, wxid)并不唯一

@大尨 在14楼说：

现在从A表查询一条 status=0 的记录 wxid 出来 拿到 B表 以 uid type wxid 作为条件查询是否存在

在10楼说：

再拿这条数据去 B 表 查询这个业务跟这条记录是否存在。存在就重新取一条数据继续判断。不存在就添加进B表做记录

应该是不允许重复的

@无名啊，如果不允许重复，那么他确实可以用来做主键。