Какие подводные камни могут быть, если все PK и FK в базе будут созданы с указанием использования DESC-индекса?

Для быстрого select max(some_pk) ...

kvd, погоди. Это пока еще нормальные вопросы :-)

Симонов Денис, самодельный репликатор, написанный за один день "на коленке", чтобы реплицировать данные между "филиалами" и центральной базой, использует такие запросы. На очень больших таблицах (порядка миллиарда записей) начинаются тормоза. А если учесть, что данные должны реплицироваться каждые 10(!) секунд, то вообще все грустно... Можно было бы написать его по-нормальному или задействовать готовый, но уже нету времени, т.к. внедрение системы должно вот-вот должно начаться. Поэтому ищу наиболее быстрые решения.

Мимопроходящий, требования не я придумывал. Мое дело маленькое - сделать так, чтобы работало как нужно людям. Можно время между репликациями увеличить и до минуты, но пользователи центральной базы хотят видеть, что происходит в "филиалах" как можно быстрее

Симонов Денис, да так и есть. Репликация была сделана методом, который первый пришел в голову. Таблицы логов хранят только инфу об update и delete. Информация о новых записях получается путем сравнения максимальных значений ключевых полей. В общем-то все работает без сбоев, но проверка на большой сгенерированной базе показала тормоза.

Так что в итоге? Внутренности репликатора обсудили. А что насчет вопроса в первом сообщении темы?

kdv, я тебе объяснил ситуацию. Я со всем согласен, но из-за недостатка времени меня интересуют очень быстрые решения. И самое простое решение в том, чтобы индексы по PK были убывающие (ну и соответственно по FK тоже, т.к. об этом предупреждается в документации). В этом случае max(pk) отрабатывает очень быстро.
Так вот, повторюсь: я не получу проблемы с такими индексам?

Для многопользовательской среды там все учтено. Проблем с max(id) быть не может. В каждый момент может быть только одна транзакция репликатора в базе.
Так что там с убывающими индексами для pk и fk? Может мне хоть кто-нибудь ответить?

Симонов Денис, да таблица одна на всех. И у нее есть id, максимальное значение которого сохраняется и используется репликатором. Но ней не хранятся данные о вставленных записях. Только об удаленных и измененных.

Dimitry Sibiryakov, я бы просто создал отдельный индекс, но для таблицы-миллиардника иметь два индекса по bigint-полю - это расточительство с точки зрения оптимальности импользования кэша :-)

Симонов Денис, ну во первых, работает это как я ожидаю. Это тебе не "эмуляция" генераторов через max(id)+1 :-)
А во вторых, у меня и так уже ожидаются две таблицы с заполнением более 500 млн. строк в год. Иметь еще одну гигантскую таблицу с логами мне не хочется. Хотя ее можно периодически подчищать, но сейчас из-за недостатка времени мне хочется иметь максимально простое решение.

fd00ch, я тоже надеюсь, что их нет. Но ответы в этом форуме заставили призадуматься... :-)

Симонов Денис, уже думал об этом. Это я сделаю в случае, если будут косяки или тормоза с убывающими индексами по pk.