Случайные UUID убивают производительность базы данных.

Ты перешел с целочисленных ID (1, 2, 3…) на UUID (a1b2-3c4d-…) ради безопасности или распределенной генерации.

И вдруг записи в БД стали медленнее. Иногда намного.

Вот почему.

Фрагментация индексов.

Большинство индексов в БД это B-Tree (сбалансированные отсортированные деревья). Физическое расположение данных имеет значение.

1. Последовательные ID

Когда ты вставляешь последовательные числа (1, 2, 3), новые записи всегда попадают в самый правый лист индекса.

Записи предсказуемые и последовательные.
Максимальные cache hit’ы.
Страницы индекса остаются заполненными на 100%.

Это максимальная скорость, на которую способна твоя база.

2. Случайные UUIDv4

UUIDv4 равномерно случайные. Это значит, что каждая новая вставка может попасть в любое место дерева.

Из-за этого:

-» База постоянно подгружает случайные страницы с диска в память (random I/O).

-» Page split. Если целевая страница заполнена, БД вынуждена делить ее пополам, в итоге получаются две полупустые страницы.

-» Эффект швейцарского сыра. Индекс раздувается и заполняется дырками, зря тратя RAM и место на диске.

-» Когда размер индекса превышает объем доступной памяти, пропускная способность на запись может просесть на 20–90%.

3. UUIDv7

Перестань использовать UUIDv4 в качестве primary key. Используй UUIDv7 (стандартизирован в RFC 9562).

UUIDv7 содержит таймстемп в начале ID, поэтому он сортируемый.

В итоге ты получаешь лучшее из двух миров:

-» Распределенная генерация, без центрального счетчика.

-» Монотонные вставки. В B-Tree они ведут себя почти как последовательные числа, без фрагментации.

-» Безопасность. Нельзя просто угадать ID (атакующий не узнает, что пользователь 101 идет сразу после 100), хотя стоит учитывать, что время создания записи становится видно.

Итог простой: ты сохраняешь удобство UUID и избавляешься от перфоманс-потерь.

👉 Java Portal

Совет по Spring Boot: используйте TaskScheduler для реализации лёгких динамических задач. Для более сложных сценариев лучше смотреть в сторону Quartz.

Инжектим и используем:

@Autowired
TaskScheduler scheduler;

scheduler.schedule(
    () -> System.out.println("Hello!"),
    new CronTrigger("0 */5 * * * *") // каждые 5 минут
);

Инжектируемый бин — это ThreadPoolTaskScheduler, встроенная реализация сразу TaskScheduler и ScheduledExecutorService

При необходимости конфигурацию можно кастомизировать:

@Configuration
@EnableScheduling
public class SchedulerConfig {

    @Bean
    public TaskScheduler taskScheduler() {
        ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
        scheduler.setPoolSize(5);
        scheduler.setThreadNamePrefix("my-scheduler-");
        scheduler.initialize();
        return scheduler;
    }
}

👉 Java Portal