Для начала вам может потребоваться сделать шаг назад и пересмотреть свою схему. Как вы получили 10 миллионов строк в таблице участников? У вас действительно есть 10 миллионов участников (кажется, много)?
Я подозреваю (хотя я не уверен), что у вас менее 10 миллионов участников, и в этом случае ваша таблица не будет правильно структурирована. Пожалуйста, опубликуйте схему, это первый шаг к тому, чтобы мы помогли вам.
Если у вас есть 10 миллионов участников, я бы посоветовал вам начать с того, чтобы ваше приложение не зависело от поставщика (то есть стандартного SQL). Затем, если вы начнете сталкиваться с проблемами, просто выбросите вашу текущую СУБД и замените ее более мощной.
Как только вы установили, что у вас есть подходящий вариант, тогда и только тогда я бы посоветовал использовать материал, специфичный для поставщика. В противном случае это будет болезненный процесс для изменения.
Кстати, 10 миллионов строк на самом деле не считается большой таблицей базы данных, по крайней мере, откуда я.
Кроме того, важно следующее (не обязательно исчерпывающий список, но хорошее начало).
- Дизайн ваших столов для 3NF всегда. Как только вы выявите проблемы с производительностью, вы можете нарушить это правило, если понимаете последствия.
- Не беспокойтесь о настройке производительности во время разработки, ваши запросы постоянно меняются. Просто примите тот факт, что они могут не бежать быстро.
- Как только большинство запросов заблокированы, затем начинают настраивать ваши таблицы. Добавьте любые индексы, ускоряющие выборки, отмену нормализации и т. Д.
- Настройка - , а не - операция установки и забывания (вот почему мы так много платим нашим администраторам баз данных). Постоянно следите за производительностью и настраивайте под себя.
- Я предпочитаю придерживаться своего стандарта SQL, чтобы сохранить возможность переключения поставщиков в любое время. Но я прагматичный. Используйте специфичные для продавца вещи, если они действительно дают вам импульс. Просто будьте в курсе того, что вы теряете, и постарайтесь как можно больше изолировать вещи, специфичные для поставщика.
- Люди, которые используют
"select * from ...", когда им не нужен каждый столбец, должны быть избиты в подчинение.
- Аналогично тем, которые выбирают каждую строку для фильтрации на стороне клиента. Люди, которые пишут наши СУБД, не сидят весь день, играя в Пасьянс, они знают , как заставить запросы выполняться быстро. Позвольте базе данных делать то, что лучше всего. Фильтрация и агрегация лучше всего выполняются на стороне сервера - отправляйте только то, что нужно по сети.
- Создайте свои запросы, чтобы быть полезными. Кроме Министерства обороны, которому требуются отчеты с подробным описанием каждого компонента их авианосцев вплоть до уровня «гайки и болты», никто не заинтересован в чтении вашего 1200-страничного отчета, независимо от того, насколько полезным он, по вашему мнению, может быть. На самом деле, я не думаю, что министерство обороны тоже читает их, но я бы не хотел, чтобы какой-то генерал жевал меня, потому что я не делал этого - эти парни могут быть громкими , и у них есть немало сложное оружие под их контролем.