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

теперь мне можно удалиться с канала? ИЛи меня просто забанят? )))

теперь мне можно удалиться с канала? ИЛи меня просто забанят? )))

да, но зачем?

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

не ради этой инфы я сюда пришел (

ясен красен

шиза какая

еррор 13 - это пермишн денайд...

Кому-то знакомо где я туплю конкретно? )

Кому-то знакомо где я туплю конкретно? )

а это скорее apparmor или selinux, которые сконфигурированы, чтобы mysqld имел доступ только к ограниченным директориям. и /home/mysqltmp в этот список очевидно не входит

можно настроить apparmor/selinux, или вообще их отключить, если security не важна

а можно попробовать симлинк в /tmp/mysqltmp на /home/mysqltmp

но повторю, это всё затыкание дыр. временные таблицы на 4G — так себе идея в любом случае. особенно на слабенькой машинке, как я понимаю

а это скорее apparmor или selinux, которые сконфигурированы, чтобы mysqld имел доступ только к ограниченным директориям. и /home/mysqltmp в этот список очевидно не входит

спасибо, пробую

Привет всем, есть поле VARCHAR в таблице, которое содержит id через запятую: Example: 45,56,78, Нужно произвести поиск по таблице, у меня есть массив [45,69], который указал пользователь при поиске. Подскажете как составить запрос, чтобы он учитывал этот массив и выдал в итоге подходящие результаты

Привет всем, есть поле VARCHAR в таблице, которое содержит id через запятую: Example: 45,56,78, Нужно произвести поиск по таблице, у меня есть массив [45,69], который указал пользователь при поиске. Подскажете как составить запрос, чтобы он учитывал этот массив и выдал в итоге подходящие результаты

where field_name like "%45%" OR field_name like "%69%" ?

where field_name like "%45%" OR field_name like "%69%" ?

если будет в базе 456,670,75, - то под ваш запрос это тоже проходит

если будет в базе 456,670,75, - то под ваш запрос это тоже проходит

если у вас формат записи "id," - с запятой, то добавьте её

если будет в базе 456,670,75, - то под ваш запрос это тоже проходит

where field_name like "%45,%" OR field_name like "%69,%"

если будет в базе 456,670,75, - то под ваш запрос это тоже проходит

а вы про тип поля енум слышали?

where field_name like "%45,%" OR field_name like "%69,%"

тогда при поиске по id=5 "45,%" - проходит

а с двух сторон тогда первое значение из строкине подойдет

сработает, если формат будет: ,56,67,9,9,

и поиск делать с двумя запятыми, спасибо

а вы про тип поля енум слышали?

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

сработает, если формат будет: ,56,67,9,9,

ну формат, как раз и нужен для поиска )

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

попробуйте действительно добавить просто запятую

Добрый день! Есть у кого опыт активации jemalloc на percona server 5.7.20 ? В оф. источниках написанно, что нужно просто установить и перезапустить сервер. Гуд, так и сделано, но при проверке получаем "#pt-mysql-summary | grep -A5 -i "memory management" # Memory management library ################################## jemalloc is not enabled in MySQL config for process with ID 1997 # The End####################################" Пробовал прописать в my.cnf "malloc-lib = /usr/lib64/libjemalloc.so.1" Не заработало. Может кто подсказать что не так и куда копать?

по идее просто надо в LD_PRELOAD добавить jemalloc

я темнота, чет никак вникнуть не могу. Что такое LD_PRELOAD я уже проситал, но вот как с помощью LD_PRELOAD осилить jemalloc, пока нет.

LD_PRELOAD="/usr/lib/блабла/libjemalloc.so" mysqld

типа того

хм.... и ничего. Результат тотже

а как проверяешь?

pt-mysql-summary | grep -A5 -i "memory management

стоит Percona Toolkit

Кто знает, как найти в json поле все пути с заданным ключом?

Нужно найти $.someKey[*].foo и удалить его

Из всех объектов массива someKey выпилить ключ foo

Кто знает, как найти в json поле все пути с заданным ключом?

json_keys с заданным path сформирует массив путей, дальше удаляешь в цикле

по-другому наверное никак...

Да я уже сделал по аналогии, всего за 241 элегантный запрос удаляю нужные ключи.

Люблю json в базе ❤

элегантно.

)

обманул, json_keys не поможет(

есть json_search, но он работает только со строковыми представлениями, и если у тебя json сохранен бинарем а не строкой - найдет не все есть json_contains_path, но это тоже цикл будет

грусть в общем

Непонятно почему не работает * в json_remove, почему-то отключили такую возможность.

видимо потому что это потенциальный способ выстрелить себе в колено

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

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

сначала будет использовано уже распределённое место, т.е. размер файла первоначально расти не будет. (место на диске после удаления данных из таблицы не освобождается само. можно попробовать optimize table (myisam) либо любой alter table (innodb))

Да, спасибо!

а подскажите как работает индекс в случае с сортировкой к пример есть запрос select A, B, C from table where A = 20 and B = 10 order by C к примеру, если я сделаю индекс (B, A) то он будет работать оптимальнее (колонка B существенно сужает дальнейшую выборку) а вот как в составном индексе работает сортировка - не понимаю, то есть если я сделаю индекс с очередностью B, A, C будет ли это верным решением?

проверяйте через explain

сделайте 2 индекса, и смотрите через EXPLAIN какой выгоднее

Заодно подскажите мне, почему в slow.log я постоянно наблюдаю один и тот же запрос. разве он не должен попадать в кеш запросов?

Заодно подскажите мне, почему в slow.log я постоянно наблюдаю один и тот же запрос. разве он не должен попадать в кеш запросов?

зависит от того, какой запрос, возможно просто логгируются все запросы, которые не юзают индекс, то есть стоит log_queries_not_using_indexes = true

Query_time: 3.811641 Lock_time: 0.000059 Rows_sent: 8357 Rows_examined: 2381048

он явно по времени выполнения попадает в лог

ну значит он медленный ?

ну и сам запрос: SELECT feature_value_id, COUNT(*) FROM shop_product_features pf JOIN shop_product p ON pf.product_id = p.id WHERE pf.feature_id = 4 AND pf.sku_id IS NULL AND p.status = 1 GROUP BY pf.feature_value_id;

ну как выше сказал - смотри EXPLAIN

профилируй

я уже и так, и сяк смотрел, все-равно долго получается

даже просто SELECT feature_value_id FROM shop_product_features WHERE feature_id = 4; перебирает кучу строк

запостил ниже картинкой

почему он перебрал 1771760 строк, если их всего 1006617 нужных?

а подскажите как работает индекс в случае с сортировкой к пример есть запрос select A, B, C from table where A = 20 and B = 10 order by C к примеру, если я сделаю индекс (B, A) то он будет работать оптимальнее (колонка B существенно сужает дальнейшую выборку) а вот как в составном индексе работает сортировка - не понимаю, то есть если я сделаю индекс с очередностью B, A, C будет ли это верным решением?

Будет. Важно только чтобы у тебя с локапа первого префикса отсеивалось максимально возможное число строк

то есть третий ключ в индексе все-равно будет отрабатывать, несмотря на очерденость?

то есть третий ключ в индексе все-равно будет отрабатывать, несмотря на очерденость?

применительно к select A, B, C from table where A = 20 and B = 10 order by C да

понятно, спасибо

индекс в память влезает? что профилирование говорит?