Soniked, тогда действительно странно, у вас только 1 таблица в БД? Если обращаетесь только к 100тыс, то только они и должны лежать в buffer pool, с индексами примерно также. Конечно, если запросы действительно так работают, а не перелопачивают все данные.
Для начала, посмотрите сколько занимают места на диске все таблицы и индексы, и что пишет стандартный монитор InnoDB.
mayton2019, специализированное решение которое подходит для "крупной торговой сети косметических
магазинов США" совершенно не обязательно подходит для всех проектов.
И, как правильно заметил Ипатьев, у автора просто не получается сформулировать реальную задачу, а значит все варианты сейчас это просто гадание. Soniked, не надо писать как вы хотите решать неизвестную нам задачу, напишите саму задачу, чего вы хотите добиться. По последнему комментарию, можно предположить, что вам жалко оперативы для MySQL и вы хотите уменьшить ее потребление. Тогда установите размер buffer pull таким, каким хотите его видеть. И только после этого, если окажется, что MySQL его не хватает (т.е. появятся постоянные чтения с диска), вот тогда и нужно будет искать решение.
ThunderCat, т.е. вполне себе можно нормализовать структуру в вордпрессе? Фраза про смешно была не в смысле что это невозможно, а в том, что в вордпрессе мало кто так делает? Ок, тогда понял вас, спасибо.
ThunderCat, понятное дело, что вариант плохой, но делать то что? Нормализовывать вы пишите смешно, но именно это и предлагаете.
Индексы не панацея, не всегда в таблице миллионы данных, а фуллскан может быть очень быстрым на нескольких десятках тысяч, т.к. просмотреть последовательно все страницы проще, чем бегать по индексу и выбирать по id каждую строчку. Да и оптимизатор в любой СУБД далеко не идеален, и ошибается он достаточно часто. Но, конечно, можно забить на эти "мелочи" и делать всегда стандартно, выбирая не лучший вариант, но работать будет.
ThunderCat, отличное описание, но это и так понятно, мой вопрос был в другом, если это не вордпресс сделал, значит плагин, но даже так, значит в плагине должны быть инструменты для десериализации и подготовки объекта в адекватном виде. И, тогда этим инструментом и надо воспользоваться. Да, придется забрать все записи, но они хотя бы будут уже в адекватном виде, и автор сможет по ним искать. Быть может их не так много, и автору этого будет вполне достаточно.
Не говоря уже о том, что "полный прямой перебор всех записей, минуя индексы бд" не всегда худший сценарий, а бывает, что наилучший. Проблема указанных запросов не в этом, а в использовании функций regexp или like, вот они действительно сильно замедлят фильтрацию.
Пока звучит как "в нашей микросервисной архитектуре мало сервисов и мы решили запилить еще". Т.к. непонятно что это за сервис и с чего он вдруг понадобился, как это все связано с хранением в других сервисах и т.п. Быть может это какая-то бессмысленная хрень, а может это чтото вроде DWH, но текущего описания для понимания совсем недостаточно.
ThunderCat, дада, добродушный смех на Тостере. Я честно хз, как там wordpress делает, но логично предположить тогда, что автор просто не так как нужно получает данные. Раз ему они приходят сырые, а не уже обработанные. Тут то бы кто подсказал.
Zailox, разумеется либо-либо, загузчик не может передать управление сразу 2м процессам. Используйте openrc как init, и в нем запускайте свой скрипт, как IvanU7n и написал. Openrc судя по доке и inittab и еще куча конфигов есть.
Shimpanze, я про то, что пока неизвестна задача, может и не так, и не это нужно.
Из предыдущей задачи, я так понял, нужно просто знать входит ли значение в массив. Для этого достаточно функции in_array, без всякого преобразования массива.
И только если она будет долго отрабатывать, и есть время на преобразование массива, тогда можно использовать хеш-таблицу, но здесь лучше сделать массив вида: [ 'foo'=>1, 'bar'=>1, ... ], и по нему проверять только существование ключа через array_key_exists.
Shimpanze, ну вы сами прикиньте, вместо того, чтобы работать напрямую с массивом, вы используете прослойку в виде объекта. Соответственно гораздо больше памяти, и медленней.
Михаил Р., кому как, если не занимаетесь ежедневно перехватом и модернизацией запросов по разным протоколам, то универсальный инструмент вроде Fiddler не особо то и нужен, и узко специализированное решение будет проще.
Александр Вялых, извиняюсь, если ввел в заблуждение, проверил, да, вы и alexalexes правы, еще в 7ке zval перетащили в bucket, а bucket в arData. А я то считал, что как раньше данные php-шного массива лежат отдельно. А так, у нас один сишный массив на который ссылается хештаблица, и прям в нем лежит zval (понятно, что zval не обязательно уже данные, но все же).
Т.е. при rehash, необходимо перестроить хештаблицу и не просто массив с указателями, а массив со сложной структурой. Одно дело скопировать массив с интами, а другое дело с структурой, где только интов целая гора. Но, видно это меньшее из зол.
Для начала, посмотрите сколько занимают места на диске все таблицы и индексы, и что пишет стандартный монитор InnoDB.