abroabr

На деле это проще, чем выглядит.

Внутренее соединение - это самое обычное соединение таблиц. Даже нет необходимости указывать, что это inner join, если и более простой синтаксис - это будет все равно внутреннее соединение.

Внутреннее соединение означает, что в результате вы получите то, что было в обоих таблицах сразу. Если хотя бы в одной из таблиц не было записи, соответствующей условию соединения - вы не получите соответствующую строку.

Внешнее соединение обозначает, что помимо того, что вам выдало бы внутренее соединение вы дополнительно плюсом получите данные из первой (left join) или второй (right join) таблицы. Даже если в другой таблице и не было записей, соответствующих условию соединения.

Зачем может быть нужно внешнее соединение? Например, у вас есть пользователи, которые не входят ни в одну группу. Построив внешнее левое соединение по таблице пользователи и по таблице группы - вы получите полный список пользователей. Те из них, что не входят ни в одну группу - тоже будут присутствовать в списке, но в колонках описывающих группы будет указано NULL.

Если же вы построите ровно такой же запрос по внутреннему (обычному) соединению, то есть соедините пользователей и группы - то получите только тех, кто входит хоть в какую-то группу.

Полнотекстовый поиск устроен достаточно примитивно.
У всех. Разница только в нюансах.

1. Делится текст на отдельные слова, отбрасываются короткие и служебные слова.
2. Прогоняются слова через стемминг (отсекаются окончания) snowball.tartarus.org/algorithms/russian/stemmer.html
3. По словам строится индекс что-то типа такого roaringbitmap.org

Все - MySQL, PostgreSQL, SphinxSeach, ManticoreSearch, ElasticSearch - работают по такому алгоритму, когда речь идет о полнотекстовом поиске.

Качество поиска упирается в основном в п. 1 и 2. Плюс ручная заточка (дополнительный словарь и пр.)
Скорость поиска упирается в п. 3.

Есть небольшие отличия. Например, ElasticSearch умеет работать с индексом, который хранится на кластере из нескольких серверов. Таким образом, он не ограничен в размере индекса так жестко как SphixSearch (где принципиально, чтобы данные располагались на одном сервере).

С другой стороны - SphinxSearch и его форк ManticoreSearch - чрезвычайно заточены на скорость. В частности, в них принята парадигма - игнорировать ошибки при построении индекса настолько настолько это возможно. Все ради скорости.

MySQL и PostgreSQL - не имеют никаких преимуществ ни по скорости (как Sphinx/Manticore) ни по объему индекса (как ElasticSearch). Их преимущества - простота использования, если у вас данные изначально хранятся в реляционной СУБД.

Нет, выхлопа по скорости при переходе на MySQL c Sphinx вы не получите. Sphinx быстрее. От заточен именно на скорость.

Другое дело, что, возможно, вам не понадобится столь высокая заточенность на скорость у Sphinx. Возможно, удобство хранения в реляционной СУБД MySQL перевесит.

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