假设：在聚集索引的情况下，磁盘上记录的顺序与聚集索引的顺序相同。
问题：每次插入新记录时，磁盘上的数据是否都会重新排列？这不是对在磁盘上执行数据移动的性能造成很大影响吗？
MySQL 的即兴创作：每个索引页都有一个保留空间，即为将来更新保留的索引页空间的 1/16。
我的问题：当这个空间（保留空间）用尽并且新记录等待写入时会发生什么？这是否会重新排列该索引页之后的所有数据以适应此新记录？这对表演不是很大吗？如果是，有哪些可能的解决方法？
一些额外的参考：这是否直接映射到操作系统处理内部碎片的方式，并且文件系统试图将与同一文件对应的所有块尽可能地存储在磁盘上以节省磁盘寻道时间？如果可能的话，如果两者相关以及如何相关，是否有解释？
我发现Gary Mcgill的帖子（由于聚集索引导致 SQL 查询缓慢）上的答案对此非常有帮助。
是的，使用聚集索引并在中间插入一些东西会很痛苦。这就是为什么只有在以线性方式插入时才必须小心使用聚集索引的原因，因此对于 AUTO_INCREMENT ID 和其他列，在最后一个“之前”插入行是不常见的......
我遇到的一个有趣的情况是，当 ID 字段是用两个字符前缀和一个序列号构造时......数字部分本身就是一个很好的候选者，但是有两个字母前缀，插入ZZ1234并AA1235导致一个问题。
可能的解决方法：当情况不适合时，重组索引以不使用集群。
这是否直接映射到操作系统处理内部碎片的方式，并且文件系统试图将与同一文件对应的所有块尽可能地存储在磁盘上以节省磁盘寻道时间？
我不认为这些是直接相关的。在某些 DBMS 中，可以让 DBMS 完全控制块设备，并且没有 OS 层影响磁盘/SSD/其他任何东西上的数据布局……