Dimitry Sibiryakov, нет. max(id) не используется для генерации чего либо. Это всего-лишь способ получения информации для репликатора. И тестируется все это в многопользовательской среде. Если у тебя есть конкретные идеи, как это может не сработать - сообщай, буду вникать и думать )

Эх. Тема ушла далеко в оффтоп. Особенно радуют советы про гарантированные проблемы с max(id), с учетом того, что советчики не знают как оно там устроено. Сегодня попробую сменить направление у индексов для pk и fk.

kdv, максимально просто )

Только что попробовал pk и fk с убывающими индексами. Ничего не упало, диск с: не отформатировался, а за окном не пошёл зелёный снег, как можно было бы ожидать из ответов в этой теме... )

База с pk и fk с убывающими индексами за ночь немного заполнилась тестовыми данными. В итоге получилось не то, что я ожидал. Для примера запрос


(где 20000000000-24999999999 - диапазон pk, в котором создаёт свои записи филиал №2) на "непрогретой" базе выполняется 12 минут :( На прогретой- 0.3 сек, но это всё равно медленно. А ведь в таблице только 100 млн записей, что в 10 раз меньше наполнения за год.

В итоге переделал наподобие того, как советовал Симонов Денис:
create table t (
tablename char(31) not null,
source_db char(31) not null,
last_id bigint
)

Наверное на этом пока и успокоюсь :)

Вот блин, отказался от desc-индексов для pk в базе и рубль начал падать. Звиняйте )))