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