include в php большого файла

Еще раз - это ВООБЩЕ не оптимальное решение! цль была - примерно оценить скорость чтения записи в сравнении с БД.  И даже в таком варианте я признаю, что это сопоставимо. Если грамотно организовасть файловую систему, оптимизировать запись и чтение - это может быть быстрее, чем использовать БД. По крайней мере на небольших обьемах и сопоставимо по потреблению памяти.  Так понятнее? Не в рамках вопроса пытаться написать оптимальный скрипт на базе кода который я привел - он не для этого был написан.

Я могу затереть занные в файле, могу многократно писать одно и тоже, могу удалить случайно файл, могу записать в него недопустимые символы и он перестанет читаться.... Все это нужно предусматривать. А при работе с SQL все это уже есть

Влияет. все то что я написал выше. Например достаточно тип поля сделать уникальным и я избавляюсь от необходимости каждый раз проверять, есть ли такой айди в таблице. Добавление в CONSTRAIN ONDELETE Cascade - упростит мне очистку базу от ненужных данных. То есть вся та работа, которяа должна будет сделана при работе с файлами при работе с БД УЖЕ реализована. Да банальный бэкап обычно есть на любом хостинге. Наверное, давно не работал но сомневаюсь, что я ошибаюсь. 
Так что никакой гипотетичности. Все это пройдено собственными граблями на проектах с месячными бюджетами за который этот форум можно купить десяток раз. Поэтому я так критически отношусь к идее работы с файлами  в данном случае. 

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

Ваше право. В любом случае, спасибо за интересную дискуссию и что пошарили свой опыт. Лично мне было интересно и полезно. 

Start script
Found file 40000 for checking ip 49342
Count of records: 433209
This ip(49342) was blocked for download
Execution time: 0.04430103302001953

Подытоживая, нашел время проверить поиск по аналогичной БД на этой же машине. Стэк - Postrgesql 14, проиндексированная таблица, коннект с помощью SQLAlchemy. Скорость поиска в таблице с 1100000 строковых записей длиной 30 символов:

Start finder
[(Id(id=1000201, ip='mIiVBR23U2dooVjRzmCn0eC8a4XMcg'),)]
Execution time: 0.0586090087890625
[(Id(id=5, ip='wHx0pgTK4kOoI9nc7dp9b9NV7uBqnn'),)]
Execution time: 0.004904031753540039
[]
Execution time: 0.004606962203979492

То есть в худшем случае результат сопоставим, в лучшем - на порядок быстрее при количестве записей в 2 раза большем 

Все-таки база побеждает) Да и кода там меньше получается.

И кстати, JOIN еще одной таблицы, например, если я хочу добавить еще  описание, хранящееся отдельно - не сильно увеличивает скорость

Результат выполнения такого кода 

    @timer
    def get_id(self, ipid):
        stmt = (
            select(BlockedID.ip_id, Description.url)
            .join(Description, Description.blocked_id == BlockedID.id, isouter=True)
            .where(BlockedID.ip_id == ipid))
        with Session() as session:

            print("="*120)
            print(stmt)
            result = session.execute(stmt).all()
            print("-" * 120)
            print(result)

что генерит запрос типа

========================================================================================================================
SELECT blocked_id.ip_id, description.url 
FROM blocked_id LEFT OUTER JOIN description ON description.blocked_id = blocked_id.id 
WHERE blocked_id.ip_id = :ip_id_1
------------------------------------------------------------------------------------------------------------------------
[('1234456', 'http://tut')]
Execution time: 0.006269931793212891

Для миллиона записей совсем некритично. Сам HTTP запрос будет занимать намного больше времени,  Получение результата - малая часть в процентном отношении ко всему времени. 

В итоге получаю очень простой код,  хорошую надежность, простой бэкап данных, чем в случае работы с файлами

А если при этом всем еще вместо постгри взять например keydb?

Думаю будет вообще летать)
На семинаре  от компании Postgres Professional очень обижались на постгри вместо правильного "постгре(и)с" 

Почему то все считают что раз PostgreSQL  то надо отбрасывать 3 буквы, но это не совсем верно) Да  и несильно к делу относится. На noSQL базах не проверял, впрочем очевидны их преимущества по скорости. SQL  и файлы в одной лиге, поэтому  интересно было их сравнить