rPman

хоть один пример такой функции показал бы

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

p.s. гугли - php профилирование вызовов функций

1000 записей скорее всего можно на клиента выгрузить и в javascript искать это будет самый быстрый вариант

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

Если говорить про конкретный случай, то загрузка дампа памяти из файла в готовом виде типа var_export, или лучше igbinary_serialize, будет самым эффективным способом

Но нужно понимать что если алгоритм поиска сложный, не просто по подстроке, то тут уже сам php будет давать накладные расходы

Попробуй переверни логику по другому:
Не удалять 'по крону' запись, а при чтении из базы выводить только те записи, которые удовлетворяют условию - запись не старее 24h и email_status!=0
Само же удаление производить когда-нибудь потом, время выбирать уже тебе и разово для всей базы а не для одной записи.

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

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

Самописное приложение на любом языке программирования, который тебе известен.

Можно само собой пользоваться готовыми утилитами типа sed (регулярными выражениями) и awk (это вообще специализированный древний язык работы с потоками данных)

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

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

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

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

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

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

Первое что нагуглил это для VB# но разницы нет никакой

шлешь в бесконечном цикле паузу и запрос
SHOW FULL PROCESSLIST;
сохраняешь список идентификаторов для проверки а следующем шаге, проверка - если какой то id остался с прошлой проверки - считать этот запрос медленным, интервал (длина пауза) между запросами - пороговый интервал для определения что такое 'медленный'

upd. можешь добавить к идентификатору содержимое info, как то поможет, чтобы хоть немного обойти замечание акина

локальная sql база данных - это sqlite

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

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

база данных по умолчанию лежит /var/lib/mysql полностью заменяешь на новой установке (при выключенной машине или службе) на ту что скопировал и все будет работать

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

p.s. mysql позволяет работать с базой без пароля при наличии рута
нужно остановить службу и запустить ее в консоли командой
mysqld_safe --skip-grant-tables &

как импортируешь то? ты в свой скрипт не можешь вставить sleep между запросами?

львиную долю нагрузки базе данных на запись создают:
1. поддержка транзакций
2. перестройка индексов
3. средства защиты данных от сбоев
каждая запись на диск, которая по мнению базы данных должна быть произведена с гарантией, т.е. снабжается вызовом flush, но база данных не всегда знает когда это стоит делать а когда нет, частично это разруливается длинными транзакциями, вставляя между коммитами 100500 запросов на вставку

Так вот по каждому пункту можно временно изменить логику и настройки работы базы данных.
1. отключить транзакционные механизмы, перейдя от innodb к myisam, это может дать чуть ли не двухкратный прирост, но потребует в приложении как то игнорировать отсутствие поддержки транзакций, что не всегда просто сделать
2. отключить индексы, буквально, оставить только PK и то только там где это имеет необходимость только для импорта, после окончании импорта данных, индексы нужно будет вернуть. Однократное создание индексов на порядок если не два быстрее чем обновление индексов по каждой записи в базу.
3. отключить поддержку flush в операционной системе, буквально например опция монтирования ext4 data=writeback, база данных не будет ждать когда данные реально будут записаны на диск (есть еще опция O_DSYNC у mysql innodb, совет вообще полистать как тюнить дисковый io) но осторожно, если в это время произойдет краш сервера, данные будут испорчены, причем скорее всего безнадежно. В догонку, можно перенести журнал ext4 на другое более быстрое устройство или лучше совсем его отключить, так как при записи данные пишутся сначала в него потом на диск, на время импорта это лишние операции
И в догонку, если размер базы данных к примеру считанные сотня гигабайт, то можно временно арендовать в облаке машину с большим объемом RAM, залить базу в tmpfs и на максимально быстрой скорости импортировать данные, потом готовую базу залить обратно.

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

Правильно - не заводить систему entity-value где ни попадя, у вас там действительно новые типы данных появляются и меняются каждый день?
Храни значения как полагается - в таблицах и колонках

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

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

смотри

CREATE INDEX id_employees_index ( (JSON_VALUE(visits, '$.id' RETURNING UNSIGNED)) )

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

p.s. какой объем данных? не будет ли эффективнее реализовать свои таски в оперативной памяти своего отдельного приложения, и вместо базы данных пусть твой бакэенд (или кто там) лезет к этому приложений... ни одна sql база данных ни при каких условиях не будет работать быстрее, чем твое собственное приложение с данными в оперативной памяти, а уж если тебе хватит одного потока то и на разработку решения потратишь очень мало времени

а left join?

По уму правильный способ, при создании foreign key index нужно указать on delete cascade, и тогда при удалении записи в главной таблице, все связанные записи удалятся автоматически

если update запросов на порядок меньше чем запросов на select, то типовой способ ускорения последних за счет замедления update - исполнение запросов select заранее, складывая их результат в специальную табличку тригерами

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

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

partitioning

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

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