Stalker_RED

https://www.extendoffice.com/documents/excel/5894-...

select 
   manga_id, 
   count(manga_id) as cnt 
from manga2likes
group by manga_id
order by cnt

LOAD DATA... INFILE 'myfile.csv'...
https://dev.mysql.com/doc/refman/8.0/en/load-data.html

что-то по лучше, чем MySQL

а что получше - феррари, карьерный самосвал или метро?
Феррари вроде как быстрее, но не может перевезти 500 тонн за один рейс. Карьерный самосвал перевезти может, но расход горючки сумасшедший. А у метро фича - гоняет без пробок, но только там, где рельсы заранее проложили.

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

Целиком в БД сохраняют с тегами HTML, или Объектом JSON

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

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

1000 строк загружается за 3-4 минуты

интересно в каком виде у вас данные и как вы их загружаете, вероятно вы делаете что-то сильно не так.
Откуда у вас вообще цифра 1000, вы построчно вставляете?

Другие технологии, их есть у нас. Называется - просто не делай этого вообще.
Игрок получил повреждения - записываешь в базу, и все, ничего не регенерируешь.
Когда произойдет какое-то новое взаимодействие с игроком - получил новый урон, обновил страницу, или какая там у вас игровая логика, тогда уже, при помощи формулы "прошедшее_время * скорость_регена = сколько_здоровья_оргененило".
С баффами все немножко сложнее, но смысл тот-же - считайте формулой, и в тот момент когда данные нужны, а не в фоновом процессе неведомо зачем.

Частично проблема решается алгоритмом шинглов, который неплохо находит похожие тексты. Но хороший рерайтер легкло сделает текст отличающимся на 40-60% при сохранинеии смысла. А в последнее время можно вообще сделать магию: "чатгпт, перепиши этот текст другими словами добавив тоски о былом величии римской империи", и все это за считанные секунды и бесплатно.

По расчетам вот этого сервиса процент схожести менее 30%

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

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

Или включайте вручную каждый раз если автозапуск не нужен.

Call to a member function findOne() on null, то есть у null нет метода findOne, то есть вместо редбиновского объекта R у вас null, то есть при попытке подключить redbean какой-то серьёзный косяк.

limit 1 добавьте

Если бд копируется просто как "папка с файлами", то да, она может сломаться, если она копируется в "неподходящий момент". Частично от этого можно спастись журналированием, но это не точно.

Чтобы не ломалась надо либо корректно останавливать ее перед копированием, либо использовать встроенные в БД средства репликации или синхронизации.

Важно, чтобы была возможность работать с актуальной БД оффлайн.

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

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

Для описанного достаточно трех таблиц: юзер, задача и заявка.

Обычно в таких случаях просто в таблице "фонды" добавляют колонку "помогает ли" и выставляют там 1 или 0.
Тогда и при смене статус а транзакция не нужна, и поиск фонда по имени остаётся простой задачей.

$results = ($query);
Серьёзно? Вы кусок кода потеряли)

SELECT answers.*, count(*) as cnt
FROM answers
LEFT JOIN likes ON likes.answerID = answer.id
GROUP BY answer.id