DevMan

memcache и memcached - это разные вещи.
php_memcache.dll не имеет отнощения к классу \Memcached

Первый вариант, разумеется, вообще ни о чём.

Есть три вектора атаки на пароли: перебор по радужным таблицам, брутфорс и подбор по словарю.
От первого защищает соль, от второго алгоритм, от третьего сложность пароля.

У нас здесь речь идет об алгоритме. То есть, о буртфорсе. Что такое брутфорс? Это тупо подстановка случайных сочетаний символов по очереди и проверка, не совпал ли хэш. Чем быстрее вычисляется хэш, тем быстрее раскалывается пароль.
ПОЭТОМУ, ключевой характеристикой хэша для паролей является сложность его вычисления.
Твой ша-пицот-двенадцать выплоненный стопицот раз - это для современной техники как воробей чихнул. А для будущей и подавно.
Поэтому умные люди придумали алгоритмы которые во-первых вычисляют каждый хэш гораздо медленнее, а во вторых адаптируются под растующую скорость процессоров, и говорят тебе когда пора уже усложнять алгоритм. Именно этим и занимаются встроенные функции, и поэтому ты должен использовать именно их.

Во-первых не позорься, убери тег big data. 11 лямов - это не бигдата, а кошкины слёзки.
Во-вторых, надо учиться задавать вопросы.
Не вопрос вида "доктор, у меня рука болит, как сделать чтобы не болела", а подробно излагать, что за поиск, что за запрос, что за данные, что за столбец, есть ли индекс, что показывает explain.

В текущем же виде ответ только один - помазать зеленкой добавить индекс
если индекс есть, и поиск идет по полному совпадению, то смотреть, влезает ли индекс в память
Если поиск идет по частичному совпадению - то выносить его в отдельный сервис, sphinx/elastic

Можно не придумывать велосипеды, а использовать постоянный профиль.
Оба варианта рабочие 100 пистонов!
Проверял лично на Linux Mint 19.3 и Windows 10 20H2.
Если при запуске профиля не существует, chrome сам его создает. При закрытии профиль сохраняется и при следующем запуске подхватывает его со всеми настройками и расширениями.

Код (для Linux):

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument("user-data-dir=/home/sergey/SeleniumProfile")
driver = webdriver.Chrome(chrome_options=options)
driver.get("https://google.com")

Запускаете его, он создает профиль. Далее в браузере идете в магазин с расширениями и устанавливаете себе любые расширения. Все! При следующем запуске кода selenium будет использовать данный профиль вместе с расширениями.

Вот код для Windows:

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument("user-data-dir=C:\\profile")
driver = webdriver.Chrome(chrome_options=options)
driver.get("https://google.com")

Автор решил удалить вопрос, но не смог, т.к. уже есть ответ. За такое канделябром бить надо.

изучаю Vue.js и никак не могу понять зачем он нужен

Не можете понять - значит вам он не нужен. Отложите его в сторону, и изучите что-нибудь другое.

Просто нужно создать новую хэш-таблицу в 20 миллиардов и всё? Ведь это делается за секунды.

1. Даже просто выделить память на 20 миллиардов хешей займет далеко не секунды.
2. Не секунды займет записать их на диск.
3. Соль нужна для того, чтобы нельзя было использовать РАНЕЕ сгенеренную хеш таблицу.
4. md5 не самый лучший хеш на сегодня - можно использовать более трудоемкое хеширование, которое будет генерироваться медленнее.

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

Технически можно и так, и сяк. Но, как всегда, есть нюансы, на которых и сыпется большинство советчиков (в том числе в этом треде).

Если у вас только сайт на домене, максимум почта на других портах, и даже CDN не используется - можете спокойно использовать основной домен без www. Если у вас сайт многоязычный, и языки размещены на поддоменах - тогда тоже без www. Если же у вас есть и другие ресурсы в домене, например:

www.example.com - публичный сайт
developers.example.com - публичный сайт инструментов для разработчиков
api.example.com - какой-нибудь публичный АПИ
cdn.example.com - поддомен content delivery network (можно много - cdn1, cdn2 итд)
docs.example.com - публичная документация
help.example.com - публичная справка
support.example.com - публичная служба поддержки
dev.example.com - закрытая, непубличная копия сайта, стейджинг
hr.example.com - закрытая, непубличная часть, внутренние ресурсы компании для сотрудников
mail.example.com - технический субдомен для почты
webmail.example.com - веб-морда для почты (может быть как публичной, так и открытой для отдельных IP, доступ по VPN и тд)
vpn.example.com - чисто технический поддомен для проксирования трафика через VPN компании
ns1.example.com - поддомен для своего сервера имен (ns1/ns2/ns3 или primary/secondary и тд)

... и так далее. Таких поддоменов может быть очень много, и у каждого своя, совершенно изолированная кухня. Так вот, если использовать для публичного сайта домен без www, то все его куки будут распространяться на все поддомены. А это плохо. На современном сайте этих кук штук 10 минимум, большая часть из них совершенно не нужна, или даже откровенно лишняя на всех других поддоменах. В это же время, если вы используете www и хотите поделиться куками с него с другим поддоменом - это вполне возможно сделать, осознанно.

Кроме этого - с www намного удобнее работать на уровне DNS, если это CNAME. Записи типа А лучше ставить долгий TTL, а вот CNAME может иметь короткий и его можно перебрасывать в любой момент. Пошла DDoS-атака - в считанные минуты пустили трафик через гейт сервиса защиты от DDoS или выделенный файрвол (у который другие IP-адреса). Или балансировку нагрузки делать. При этом основной домен (origin) и его IP не меняется, почта не слетает, внутренние сервисы не слетают, АПИшки не падают и тд.

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

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

потому что это не исполняемый файл

Исполняемый файл это файл который исполняет операционная система.
в данном случае РНР файл исполняется не операционной системой, а веб-сервером, и права на исполнение к нему не имеют отношения вообще никакого

Очень просто - в один блок монтируется приложение на react, в другой на vue.

Зачем - вопрос не сюда, спросите у тех, кто так сделал.