rPman

Akina абсолютно прав, но в качестве ответа - одним из простых критериев похожести может быть отличие в количестве символов (известный алгоритм levenstein)
вот статья с примерами и реализациями на mysql
для postgres есть штатная реализация но нативные индексы так и не поддерживаются

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

если количество не велико (точнее разумно) можно симулировать таблицу с возрастающими значениями на основе union и left join

p.s. это адский быдлокод но я помню делал такую вьюху

create view digits (a) as select 0 as a union
select 1 union
select 2 union
select 3 union
select 4 union
select 5 union
select 6 union
select 7 union
select 8 union
select 9

соответственно дальше можно написать такой запрос

select x.a+y.a*10+z.a*100 from  digits x,digits y,digits z

количество указаний digits во from в нем определит максимальное количество значений (в данном случае 1000) как степень 10

Можно создать из этого ее вьюху, и на ее основе уже оперировать степенями 1000

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

последовательно выполнить
insert into new_table select from old_table
если в таблице есть foreign key индксы ли другие constraint, которые могут препятствовать простому их копированию, то отключаешь их перед копированием (для innodb придется удалять и позже создавать заново, для myisam есть метод alter table ... disable keys)

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

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

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)) )