InnoDB无法找到行疑似索引损坏？MariaDB 10.1.18异常咨询
这种查不到主键行但能通过其他列查到、更新后恢复的诡异问题，我在维护老版本MariaDB时碰到过好几次，结合10.1.18的InnoDB特性，主要是这几个方向的问题：
1. 聚簇索引与二级索引数据不一致
InnoDB的主键（你的id列）是聚簇索引，所有二级索引都会指向聚簇索引的记录。如果遇到突然断电、磁盘IO故障，或者版本本身的bug，可能导致聚簇索引和二级索引的存储数据出现偏差——比如二级索引还保留着id=1的指向，但聚簇索引的这条记录在缓存或磁盘上出现了逻辑损坏。
执行无意义的更新操作时，InnoDB会重新写入这条记录的聚簇索引和所有关联的二级索引，相当于强制同步了索引数据，所以之后两种查询都能正常返回结果。
排查与修复方法：
- 用
CHECK TABLE your_table_name EXTENDED;命令检查表和索引的一致性，这个命令会深度校验数据和索引的匹配度 - 定期执行
OPTIMIZE TABLE your_table_name;重建表和索引（注意：这个操作会锁表，建议在业务低峰期执行）
2. MariaDB 10.1.x版本的InnoDB快照/缓存bug
10.1系列是比较老旧的分支，10.1.18本身存在一些已知的InnoDB查询异常bug——比如事务快照读时，缓冲池中的数据没有正确刷新，导致主键查询读取了过期的快照，而二级索引查询走了不同的缓存路径。
这类bug大多在10.1系列的后续小版本（比如10.1.48及以后）被修复了，如果你还在使用10.1.18，升级到同分支的最新版本会大概率避免这类问题。
3. 事务隔离级别导致的快照异常
如果当时有未提交的长事务在操作这条id=1的记录，可能导致当前查询的事务快照无法读取到最新的数据，但二级索引的快照逻辑不同，所以能查到记录。不过这种情况相对少见，因为长事务的影响通常更持续，不会只在主键查询中出现。
你可以通过SHOW ENGINE INNODB STATUS;查看当时的事务状态，检查是否有长时间未提交的事务持有行锁或影响快照读。
总的来说，这种临时异常本质是InnoDB的索引或数据快照出现了一致性偏差，更新操作触发了数据的强制同步从而修复问题。最稳妥的长期解决方案是升级到更稳定的MariaDB版本（比如10.4+），同时避免服务器异常断电、磁盘IO过载等可能破坏数据一致性的场景。
内容的提问来源于stack exchange，提问作者Tobia
