假设:在聚集索引的情况下，磁盘上记录的顺序与聚集索引的顺序相同。
问题:每次插入新记录时，磁盘上的数据是否都会重新排列？这不是对磁盘上执行数据移动的性能造成很大影响吗？
MySQL 的即兴创作:每个索引页都有一个保留空间，即索引页中保留空间的 1/16 以供将来更新。
我的问题:当这个空间(保留空间)耗尽并且新记录正在等待写入时会发生什么？这是否会重新排列该索引页之后的所有数据以适应这条新记录？这不是对演出影响很大吗？如果是，可能的解决方法是什么？
一些额外的引用:这是否直接映射到操作系统处理内部碎片的方式，并且文件系统尝试将与同一文件对应的所有 block 尽可能靠近地存储在磁盘上以节省磁盘寻道时间？ 如果可能的话，是否有解释这两者是否相关以及如何相关？
我在 SQL query slow because of clustered index 的帖子 ( Gary Mcgill ) 中找到了答案在这方面非常有帮助。
最佳答案
是的，使用聚集索引并在中间插入一些东西会造成很大的损失。这就是为什么只有在以线性方式插入时才必须小心使用聚集索引的原因，因此对于 AUTO_INCRMENT ID 和其他列，在最后一行“之前”插入行的情况并不常见......
我遇到的一个有趣的情况是，当 ID 字段使用两个字符前缀和一个连续数字构建时...数字部分本身就是一个很好的候选者，但是使用两个字母前缀，插入 ZZ1234 和 AA1235 导致出现问题。
可能的解决方法:当情况不合适时，重组索引不使用聚集索引。
Does this directly map to the way an operating system handles internal fragmentation and the file system tries to have all the blocks corresponding to the same file stored as close as possible on the disk to save on the disk seek time?
我认为这些没有直接联系。在某些 DBMS 中，可以让 DBMS 完全控制 block 设备，并且没有操作系统层影响磁盘/SSD/其他数据上的布局...
关于mysql - 使用聚集索引重新排列表中的记录，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13156510/