Материалы
Когда база данных становится видимым узким местом, команды часто сразу прыгают к миграции или переписыванию. Иногда это оправдано, но часто первым делом нужен тюнинг БД и пересмотр структуры. Первый вопрос - где именно теряется производительность и что можно безопасно улучшить.
Лучше всего подходит
Начните с того, чтобы найти, где действительно тратится время. Посмотрите на тяжелые пути запросов, индексы, patterns join-ов, нагрузку отчетности и те места, где код приложения компенсирует плохой доступ к данным.
Некоторые проблемы производительности на самом деле являются проблемами схемы. Перегруженные таблицы, непоследовательные ключи, исторические shortcut-ы и неясное владение данными создают трение, которое нельзя убрать одними настройками запросов.
Взвешенный первый проход по тюнингу улучшает текущую производительность, показывает, какой долг схемы действительно важен, и создает более чистую основу для будущей миграции или редизайна.
Следующий шаг
Короткой заметки о системе, риске поставки или операционной проблеме достаточно, чтобы сдвинуть обсуждение с места.