Ваше основное предположение верно только в том случае, если у вас есть таблица только для записи (или, по крайней мере, только для обновления).Если вы удаляете записи, PK для новых записей будут вставлены не последовательно (физически).
Эффективность вставок в индекс почти всегда является второстепенным фактором, а возмущение этим является антипаттерном преждевременной оптимизации.Рассматривали ли вы, как правило, более существенные проблемы кардинальности, длины ключевых полей, размеров кэша и т. Д.?
Использование суррогатных автоинкрементов в первую очередь обычно неоптимально - обычно есть более полезный уникальный ключ с реальными значениями, которыекластер в более значимых отношениях.(И вы можете кластеризовать только таблицы innodb - вы это понимаете, верно?)
«Кластеризация» означает, что индекс по существу - это таблица.Так что это выгодно при вставке суррогатного ключа, потому что все добавляется в конец таблицы, потому что следующее значение индекса всегда выше, чем любое предыдущее (как вы уже знаете).
Если вы не заполняете дырысозданный удаленными записями.Это может происходить косвенно, но может быть связано с дополнительными затратами, поскольку необходимо перемещать целые записи, что, очевидно, требует больше усилий, чем просто перемещение значений и указателей ключа индекса.
Кластерные записи не дают большого преимущества для запросов для одногозаписей столько же, сколько для диапазонов записей (например, элементов для заказа, клиента, пользователя. Если вы, например, можете выбрать несколько (или несколько сотен) записей для одного и того же пользователя, для которого стоит кластеризоваться. Это гораздо менее вероятночто записи будут вставляться непрерывно для одного пользователя (в большинстве сценариев), поэтому кластеризация в хронологическом порядке не очень помогает, но ваши требования могут отличаться.
Вы не указали innodb, поэтому я ответил в первую очередьдля myisam (по умолчанию), где только автоинкремент или хронологический индекс будут симулировать кластеризацию - явной опции нет.