Psychedelic Geek

Угу. Сначала понаставим @, чтобы скрыть все ошибки, а потом будем голову ломать, почему ничего не работает и ошибок не показывает.

А вообще, это делается в одну строку.

file_put_contents($outfilename, str_replace('Российский рубль', 'RUB', file_get_contents($infilename)));

Если очень кратко:
Вам нужно понять, что индексы это не такая уж элементарная вещь. Нельзя просто поставить на поле флажок "индексировать". Индексы это тонкая настройка, и чем сложнее выборки, тем она сложнее. Даже не рассматривая различные типы индексов, выбрать какие поля, в какой последовательности, с какой сортировкой и в каком индексе должны присутствовать бывает не так просто. Для этого нужно очень хорошо понимать и как устроены индексы, и как с ними будет работать оптимизатор и какова селективность конкретных данных. И тогда, скорость выборок можно увеличить в разы, но все это конечно не бесплатно.
Тем не менее, другой ваш вопрос, если нужно фильтровать и сортировать по всем полям таблицы, а полей очень много, здесь уже использование реляционных СУБД не оправдано и на помощь приходят другие инструменты, типа ElasticSearch.
Если заботитесь о стабильности, то индексы всегда назначаются при разработке соответствующих запросов. Если потом мы их и меняем, то потому что чтото не предусмотрели.
Индексы могут замедлить работу. Очевидно, что они замедляют вставки и апдейты, но при криворукости можно замедлить и выборки, ведь и оптимизатор тоже ошибается. Индекс это по сути еще одна таблица, что уже намекает что не всегда это будет быстрее, т.к. придется работать не с одной таблицей, а с двумя (не всегда с двумя, но опять же, в двух словах все не охватишь).

Когда ты связываешь две таблицы по полю, то поле второй таблицы должно быть проиндексировано для мгновенного доступа, чтобы это поле могло быть отображено рядом. В FoxPro это наглядно видно. Поэтому сначала надо подумать, сделать архитектуру, а потом писать. Но так не всегда получается, и приходится добавлять индексы "на живую" под вновь появившуюся хотелку. В общем индексы нужны для быстрой связи между БД.

Таблица без индексов это как Array либо List объектов. Каждый новый индекс добавляет хранение этих объектов в Map (Dictionary) где key мапы это index key, а value это строка.

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

Для некоторых сложных индексов по нескольким полям иногда нужно замеры проводить. (По типу, если есть индекс с 3 полями, а ты ищешь по 4 полям, и не знаешь, что будет лучше, добавить новый с 4 полями, или продолжить использовать имеющийся с 3 полями)

Индексы нужны, но не всегда и не всем.
При разработке вы действительно точно не можете спрогнозировать нагрузку на БД. Но точно и не нужно. Как правило разработчик знает свое приложение, и какие данные из БД ему нужны. Соответственно знает предикаты (блок WHERE), которые будут в тех или иных запросах. Далее, входе разработки, когда будет накоплена некоторая статистика по наиболее востребованным предикатам, можно будет уже продумать какие индексы нужны.
В ходе реальной эксплуатации приложения, даже просто у разных клиентов может возникнуть ситуация, когда у одного все хорошо, а у другого тормозит. Все зависит от профиля нагрузки и наполнения таблиц. Бывает, что таблица DML-нагружена (много изменений) и имеет много индексов - будут тормоза, связанные с дополнительной работой по поддержания индексов в актуальном состоянии. А если ещё и много ограничений целостности...
Второй вариант, когда у одного клиента таблица на 1к строк и ему хорошо без индексов, даже если таблица "горячая" по чтениям. БД просто держит её всегда в кэше.
У другого клиента эта же таблица содержит 100к записей и ему ну очень нужны какие то индексы.
Ситуация когда данные в таблице часто меняются и часто и много запрашиваются, как правило связанны с не верной архитектурой приложения. Тут нужно уже переделывать.

Ответ очень прост. Смотришь сколько идёт ли поиск по полю, если медленно то ставишь индекс все.
Для определения быстро или медленно. Тоже легко если таблица миллион плюс записей будет то сразу да, если нет смотришь требования, запрос должен происходить максимально быстро то ставишь индекс(к примеру часто используется в подзапросе) , если не важно то не ставишь. Все весь алгоритм.
А вообще чтобы понять требуется индекс или нет смотришь сколь вообще идёт запрос в веб если он идёт в районе 1 секунды то все ок, если нет ищешь способ ускорить, сам простой способ проиндексирвать на поля по которым идёт поиск.
Так же индекс не имеет смысла ставить на поле, если ты перед этим будет фильтр, который уменьшить выборку до 10-20 значений.
К примеру у тебя в таблице, хранятся ид пользователя и его адрес. По ты точно знаешь, что только по адресу поиск не производиться, то можно фильтрануть по ид пользователя, а потомм по адресу, а адресов больше 100 99% не имеют. Тут индекс не нуден

Ну как минимум чтение индекса при поиске обходится намного дешевле, чем чтение всей таблицы. Банально меньшее кол-во данных надо прочитать. Тем более индексы - упорядоченная структура, для поиска данных по какой-то колонке не надо читать весь индекс. Можно сравнить b-tree индекс с алфавитным указателем - чтобы найти в нём ссылку на какое-то слово, не надо читать весь алфавитный указатель, надо просто перейти к нужной букве.
Но да, не каждый индекс может быть полезен. Есть такое понятие, как селективность индекса. Условно, индекс по полю "пол" реально может не давать пользы, так как даже при использовании индекса так и так надо будет прочитать половину записей в таблице и может быть быстрее просто прочитать всю таблицу.
Рекомендую прочитать книги, например, я читал "Настройка производительности MySQL" Нихтера. Тогда всё станет ясно.

Вопрос бы переформулировать. Не нужны ли индексы, а сколько надо индексов.
По своему опыту.
1 индекс на таблицу обязательно. Даже если в запросе нет условия по индексу, план выполнения строится оптимальнее, запросы работают быстрее.
А вот больше уже сильно зависит от используемой БД и самого использования. С pg например столкнулся с ситуацией, когда второй индекс сильно замедляет операции вставки и удаления. При этом этом селекты выполняются незначительно медленее. И если сравнивать организацию индексов в pg и mssql, то можно даже найти объяснения, почему то, что хорошо работало в одной БД, плохо работает в другой.

Очень просто.
По-сути это простейшая задача, часть которой покрывается в рамках любого платежного провайдера при приеме платежа.
Можешь оперировать следующими вариантами в зависимости от своей бизнес-логики:
1. использовать локацию по IP в момент регистрации юзера
2. использовать локацию по IP запроса на платеж юзера
3. использовать BIN-парсер для детекции данных о платежном методе по first 6 card digit

В свободном доступе есть куча сервисов, которые предоставляют доступ для расшифровки как ip, так и bin-информации бесплатно в рамках месячного лимита, если надо больше - просто купить подписку

но а вообще не понятно зачем заморачиваться, когда у тг есть апи и интеграция с платежными провайдерами
https://core.telegram.org/bots/payments

Связано это может быть с тем что у тебя старый роутер.
Если у тебя подключение идет под 2.4ггц 802.11n aka WiFi 4, то у тебя будет 150мбит на антенну брутто. 150мбит нужно разделить на 2, тк половина идёт на отдачу, а половина на приём.
Получается 75мбит. Делим на 8 и вот и получается чуть меньше 10мбайт

С. Прата подходит только для самого начала. 2012й год, стандарт C++11 вполне подходит чтобы начать.
Дальше Прата рассматривать уже незачем. В стандарт нужно вникать самостоятельно, а не через книги.

Смысла сначала разбираться с последними стандартами особого нет. Код C++ пишется на разных стандартах даже в рамках одного проекта. Редко получается найти достаточно большой коллектив людей, которые один стандарт знают достаточно хорошо. Поэтому люди пишут каждый в своем стиле и со своим знанием.
И в таком коде надо уметь разбираться. Между стандартами много отличий как в синтаксисе, так и в поведении одного и того же кода. Это надо очень хорошо знать.

Для систематизации своих знаний очень важно понимать то, почему в следующем стандарте были сделаны именно такие изменения. Поэтому очень важно разбираться по порядку их выхода.
cfront, C++2.0 и C++98 сегодня иррелевантны. C++03 неактуален из-за изменений в C++11.
C++11 является самой базой понимания современного C++. С ним нужно разобраться буквально до самых мелочей.
C++14 является очень важным шагом вперед и его тоже нужно изучить. Важнее всего отличия поведения кода между C++11 и С++14.
C++17 является радикальным. Помимо прочего в нем оговорен отказ от обратной совместимости стандартов. В нем же сделано больше всего изменений, влияющих на поведение кода. Разница поведения кода до 17-го и после него под час радикальна.

C++20 сосредоточен на метапрограммировании и времени компиляции, но и других изменений в нем тоже хватает. Отличия от C++17 и более ранних весьма существенны. Но продуктового кода на нем сейчас крайне мало и его еще пару лет можно не брать во внимание.
C++23 и C++26 пока можно не брать, они даже на уровне трансляторов все еще плохо поддерживаются.

Из полезного стоит больше всего внимания уделить рабочей версии стандарта: eelis.net/c++draft
А для быстрого ориентирования очень полезна выжимка изменений в стандартах: https://github.com/AnthonyCalandra/modern-cpp-features

И самое главное. Не думай что у тебя получится все понять сразу. Люди на этот процесс кладут десятки лет своей рабочей жизни. Тебе их не перепрыгнуть. Но бежать впереди основной серой массы слабоквалифицированных кадров у тебя получится с успехом. И спустя твои десятки лет тебя тоже будут уважать за знания и навыки.

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

Абсолютное большинство фронтендеров не используют Vim и прекрасно справляются. Те, кто использует, тоже справляются. Десятикратной форы не даёт ни то, ни другое.
Поэтому, я бы сказал, что энергию лучше направить на что-то более практическое, но если хочется, то попробуйте, конечно.