Може коли вставляємо наприклад на другу позицію,то просто оновлювати ідентифікатори,шляхом видалення старого AUTO_INCREMENTу поля і запуску нового (через SQL) ? Тоді всі поля наново пронумеруються по порядку.

Так вся суть задачі — уникнення перенумерування всіх полів, наскільки я розумію.

мені здається із вашим варіантом перегенеровувати прийдеться лише у випадку коли елемент будуть перетягувати в початок, якщо пересунуть в кінець то просто додати +16 до максимального значення яке знайдете.

а що заважає так само рухатись і в іншу сторону -2, -4, -6 ... ? тут взагалі не треба нічого перегенеровувати

хм, треба уберігтись від такого випадку

20
21
22

тобто може є сенс відсувати 20 в меншу сторону і 22 в більшу, тоді навантаження буде, але все ж таки менше ніж якщо всі перегенерювати

Хочу більше деталей. З чим саме працює користувач ? з інтерфейсом, який буде створений спеціально для користувача, чи він буде нагло лізти в базу власними запитами ?
В першому випадку це вирішується на етапі розробки інтерфейсу.
В другому - взагалі втрачає сенс.

А якщо так наприклад..

0
16
32
48

З 4 позиції на 2, з 48 на 16, то тримаємо числа в FLOAT і до 0 додаємо наприклад 0.0001 (INSERT даних) ,а 48 (DELETE) видаляємо.

Виходить
0
0.0001
16
32

З 2 на 3

0.0001 видаляємо
А 16 + 0.0001

0
16
16.0001
32

Те ж саме, ні? Float'ів рівно стільки ж, скільки й int'ів.

З float-ами теж думав (от тільки не 0.0001, ми не знаємо, куди полізе наступний елемент, тому просто середнє - між 20 і 21 буде 20.5). Але тоді треба буде епсилони ловити, що складніше, ніж одиниці.
До речі, тоді вже буде кращим вважати, що є два псевдоелементи INT_MIN та INT_MAX, які не виводяться і не зсуваються, але використовуються при обчисленнях середніх, при початковому вирівнюванні всі елементи розставляються рівномірно між ними, а при локальних перенумераціях шукаємо блок елементів розміром, що збільшується удвічі (4, 8, 16 і т.д.) з середньою щільністю хоча б удвічі більшою за середню щільність по масиву. Середня щільність - це кількість елементів, ділена на відстань між крайніми елементами.
Подумав, що по кількості елементів складно зробити запит, треба робити навпаки - у нас є два суміжні елементи, а має між ними бути відстань (в середньому по множині) n. Запитуємо, що робиться в їхньому околі довжиною n. Маємо там ще кілька елементів. Обчислюємо щільність, якщо влаштовує - впорядковуємо, якщо ні - збільшуємо окіл до 2*n і т.д. Але під час цього треба ще й блокувати таблицю... йой...

Вся сіль в тому, щоб при пересуванні рядка на іншу позицію,не чіпати решту записів взагалі (макс 2-3). Ви не зможете тримати ключі без змін при переміщенні (а потім сорт по ньому)
Така собі оптимізація при великих об'ємах даних.