Ошибка структуры базы данных

Почему появляется ошибка?

Данная ошибка появляется в случае, когда структура базы данных не совпадает со структурой, расположенной в установочных sql-файлах. Обычно это возникает при установке обновлений.

На что эта ошибка влияет?

Как исправить ошибку?

Требуется наша помощь?

Специфика современных версий учетных программ обуславливается использованием многоуровневого кода. Логично, что чем сложнее структура — тем выше вероятность возникновения внеплановых ситуаций, с которыми приходится сталкиваться рядовым пользователям конфигурации. В отдельных случаях даже сотрудники администрирующих служб предприятия не всегда способны сразу определить исходную причину появления неполадок, поэтому работа по устранению неудобств может занять немало времени. Одной из наиболее часто встречающихся проблем является классическая ошибка SDBL 1С, источники и способы устранения которой мы и рассмотрим в сегодняшнем обзоре.

Общее представление

Взаимодействуя с учетной программой, пользователи выполняют различные операции, каждая из которых, так или иначе, формирует запрос к базе данных. Создание нового документа, интеграция библиотеки, плановое обновление — во время любого из процессов есть вероятность получить в ответ уведомление от системы, свидетельствующее о том, что одна из логических цепочек была нарушена. Распространенный вариант — когда на экране появляется сообщение об ошибке SDBL 1С ожидается выражение (pos = 6) (а также 15, 57, 198, 250, 469, или любой другой номерной идентификатор).

Фактически это говорит о наличии технического сбоя, с которым чаще всего сталкиваются пользователи, самостоятельно обновляющие конфигурацию автоматическими средствами. Важно понимать, что при работе с программой (и в том числе при установке новых релизов) необходимо иметь определенный уровень навыков и знаний, достаточный для внесения изменений и управления функциональными возможностями платформы.

Впрочем, сильно переживать не стоит. Появление ошибки SDBL 1С еще не значит, что структура базы данных предприятия разрушена полностью — в большинстве случаев исправить проблему можно при помощи стандартного набора способов, реализовать которые под силу даже начинающим пользователям.

Причины возникновения

Один из главных факторов, о котором многие забывают в процессе работы с учетной системой — необходимость соответствия платформы и конфигурации обновления. То есть перед тем как начать использовать новый релиз, нужно создать условия, в которых он сможет нормально функционировать. Простейший вариант — доверить контроль за установкой профильному специалисту, который поможет избежать технических сбоев в программе.

Если говорить об уже упомянутой ранее ошибке SDBL 1С «ожидается выражение (pos = 144)» (или 48, 153, 13 — не столь принципиально), то в этом случае ключевым обстоятельством становится повреждение базы данных, обусловленное нарушением системных логических циклов. К числу распространенных причин возникновения, отмечаемых специалистами, относят не только применение устаревшей конфигурации или платформы, но также и проблемы, связанные с серверным кешем. Кроме того, всегда существует вероятность случайного запуска с некорректной учетной записи, не обладающей достаточным набором прав.

Чаще всего системные ошибки происходят в процессе очередного обновления БД, а также при обращении к ней — через запрос на добавление документов, во время тестовой проверки логической целостности, или же в иных ситуациях. Критической проблемой при установке расширений может стать и «некорректное использование LOCAL/GLOBAL в SET GENERATION», не позволяющее полноценно сохранить базу даже после выборочного удаления. Стоит отметить, что стандартное решение в виде перезагрузки программы обычно не помогает, поэтому для восстановления работоспособности придется воспользоваться альтернативными методиками.

Какие сообщения возникают

Уведомление о технических неполадках отражает специфику возникшей проблемы, и может появиться как во время обновления конфигурации, так и в процессе работы с обменом данных. Как правило, текст в информационном окне раскрывает специфику возникшей ошибки SDBL 1С: «не является именем поля», «ожидается идентификатор» или «выход за пределы размерности результата 1C», и т. д.

Встречаются и вспомогательные приписки, причем их количество зависит от конкретной неточности, допущенной в ходе сборки и настройки обновленного расширения:

• предпринята попытка ввести неприемлемый тип значения «NULL»;

• пропущена точка с запятой;

• нарушение индексирования с полным текстом;

• неоднозначное определение некоторого поля;

• отсутствует выражение (pos =) — с различными числовыми идентификаторами в скобках.

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

Устранение ошибки SDBL 1С

Попытки справиться с возникающими проблемами самостоятельно не всегда заканчиваются одинаково успешно, поскольку в каждой отдельно взятой ситуации влияние оказывают разнообразные факторы — как в самой системе, так и за ее пределами.

В связи с этим главной рекомендацией специалистов является регулярное резервное копирование, позволяющее без особого труда восстановить исходные данные в случае наступления критических обстоятельств. Оптимальный график предусматривает не только ежедневное ночное создание копий, но также и дополнительное резервирование перед каждой значительной операцией, будь то обновление или закрытие периода. Автоматизированная архивация базы реализуется встроенным функционалом учетной программы, а восстановление из Конфигуратора занимает минимум времени, позволяя откатиться к рабочему состоянию практически без прерывания процесса.

Практически любая ошибка SDBL 1С — «недопустимый символ (pos = 40)», «пропущена точка с запятой», или «ожидается имя таблицы 21», может быть устранена путем выполнения несложного набора действий. Перечень доступных вариантов выглядит следующим образом:

1. Удаление кэшированных данных — как на пользовательском рабочем месте, так и на основном сервере, где произошел технический сбой. Для реализации процедуры очистки кэша достаточно закрыть учетную программу, открыть «Проводник», найти, выбрать и удалить набор папок из раздела «Application Data». Отличить нужные элементы проще всего по названию, которое выглядит как хаотичный набор символов — например, «ac5c8bm4-y65k-4s23-a9g8-2dcttp0b15da».

2. Использование функционала Конфигуратора, позволяющего провести тестирование и исправление информационной базы. В этом случае необходимо найти поврежденную ИБ, выбрать ее и перейти в раздел «Администрирование», после чего активировать встроенную функцию для теста и корректировки ошибок.

3. Перезагрузка сервера, на котором расположены программные приложения системы 1С. Самый простой вариант — включение и выключение всех взаимосвязанных SQL-сервисов, включая агент. Для выполнения задачи нужно зайти на нужный серверный источник, выделить агентскую службу, вызвать контекстное меню и остановить процесс. Аналогичные действия повторяем на SQL со служебными процедурами Server и Agent. Повторная активация осуществляется в обратном порядке.

4. Выгрузка БД в отдельный DT-файл с последующей повторной «заливкой». По сути, метод напоминает стандартную перезагрузку системы — структура записывается в файловом формате, что позволяет упорядочить проблемные разделы. Для выполнения процедуры достаточно открыть меню управления учетной программой, найти в категории «Администрирование» функцию «Выгрузить информационную базу», и после ее завершения выбрать опцию «Загрузить ИБ», используя сформированный файл.

5. Откат к последней резервной копии. Один из самых простых и доступных вариантов — конечно, в том случае, если архивирование данных проводится на регулярной основе, а не только перед закрытием периодов. Вообще, решение записывать текущее состояние перед каждым внесением изменений может избавить от большинства проблем, связанных с техническими сбоями. Даже если вы столкнетесь с уведомлением о том, что «ожидается имя поля», или получите ошибку «таблица 1С inforg не создана в новом поколении», источник которой не всегда понятен даже опытным пользователям — загрузка последней копии просто вернет систему к исходному состоянию. Для резервирования допускается использование как SQL MS, так и Конфигуратора учетной программы — через последовательную выгрузку файлов в уже упомянутом DT формате.

6. Обновление платформы через сайт информационно-технологического сопровождения разработчиков, доступный всем лицензированным пользователям продукта. Функционал портала ИТС позволяет установить последнюю редакцию, актуальную на момент обращения, инсталляция которой производится как на основной сервер, так и на рабочие места клиента.

Как правило, один из перечисленных методов позволяет добиться желаемого результата, устраняя проблему в работе учетной системы. В ситуациях, когда применить готовое решение так и не удалось, есть резервный вариант, отличающийся высокой вероятностью успешного исхода. Очистка в менеджере SQL 1С таблиц ConfigChngR и ExtProps, что за последние годы стало уже привычным способом восстановления для большинства специалистов, осуществляется стандартной командой Delete.

На что еще обратить внимание при устранении ошибок SDBL, и как реализовать рассмотренные методы? Сейчас разберемся.

Права доступа

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

Перезагрузка серверов 1С и SQL

Это один из простейших методов восстановления, единственным обязательным условием, для применения которого является выход всех пользователей из базы. Убедившись, что доступ открыт, зайдите на сервер и последовательно выключите агент программы Server и SQL-agent, после чего запустите их в обратном порядке.

Удаление кэшированных данных

Создание кэша представляет собой процесс буферизации информации, используемой базой чаще всего, и, как правило, относящейся к статичной категории. Кэширование позволяет ускорить программный цикл — так, если говорить об учетных системах, оптимизация затрагивает загрузку файлов конфигурации, исключая необходимость постоянного обращения к основному серверу. Однако на практике встречаются случаи некорректной обработки программным обеспечением подобных задач, что в конечном счете становится причиной неправильной работы платформы.

Перечень факторов, обуславливающих нарушение логических циклов, весьма обширен, и охватывает не только динамические обновления системной структуры, но и технические сбои программного или аппаратного характера. В некоторых случаях для устранения ошибки SDBL 1С «ожидается имя поля/таблицы (pos = 21, 45, 48…)» достаточно почистить кэш, сохраненный на сервере, либо на рабочем месте пользователя.

Стандартный путь к месту хранения кэшированных данных выглядит следующим образом:

• «%userprofile%AppDataRoaming1C1Cv8» и «%userprofile%AppDataLocal1C1Cv8» — для операционных систем начиная с Windows 7.

• «%userprofile%Local SettingsApplication Data1C1Cv8» и «%userprofile%Application Data1C1Cv8» — для тех, кто все еще продолжает работать на ХР.

Откройте каталог, расположенный по указанному адресу, выделите и удалите все хранящиеся в нем папки, имя которых представляет собой сгенерированный автоматически набор цифр и букв (вроде «abg7n8ty4-brt9r893-am…»). Стоит отметить, что во время чистки кэша нужно быть особенно внимательными, поскольку в директории также могут находиться поисковый индекс и журналы регистрации 1С, которые не требуют удаления.

Загрузка DT-файла

Этот метод может показаться немного странным, поскольку фактически не предполагает внесения каких-либо корректировок в основную структуру данных. Однако в действительности выгрузка БД в отдельный файл, сохраняемый в формате DT, с последующим обращением к ней же, нередко позволяет восстановить нормальную работу программы. Алгоритм достаточно прост — в режиме Конфигуратора нужно выбрать раздел «Администрирование», использовать опцию «Выгрузить ИБ» (указав каталог для сохранения), после чего повторно залить сформированную базу обратно в систему.

Тестирование и исправление

Еще одна удобная функция, доступная в режиме корректировки конфигурации — встроенный инструментарий, предназначенный для теста и внесения коррективов. В отдельных ситуациях может возникнуть проблема с запуском Конфигуратора — вместо этого можно воспользоваться специальной утилитой chdbfl.exe, представляющей собой упрощенный программный аналог с идентичным функционалом. Приложение находится в каталоге «bin», поэтому найти его не составляет особого труда — как через стандартный путь «C:Program Files (x86)1cv88.3bin», так и через опцию поиска, предлагаемую операционной системой.

Для использования программы достаточно указать расположение проблемной базы данных, и запустить цикл тестирования. При желании можно активировать опцию автоматического исправления выявленных ошибок — в противном случае утилита ограничится диагностикой, и сформирует перечень технических неполадок в отдельном реестре.

Обновление платформы

Еще одно простое решение, предусматривающее использование сайта технической поддержки разработчиков 1С. Скачайте дистрибутив актуального релиза, распакуйте архив и активируйте инсталлятор setup.exe — система обновится автоматически.

Очистка таблиц базы данных

Если ни один из вышеперечисленных способов не дал желаемого результата — остается вариант с удалением табличных значений БД, вызывающих появление ошибки, расположенных в каталогах ConfigChngR и ExtProps. Для этого применяется скрипт менеджера SQL, с указанием информационного раздела и командой delete from. В этом случае лучше всего обратиться к профильному специалисту, поскольку некорректное восстановление может привести к более серьезным последствиям.

Заключение

Автоматизация учетных процессов — важный аспект, позволяющий оптимизировать работу компании. Ошибки SDBL 1С встречаются достаточно часто, поэтому стоит заранее позаботиться об оперативном устранении возможных проблем. Мобильные решения, предлагаемые компанией «Клеверенс», гарантируют квалифицированную поддержку, а также помогут решить задачи, связанные с учетом данных на предприятии.

Количество показов: 7426

Способы исправления ошибок, выявленных при полном тестировании системы в 1С-Битрикс

php_value pcre.recursion_limit 100000

INDEX ix_module_to_module(FROM_MODULE_ID, MESSAGE_ID, TO_MODULE_ID, TO_CLASS, TO_METHOD)

INDEX ix_module_to_module(FROM_MODULE_ID(20), MESSAGE_ID(20), TO_MODULE_ID(20), TO_CLASS(20), TO_METHOD(20))

ALTER TABLE `b_user_hit_auth` MODIFY `TIMESTAMP_X` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP;

Koldun1

19.05.10 — 08:38

ну вот и приплыли,есть(или была) база на флэшке в NTFSом формате,работает с этой базой человека три,так вот не знаю что у них там произошло вчера(молчат как партизаны),запускаю базу просто щёлкаю мышкой в любое место вываливается месадж типа памяти недостаточно и все,в конфигураторе тоже самое говориться,запустил чекдб,нашел одну ошибку,мол DBSchema кривая,написано ошибка исправлена,запускаю снова базу и финиш Ошибка SDBL:Разрушена структура базы данных 1С:Предприятия. (pos=0) .чего курить?куда копать? сюда не отправлять http://www.gilev.ru/1c/81/restore/

Koldun1

1 — 19.05.10 — 08:40

а чуть не забыл :Зарплата и Управление Персоналом, редакция 2.5 (2.5.20.3) и 1С:Предприятие 8.1 (8.1.15.14)

Rie

2 — 19.05.10 — 08:40

(0) На флешке?
Прими соболезнования и больше так не делай.

Koldun1

3 — 19.05.10 — 08:41

вся ирония в том что именно вчера не был сделан бэкап,но почему?потому что флэшка на удаленном компе висит,но его умудрились выключить до того момента как начал делаться бэкап)))

Koldun1

4 — 19.05.10 — 08:42

на флэшке,а что это не лечиться?я не верю

Rie

5 — 19.05.10 — 08:43

(4) Не верь. У флешки — ограниченное число перезаписей. После этого она необратимо разрушается. База данных, с которой работают три человека (да даже и один), обеспечивает нужное число перезаписей быстро и надёжно.
Лечить нечего, флешка разрушена.

vde69

6 — 19.05.10 — 08:44

Koldun1

7 — 19.05.10 — 08:44

как так? флэшка работает нормально.я же базу сейчас себе перекачал на жестак и там все манипуляции выше описанные делал.

Rie

8 — 19.05.10 — 08:47

(7) Если «нормально работает» — то в чём проблема?
Когда с разрушенной флешки скачивается база, то разрушенные блоки выглядят как аккуратные многочисленные нули вместо данных. Но база — скачивается.

Koldun1

9 — 19.05.10 — 08:49

я говорю флэшка работатет,а база нет,а вообще изначально вопрос задан вот это лечиться Ошибка SDBL или нет?и чем?

Rie

10 — 19.05.10 — 08:51

(9) Попробуй выгрузить/загрузить.

vde69

11 — 19.05.10 — 08:55

Rie

12 — 19.05.10 — 08:57

(11) У меня?

Koldun1

13 — 19.05.10 — 08:57

vde69 а как лечиться, если не штатно?в общих чертах можно

vde69

14 — 19.05.10 — 08:58

Sekho

15 — 19.05.10 — 08:58

в каталоге BIN найди утилиту CHDBFL и протестируй свою базу — покажет на ошибки или удаленные записи. Первый раз делай только тестирование, и поймешь — что потерял.

vde69

16 — 19.05.10 — 08:59

(13) разбирать компаунд на отдельные таблицы и ковырять уже их, степень разрушения зависит от того какие таблицы нагнулись

Koldun1

17 — 19.05.10 — 09:01

Sekho я же выше написал,так и делал)
vde69 судя по всему накрылась DBSchema,а какими инструментами?мне эта тема интересна,может ссылок дадите что почитать?

Sekho

18 — 19.05.10 — 09:06

(17) сорри, упустил из виду

Sekho

19 — 19.05.10 — 09:07

+(18) ты тест на флешке делал или уже на жестком диске?

Koldun1

20 — 19.05.10 — 09:07

уже на жестком

Дикообразко

21 — 19.05.10 — 09:07

господи, этому баяну уже лет 8-9 …
именно тогда у меня друг одним из первых на это нарвался

Koldun1

22 — 19.05.10 — 09:08

Дикообразко подробней можно?

vde69

23 — 19.05.10 — 09:09

Дикообразко

24 — 19.05.10 — 09:09

да все уже рассказано в (5) но до тебя упорно не доходит

Koldun1

25 — 19.05.10 — 09:13

vde69, google по этому поводу выдает только рекламу,что вот заплати столько то и тд,в сети есть инфа только по 7.7,так что не надо мне тут про поиск,я прежде чем тему создавать,вначале поиск поюзал,просто никто не хочет делиться тем,чем он зарабатывает себе на хлеб(
Дикообразко,то что расказано выше противоречит тому,что говорит vde69…а я ему верю у него борода есть)восстановить можно и ради эксперимента я этим займусь,просто думал услышать толковых советов,от крутых спецов)))

Дикообразко

26 — 19.05.10 — 09:15

крутые спецы прежде чем что то делать — думают…
это сопляки вечно в дерьмо попадают, а потом геройски оттуда вылазят

Дикообразко

27 — 19.05.10 — 09:16

vde69

28 — 19.05.10 — 09:16

Koldun1

29 — 19.05.10 — 09:22

Дикообразко,к сожалению я не могу телепатически управлять пользователями)у меня тут и так есть куда попадать,кто ж теперь узнает кто выключил комп куда флэшка воткнута была,во время того как другие пользователи работали с базой?)
странно vde69 мне ссылчки дает,говорит что все возможно,а Дикообразко наоборот,все про морг,инь и янь какой то)))

Koldun1

30 — 19.05.10 — 09:26

у меня есть бэкап и до моих манипулиций,при запуске ошибка «недостатчно памяти»,может с ним что-нибудь штатное можно сделать,чтобы завелось?

vde69

31 — 19.05.10 — 09:28

Koldun1

32 — 19.05.10 — 09:32

на днях поковыряю базу в общем,а точнее структуру,с этой стороны никогда к вопросу не подходил просто

Serg_1960

33 — 19.05.10 — 09:48

Вот-вот. Просто подойди к решению вопроса — может быть станешь специалистом в этом вопросе и тогда поймешь почему молчат гуру :)) Успехов.

спасибо)

В нашем предыдущем материале Как эффективно управлять ростом объема данных речь шла о том, как с самого начала не допустить ошибок при работе с базами данных. В этой же статье предлагаем рассмотреть ситуации, когда с самого начала вы совершили просчеты и столкнулись с тем, что уже поздно менять структуру данных, но все еще есть возможность их оптимизировать.

• Как работать с индексами бд?
• Индексы в бд: о чем еще стоит помнить
• Критические ошибки: запросы
• Оптимизация индексов: о чем еще стоит задуматься?

Даже если вы прислушались к нашим рекомендациям и сделали все как по учебнику, после того как ваша система заработала и накопила определенное количество данных, с ними могут случаться проблемы, например, медленное выполнение запросов. Это самое частое явление, с которым обычно сталкиваются, когда работают с данными. И это нормально, потому что на этапе разработки структуры вы не всегда сможете предугадать, как будет развиваться ваша база данных. Предположим, вы запускаете MVP-проект, но впоследствии тестовый продукт может обрасти не тем функционалом, который был запланирован. С самого начала сложно все предусмотреть, поэтому заниматься оптимизацией не всегда имеет смысл, нужно сперва посмотреть, во что выльется проект. Все оптимизации, которые на этом этапе надо выполнять, обычно связаны с двумя вещами: во-первых, вы начинаете индексировать все, что индексировали до этого, а во-вторых, вы смотрите, как вообще осуществляются запросы, возможно, они выполняются неэффективно.

Как работать с индексами

Учимся читать план выполнения запроса.

Разработчики зачастую плохо понимают, как устроены базы данных. Нужно уметь разбираться в том, как их структурировать и проектировать. Также большинство разработчиков не понимает, что такое план выполнения запроса в СУБД. Но это несложно: достаточно изучить документацию и понять, где в запросах теряется время. Чаще всего помогает «навешивание» каких-нибудь индексов.

Частичный индекс компактнее полного.

По умолчанию индекс, который вы навешиваете на таблицу, индексирует вообще все значения. Но в большинстве случаев вам не нужны NULL-значения, если они есть базе. Так выкиньте их и постройте такой индекс (любая СУБД это позволяет), который NULL-значения не учитывает. Размер индекса в этом случае у вас сильно уменьшится и будет содержать в себе только то, что нужно. То же самое касается ситуации, когда значения, которые вы индексируете, тоже вам не нужны. В поле могут быть значения от 1 до 100, но вы чаще всего делаете запрос по значениям 1, 2, 3, поэтому можете легко проиндексировать только эти значения. В этом случае индекс у вас будет небольшого размера, и работать он будет быстро. Разницу между полным индексом и частичным можно даже увидеть на глаз в вашей системе мониторинга: время отклика резко упадет.

Кластеризованные индексы идеальны для дат.

Кластеризованным называют индекс, который гарантирует, что данные в вашей таблице идут друг за другом и так, как надо. Это бывает очень полезно, когда вы в своих запросах используете интервалы, и, чаще всего, интервалы по датам. Например, вы делаете запрос о поиске всех строк с 18 по 19 июня, и если вы используете на дате кластеризованный индекс, то строки будут идти подряд, а это значит, что СУБД их очень быстро считает с диска, а не будет «бегать» по всему диску и искать. Это минимизирует количество операций чтения и может значительно уменьшить время отклика.

Функциональный индекс поддерживают все СУБД.

С помощью него вы можете индексировать данные по какой-либо функции. Бывают ситуации, когда вам нужно найти всех людей, у которых день рождения 19 июня (не важно какого года). И именно функциональный индекс эффективен в данном случае.

Индексы по числам эффективнее, чем по строкам.

Храните все, что является числом, как число (номера телефонов, ИНН и так далее), потому что индекс по номерам телефонов и ИНН (его часто приходится навешивать и на одно, и на другое) будет занимать меньше места, а если что-либо в СУБД занимает меньше места, то оно быстрее находится, считывается, оптимально кэшируется и быстрее выдается. Все это влияет на производительность. Пока у вас маленькая база данных, это незаметно, а когда она вырастает до гигабайтов и количество запросов в секунду переваливает за несколько десятков, вы сразу это ощущаете.

Индексы: о чем стоит помнить?

Не все можно эффективно индексировать.

Не все понимают, что индексы имеют свои пределы и ограничения. Встречаются разработчики, которые при создании таблицы навешивали индексы на каждое поле с надеждой, что база будет работать быстрее. Вообще не рекомендуется индексы навешивать сразу при создании таблицы, нужно сначала дождаться результата, а потом смотреть, какая у вас логика и план выполнения запроса. Не нужно торопиться.

Поиск по нескольким индексированным полям — лотерея. Надо помнить, что если в одной таблице есть несколько индексированных полей и вы не по всем из них ищите данные, то результат будет непредсказуемым, как в лотерее. Ситуация может отличаться от сервера к серверу и от машины к машине. Почему? Разные условия, нагрузка, количество памяти, скорость работы с диском. Поэтому индексировать данные надо, изучая план запроса на том самом «боевом» сервере, на котором у вас возникли проблемы.

За индексами нужно ухаживать. Индексы со временем «разбухают», становятся большими, и их нужно постоянно чистить, сжимать, дефрагментировать — только тогда они будут работать эффективно.

Много индексов на таблице — признак перегруженной структуры.

Критические ошибки: запросы

Нижеприведенные рекомендации — это классика жанра, об этом написано в любом руководстве по тому, как правильно работать с SQL-базами данных. Никогда нельзя запрашивать все разом (SELECT *), запрашивайте только то, что вы ищите, это, если хотите, закон. Скорость работы СУБД зависит в том числе и от того, сколько вы из нее запрашиваете. Если вы запрашиваете много ненужных вещей, которые потом выкинете, значит вы делаете работу вхолостую. Такой запрос — зло, особенно в ситуации, когда таблица большая.

За SELECT COUNT (*) и LIMIT/OFFSET надо винить разработчиков таких интерфейсов, где есть списки с постраничным выводом данных. Это, может, выглядит красиво, но даже по опыту использования поисковиков мы знаем, что пользователи дальше второй страницы заходят редко. А если список длинный, то они и первую страницу просматривают не до конца. Нужно давать в интерфейсах возможность делать такие фильтры, чтобы данные можно было получить быстро и именно столько, сколько нужно.

Арифметика в фильтрах, функции и полнотекстовый поиск убивают индексы. Если в условиях поиска вы используете арифметику, функции или полнотекстовый поиск, то чаще всего это убивает любые индексы. Запросы не будут быстрыми: вам нужно будет или упрощать их, или использовать какие-то специфические решения (например, для полнотекстового поиска есть плагин либо функциональный индекс, о котором шла речь ранее).

Оптимизация: о чем еще стоит задуматься?

Настройка ORM.

На это месте нам начинает сильно мешать ORM. Разработчики любят ее использовать, это сильно упрощает работу, но она часто делает много лишних действий. Это могут быть как неоптимальные запросы, так и просто лишние. На практике при разборе ошибок мы видели ситуации, когда ORM запрашивает из базы что попало, когда ее об этом не просили. Ее нужно уметь настраивать, чтобы она этого не делала.

Рефакторинг бизнес-логики.

Иногда проще сделать два маленьких запроса, чем один большой — он будет медленнее. Но здесь каждый случай индивидуален, нужно уметь экспериментировать. Поэтому чтобы ускорить работу с базами, стоит и настроить ORM, и отрефакторить запросы к ним.

Контроль ссылочной целостности.

Речь идет о ситуациях, когда настроены каскадные удаления и обновления. В то время, как вы пытаетесь что-то удалить, СУБД ищет все связанные сущности и пытается понять, стоит их удалять или нет. В этом случае можно не удалять, а помечать как удаленную. Либо пытаться ссылочную целостность как-то порвать, но это может привести к несогласованности, когда вы случайно забудете удалить вместе с основной записью и все связанные с ней. В этом случае в вашей базе будут накапливаться «потерянные» записи. Они, как минимум, будут зря занимать место. Но в перспективе это может привести к неправильной работе бизнес-логики, что гораздо хуже. Так что, если вы очень часто удаляете что-то из БД, то рвать ссылочную целостность надо очень аккуратно, семь раз проверив, что вы удалили действительно всё.

Оптимизация структуры БД — исправление ошибок, совершенных ранее. Если к тому времени, когда у вас начались первые проблемы со скоростью вы видите, что ошиблись на первой стадии, настало время их поправить, потому что далее проблемы будут усугубляться.

Заполнить и подать уведомление об исчисленных суммах налогов и взносов