ещё варианты? 300+ rps

ну 300+ rps это в общем совсем немного, если там + не сильно большой :) но не очень понятно, что требуется. смотреть полный текст всех prepared statements? какого-то конкретного? если да, какого именно?

ну 300+ rps это в общем совсем немного, если там + не сильно большой :) но не очень понятно, что требуется. смотреть полный текст всех prepared statements? какого-то конкретного? если да, какого именно?

до 800 примерно

ну 300+ rps это в общем совсем немного, если там + не сильно большой :) но не очень понятно, что требуется. смотреть полный текст всех prepared statements? какого-то конкретного? если да, какого именно?

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

ну 300+ rps это в общем совсем немного, если там + не сильно большой :) но не очень понятно, что требуется. смотреть полный текст всех prepared statements? какого-то конкретного? если да, какого именно?

ну так-то зависит что это за read и какой сервер. Может там калькулятор))))

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

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

ну так-то зависит что это за read и какой сервер. Может там калькулятор))))

2 гига база, 62 гига сервер, 16 ядер

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

ну включить general log на минутку. ну накапает там с десяток мегабайт логов, делов-то

и ядра эти уходят в потолок в час-пик :(

@KawaiDesu если длинные запросы ловить, то настроенный slow.log ничё так помогает

тем более он включается/выключается моментально и может прямо в таблицу писать запросы больше n секунд

2 гига база, 62 гига сервер, 16 ядер

@KawaiDesu оперативы сколько?

@KawaiDesu оперативы сколько?

62

оверкилл, на самом деле

херассе

2 гига база... 62 оперативы

т.е. она всё в буфер пуле?))))

тогда у тебя либо очень тяжелые отчёты, либо что-то ещё косячит, ну нельзя так проц убить парой сотен чтений

она "два раза" в буффер пуле (он 4)

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

а не проще логгировать запросы, где индекс не используется?

там пол миллиона записей

а не проще логгировать запросы, где индекс не используется?

а как такое провернуть?

а как такое провернуть?

https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_log_queries_not_using_indexes

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

дальше включил и ищешь ещё))))

https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_log_queries_not_using_indexes

там хитрее, всего индексов 4 (вопрос к разрабам), но нужный и ультрабыстрый - один

https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_log_queries_not_using_indexes

а в перконе можно вместе с самим запросом в slow log писать ещё всякое интересное вплоть до EXPLAIN

если передали ненароком int вместо string, то индекс не подцепится, но будут задействованы другие

то есть индекс как бы есть, но не тот

а разница во времени выполнения какая?

Видимо большая. Логи можно включить не в пиковую нагрузку. Если есть массовая проблема - ты её и не в пик выловишь

я бы включил general query log на короткое время. а потом чем-нибудь его прошерстил. возможно pt-query-digest-ом, чтобы велосипед не изобретать

или audit log, но я навскидку не помню, получает audit plugin текст параметра в PS или нет

@alexey_kopytov в дженерал не будет времени

А так можно будет фильтрануть

"pt-query-digest" - это да, крутая вещь))))

@alexey_kopytov в дженерал не будет времени

времени какого?

выполнения запроса

выполнения запроса

видно, когда он завершается и закрывается соединение

Slow в твоём варианте перспективнее, сможешь отфильтровать только тяжёлые

2018-02-20T12:07:45.674900Z 42 Prepare SELECT... 2018-02-20T12:07:45.675094Z 42 Execute SELECT... 2018-02-20T12:07:45.675715Z 42 Close stmt 2018-02-20T12:07:45.676129Z 42 Quit

Это general

да

не перспективнее, они по факту отрабатывают за 0.00, когда руками пускаешь

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

проблемы лезут, если один из параметров случайно int, а не string

А в процесслисте - нет

но сейчас в логе проблемных нет

ну вот

В дженерал и не будет

лучше бы были

о, нашёл

Как работает слоу: Он СНАЧАЛА выполняет запрос, а дальше если время его выполнения большое - логирует

И пишет время выполнения

general_log подошёл, спасибо

ссаные тряпки выданы

а всё еще проще оказалось

performance_schema.threads пишет полный текст запроса даже для prepared statements

или основанная на ней sys.processlist

performance_schema.threads пишет полный текст запроса даже для prepared statements

и правда, шик, запомню

@alexey_kopytov кстати, а чего sys могла неграмотно развернуться?

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

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

не знаю, не встречал

Может просто у кого-то бекап кода взять?))))

так зачем бэкап, наверняка sql где-то лежит

должен быть в /usr/share/mysql/mysql_sys_schema.sql

Есть секционированная таблица размером в 200 ГБ, в минуту вставляется 2млн строк. В планах увеличение времени хранения. Вопрос: как можно перемещеть данные на медленное хранилище?

понял, сейчас попрошу компетентные органы пошерстить. А то распределение ролей, мать его, к сервакам только как MYSQL-клиент хожу и никак иначе

Есть секционированная таблица размером в 200 ГБ, в минуту вставляется 2млн строк. В планах увеличение времени хранения. Вопрос: как можно перемещеть данные на медленное хранилище?

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

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

Верно, текушие данные на быстрые диски, вчерашние на медленное хранилище

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

можно в пределах одного сервера

Верно, текушие данные на быстрые диски, вчерашние на медленное хранилище

я бы делал так: 1. создаём пустую таблицу на том же устройстве. 2. обмениваем нужную партицию и пустую таблицу, как написано здесь: https://dev.mysql.com/doc/refman/5.7/en/partitioning-management-exchange.html

это будет быстро, потому что всё на одном устройства

3. переносим отдельную таблицу с данными на нужное устройство с помощью FLUSH TABLES FOR EXPORT, например. или на другой сервер, не важно

4. удаляем пустую партицию в исходной таблице

т.е. в архиве будет много таблиц вместо партиций?

т.е. в архиве будет много таблиц вместо партиций?

не обязательно. можно тем же методом (exchange partition) подшивать их в одну архивную таблицу

не обязательно. можно тем же методом (exchange partition) подшивать их в одну архивную таблицу

Благодарю) Осталось автоматизировать

Ikuti tautan ini untuk bergabung ke grup WhatsApp saya: https://chat.whatsapp.com/Fl6na9Bfw3L5n70oclUNmF

Ikuti tautan ini untuk bergabung ke grup WhatsApp saya: https://chat.whatsapp.com/Fl6na9Bfw3L5n70oclUNmF

/spam@spam_kill_robot

Подскажите. При поиске максимального элемента mysql использует индекс? Например я ищу последний элемент по полю типа timestamp и сейчас судя по explain база индекс по timestamp не использует

/spam@spam_kill_robot

/spam@spam_kill_robot

Подскажите. При поиске максимального элемента mysql использует индекс? Например я ищу последний элемент по полю типа timestamp и сейчас судя по explain база индекс по timestamp не использует

Зависит от запроса.

Подскажите. При поиске максимального элемента mysql использует индекс? Например я ищу последний элемент по полю типа timestamp и сейчас судя по explain база индекс по timestamp не использует

вроде должен. btree знает кто больше кого. покажи запросос

Ребят, всем привет! Как лучше поступить, если есть таблица на 2кк, из нее надо выдернуть подходящие строки по регексу, объем по итогу - примерно 0,5кк. Через HeidiSQL пару часов выполнялся запрос, потом при попытке импорта выбивало ошибку