Блог

ОБЪЕДИНЕНИЕ — удобная функция баз данных SQL, но как насчет больших баз данных (> 10 ГБ). Рассмотрим три таблицы (с двумя столбцами) отношений «многие ко многим», поскольку мы хотим получить элементы, связанные с одним отдельным случаем (например, теги ОДНОЙ статьи).

ФАКТЫ (поправьте меня, если я ошибаюсь): 1. Для ОБЪЕДИНЕНИЯ в памяти должны помещаться три таблицы. 2. Одиночный ВЫБОР по ПЕРВИЧНОМУ КЛЮЧУ не потребляет память. 3. Когда у нас есть много одновременных подключений для чтения, избыточное соединение будет храниться в очереди (без выполнения неудачного запроса или перегрузки).

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

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

Ограничение действий простыми запросами SELECT с ПЕРВИЧНЫМ КЛЮЧОМ может быть практическим подходом для эффективной работы с большими базами данных.

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

Индексы могут быть действительно полезны с большими базами данных.

Это может помочь http://www.databasejournal.com/features/mysql/article.php/1382791/Optimizing-MySQL-Queries-and-Indexes.htm

http://www.tizag.com/mysqlTutorial/mysql-index.php

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