rPman

храни количество использованных рефералов, тех что уже учтены для выдачи награды, тогда условие выборки людей, кому нужно выдать награду будет where ref_cnt-used_ref_cnt>=10
и выдавать награду либо несколько раз пока не останется рефералов (мало ли кто то разом 1000500 найдет) либо сразу считать нужную награду

наведете на решение?

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

По делу, одно время я пользовался в windows bat скриптами (готовые были написаны для win7 и уже не работают в win10, но идея там простая, все переписывается легко) когда на целевом диске создавался снапшот, затем с помощью rsync создавалась полная копия указанных каталогов, но с указанием предыдущей версии реплики, для неизменившихся файлов утилита создавала hardlink на прошлую копию, в результате получается идеальная инкрементальная копия, с которой можно работать как с обычными файлами (не требуется извлечение из сжатых архивов и последовательное принятие патчей инкрементации), причем на любую сохраненную дату, при необходимости можно легко удалить старую или даже любую реплику, благодаря корректной обработки hardlink файловой системой.

Сам диск можно подключать по сети, на выбор либо средствами windows (.vhd файлы) либо iscsi
Сжатие - поддерживается, но только слабое ntfs.

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

Второй недостаток - год ежедневных копий с даже средним количеством файлов в итоговом разделе создаст миллиарды hardlink (лимит на количество hardlink на один файл - 1024, это примерно три года ежедневных бакапов), ну и к примеру, проверка такого диска с помощью chkdsk может потребовать дни и недели.
----------------------------------------

Другой подход, если требуется создание копий общей шары на сервере (linux само собой), выбираешь cow файловые системы, с поддержкой онлайн снапшотов - btrfs/zfs. Каждый день или даже каждый час создаешь снапшот и хранишь так долго как это необходимо, удаляя не нужные тогда когда пожелаешь (операция моментальная, не зависит от объема данных). Это защитит данные от проблем на клиентской стороне, например ошибочные удаления или вирусы-шифровальщики и т.п.

Чтобы защитить данные от проблем с серверным железом, то к примеру можно использовать фишку btrfs incremental backup, когда разницу между двумя указанными снапшотами (предыдущим и текущим) отсылают на удаленный сервер, упаковав его в один файл (точнее поток). т.е. эти патчи можно хранить и применять на заранее сохраненное стартовое состояние файловой системы. Само собой удаленный сервер так же должен хранить снапшоты (кстати а патчи можно хранить на третьем сервере).

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

В обоих случаях советую создание автоматических отчетов по изменениям (не только общие но к примеру по пользователям, сколько изменений какие пользователи сделали, в графиках), т.е. даже информация о размере снапшота более чем полезна, если нормально у вас еженедельно получать дифы размером X гигабайт, а сегодня внезапно получаете 0 или 100X это уже повод забеспокоиться.
----------------------------------------

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

у mysql нет адекватных методов управления приоритетами (есть low-priority yно оно действует на не все engines) поэтому исторически распределение нагрузки делают с помощью репликации.

Поднимаешь второй сервер (физически файлы базы должны быть размещены на другом диске или даже сервере) и настраиваешь между основным и этим второстепенным master-slave репликацию, требования к этому среверу сильно ниже (зависит от нагрузки само сабой, но в основном там будут только записи) и уже на эту базу натравливаешь mysqldump

p.s. альтернатива, запилить свой/подправить исходники mysqldump, в своем приложении скорость получения данных можно контролировать принудительными sleep-ами (например запрашиваешь табличку, а в цикле получения данных вставляешь раз на тысячу строк sleep).
первый же нагугленный код mysqldump на php, вставь слип в этот цикл

upd. не нужно править код штатной утилиты, более чем достаточно просто использовать штатный механизм потоков linux и замедлить запись итогового дампа с помощью к примеру cstream

mysqldump ... | cstream -t $((1024*1024)) | zstd --ultra -T0 -o backup.sql.zstd

p.p.s. тупо, останаливаешь базу, копируешь файлы с таблицами как есть, переносишь на свою машину, поднимаешь там ту же версию mysql, делаешь дамп

нужно смотреть что там за сообщение об ошибке, вполне возможно /usr/lib/php/20200930/mysqli.so файл нулевой длины и его достаточно будет удалить вручную

удаляй все что хоть как то конфликтует, включая их зависимости
apt purge ...

если что можно удалять вручную с помощью dpkg игнорируя зависимости но в конце концов порядок нужно восстановить чтобы apt autoremove -f отработало и dpkg-reconfigure -a тоже

p.s. почему у тебя такой странный путь?
поэтому вместо debian я ставлю ubuntu, список и поддержка backports для кучи полезных приложений там заметно полнее и все за порядок удобнее

Совершенно нормально, вместо выполнения запроса на аналитику в момент вывода, делать это тригером во время изменения данных, в соответствующее поле.

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

Место на диске на порядки дешевле чем процессорное время (и время работы этого диска), которое ты будешь тратить на аналитику.

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

есть хорошее правило, постарайся, все что касается только интерфейса и поведения пользователя в сессии, хранить у пользователя, зачем это на сервер тащить?

Классический алгоритм обхода дерева по линейному списку - рекурсивный.
твой метод должен искать элементы в списке, у которых parent_id указанный в параметрах вызова, возвращает метод html код отрисовки найденных элементов (кстати что возвращать так же зависит от того, как именно ты собираешься рисовать дерево, есть два подхода, рекурсивный и линейный с отступами)

Первый вызов метода должен быть с пустым parent_id, он найдет и выведет корневой список, затем (или в процессе, зависит от способа рисования дерева) в цикле этот метод должен для каждого элемента вызывать этот же метод но с указанием в качестве parent_id текущий элемент.

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

Часто генерируют все дерево но для не раскрытых веток указывают стиль - display:none, меняя его при перемещении пользователя по дереву.

это называется pivot table

в mysql (да и многих других) нет их как часть синтаксиса языка, и каждый генерирует sql запросы по ситуации, используя case/if подставляя нужное условие под нужную таблицу - это для вывода (т.е. в select) соответственно создавать такие таблицы не получится, их приходится симулировать, размещая колонки как записи 1-ко-М в одной таблице.

Подавляющее большинство реализуют подобную задачу именно так, в лоб, теряя полезную информацию о типах данных, объединяя их в текстовую строку.

Но в некоторых (а может и частых) случаях, как к примеру описан в вопросе, из самого запроса можно вытащить информацию, какие слова к каким типам данных относятся, просто сначала нужно искать слова в справочниках (связанных таблицах по полям type_id и subtype_id), и уже вооружившись списком отфильтрованных идентификаторов, искать их в целевой таблице.

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

Это сложнее, но в особых сложных случаях это может быть оправдано.

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

Во первых, ты создаешь html а не excel, да офис умеет открывать такие файлы и даже не ругается, но если хочешь работать с документами напрямую, работай с .xlsx или .ods (open document стандарт поддерживается везде и всеми, это стандарт для документооборота, пользуйся лучше им) - это по факту архив с текстовыми xml документами

По факту, настрой кодировку, с которой ты будешь общаться с базой данных set_charset либо поменяй свою кодировку в php коде на ту же что выдает база данных (utf-8) и пропиши в твоем html в в заголовке

Разместить разные таблицы в разных таблеспейсах, а сами таблеспейсы на разных физических носителях, чем больше физических устройств у тебя будет, тем эффективнее будут работать независимые операции.

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

Windows конечно медленнее linux работает с диском, но не на порядок же, железо не одинаковое? на linux ssd а на windows hdd?

Итоговые файлы базы данных какого размера получаются? влезут ли они, если их разместить на ram диске, создав таблеспейсы на нем его перед импортом, потом перенесешь обратно (я помню достаточно давно останавливал базу, переносил каталог с таблеспейсами на рам диск, а на прежнем месте оставлял символическую ссылку, потом, после тяжелой работы с базой, так же остановив ее, переносил обратно)

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

Например сделай дополнительную таблицу, в которую будешь набирать изменения до определенного количества (или лучше по времени, раз в сутки/час/...) и потом одним запросом переносить, пакетом перестройка индекса идет быстрее.

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

p.s. решать задачу нужно исходя из того как данные читаешь и как в них делаешь поиск. Именно от этого зависит каким образом можно реорганизовать хранение или даже отказаться от mysql

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

where id in (...) работает не быстрее?
ок, залей нужные id в temporary table и делай from table,temp...

Перепроверь, что тип поля действительно числовой а не к примеру varchar (хотя если там числа то это не должно что то менять)
Перепроверь что база данных не повреждена, может просто пересоздать индекс?

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

Так же большее влияние оказывает конфиг и железо, на котором все запускается и к примеру переход от hdd к ssd (кстати даже если индексы отдельно положить на ssd).

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

ты на каждую запись из f_list (отфильльтрованную по условию в where) выводишь ВСЕ users, вот они и умножаются
sql это про умножение таблиц друг на друга, когда они указаны во from

необходимо задать условие как связаны записи из f_list с users, обычно это foreign key индексы (или у тебя там еще табличка промежуточная)

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

Зарос выглядит правильным, значит что то с данными не так.

Посмотри что выводит запрос если оставить только одно условие к примеру по street? и выводи в select *