Индексы бюджетной базы

Про индексы было тут:
http://akostina76.ucoz.ru/blog/2018-07-27-5251

А теперь про странности. Расходные платёжки и меня выбираются таким запросом:

Из документов тут только две таблицы. ZF_R – сами платёжки. В этой таблице есть сумма. DOC – список документов. В этой таблице, например, хранятся все даты. Все остальные прицепленные таблицы  - справочники классификаторы.
Основная часть КБК прицеплена к таблице K_LSR – список счетов расходов. Раньше там были все характеристики, а теперь там раздел и экономическая статья распорядителя. Те же данные по учреждениям теперь хранятся в списке платежек ZF_R.
Я не знаю когда это начало медленно работать. Меня поставили перед фатом и я решила что просто база очень большая и залила информацию за первые месяцы в базу чтобы копировать каждый день только последние документы.
На прошлой неделе кроме медленной работы были какие-то странности. Вылезло задвоение документов. Предположение, что какие-то проблемы с индексами излишне смелое потому я очень удивилась но решила вопрос со своей стороны.
В пятницу слив информации вылез за 10 минут и превысил таймаут. Одновременно стало известно что им, оказывается в выборке надо не дату утверждения в месяц. Я поменяла в запросе дату на месяц и всё начало работать за секунды. Я решила, что дата какая-то неудачная попалась и по конкретно этой не было индекса.
В понедельник утром оно сделало то же самое, т.е отработало столь медленно что перестало заливаться.
При этом выборка только из документов (ZF_R + DOC) отрабатывает почти мгновенно. Сейчас у меня перекачены себе все нужные справочники классификаторы (которые начинаются с «K_»). Сливается информация из ZF_R+DOC и к ней уже цепляются данные из скаченных себе справочников.

Предположение о том, что что-то с индексами по-прежнему очень смелое, но других у меня нет. В DOS-овские временя индексы к DBF хранились в отдельных файлах, периодически ломались и их иногда даже чисто профилактически пересоздавали. Проблем с поиском ни в Accces-е ни, тем более, в SQL Server-е не видела не разу, но команда ReIndex (переиндексация) там есть. Видимо очень редко но с ними тоже что-то случатся.
Такое ощущение, что сломался индекс какого-то справочника. Во-первых, сами документы вытаскиваются быстро. Медленно работает только при подключении справочников. Во-вторых, при такой выборке задвоение может означать что в каком-то из справочников есть две записи с одинаковым идентификатором.
Вообще-то, этого не может быть потому что не может быть никогда. В элементарно грамотно написанных базах у всех таблиц есть так называемый первичный ключ:

Он обычно создаётся в момент создания таблицы. Это индекс по тому самому основному идентификатору строки, позволяющий точно и быстро находить конкретную строку. Идентификатор (ничего не значащая цифра для внутреннего использования типа K_CSID, K_VRID) обычно создаётся самим сервером при вводе новой строки. Сервер же следит за тем чтобы там не было задвоений этих идентификаторов. Чтобы что-то задвоилось надо отключить этот ключ и вести в таблицу информацию. Что происходит при ломаном индексе я, естественно, не знаю.
Если с каким-то первичным индексом справочников проблема, то на каждой строке выборки информация из этого справочника вытаскивается простым перебором (на самом деле вообще непонятно как он вытаскивает в этом случае). Все справочники небольшие потому это смешная задержка. А вот платёжек очень много, потому может быть такой результат.
Если же там всё в порядке и просто данных очень много, то получается что довольно спорный и, вообще-то, не рекомендуемый метод поэтапной выборки (вначале документы выбрать, потом к этому набору справочники прицепить) в некоторых случаях работает быстрее обычной SQL-строки. Я бы так и решила если бы быстро работавшее в пятницу не перестало работать в понедельник. Не могли столько информации за выходные навводить.