hdd или ssd?

iostat -x 1 при записи чтл показывает?

я так могу консультировать: https://www.percona.com/store/mysql-essentials-support

> Запросы уже оптимизировал
Важно оптимизировать не все запросы, а только те, которые создают большую часть нагрузки (обычно, когда нет постоянного ревью запросов, это 3-5 запросов). Сами запросы могут быть очень быстрыми, но отъедать большую часть процессора. Кроме performance schema и statement_analysis ещё можно использовать slow log с полным логгированием и pt-query-digest (утилита из percona toolkit).
Если есть большое количество маленьких запросов и возможно кеширование, то можно кешировать в in-memory базе (redis, tarantool) или прозрачно в proxysql https://www.percona.com/blog/2018/02/07/proxysql-query-cache/ )

При хорошем кешировании, к базе будут обращения в очновном только на запись. Это похоже на нагрузки фейсбука и стоит смотреть в сторону MyRocks.

В любом случае, если уже встаёт вопрос о производительности и MySQL надо сильно задуматься о миграции на Linux. Там больше инструментов и выше производительность.

привет, я ща по ходу туплю, можете подсказать
есть таблица mails в которой поля from и to (в них id)
нужно вытащить все где есть, например 1

типо
select * from mails where from = 1 or to = 1

"типо" всю почту юзера

от from до to больше одного дня? если меньше, то https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_dayofweek

ой отправилось случайно я еще не дописал

Советуете обратиться мне в percona или возможна консультация от вас на таких условиях?
В качестве in-mem-db для быстрой работы в некоторых проектах использую h2 db. Рассматривал вариант хранить данные за час в in-mem и каждый час сохранять их в хранилище. Но возникают вопросы по сохранности данных. Рекомендованные вами варианты видел, но подробно пока не рассматривал.

я работаю в percona и такую работу по контракту могу только там делать.

Понял👌🏻👍🏻

А можно как-то адекватно оценить объем нагрузки бд к железу? Какие для этого есть инструменты? Чтобы уверенно понимать что дело в плохой оптимизации, а не недостаточно сильном сервере.

Мне бы просто оценить объем трудозатрат к стоимости апгрейда)

через mysqladmin ext -i 1 -c 30 можно получить 30 раз запущенный SHOW GLOBAL STATUS. этот вывод обработать bash скриптом

pt-mext -r -- cat status.txt

в полученном файле - первый столбец название переменной статуса, второй - количество с последнего рестарта, третий и далее изменение за секунду.
в Handler_% сидит статистика по движку хранения (innodb скорее всего только у вас), описание по этим переменным тут https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Handler_read_rnd_next

И дальше надо смотреть: если read_rnd_next почти нет и read_key по количество не в сотни тысяч раз меньше чем read_prev+read_next и order by/group by мало/нет, то индексами много не сделаешь (rnd_next это полное сканирование таблички, read_key это чтение первой записи из индекса, read_next/prev это сканирование индекса). Если мы уже 1-10к строчек всегда берём из базы и сканируем только их, значит индексы уже хорошие.
Обычно на одно ядро CPU в вакууме InnoDB может прокачивать от 1М до 4М строчек (вызовов Handler) в секунду. Handler_write часто меньше - 100к-1М. Это приблизительные наблюдения для нормальных average row length (100b-4KB)

Sort_rows, Sort_scan, Sort_range, Sort_merge_passes если много, то надо посмотреть запросы с order by group by на предмет нужных индексов.

На ревью 3-5 самых тяжёлых запросов обычно уходит неделя. Результат, в зависимости от запущенности может дать снижение нагрузки в 3-10 раз. Настолько крутые сервера даже купить сложно.

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

Трафик сетевой на сервере низкий, селектов не так много, я бы поставил на то, что 1-2 тяжёлых селекта делают всю нагрузку на CPU. Тем более что нулевое Innodb_data_reads в секунду (если я правильно понимаю ваши графики), говорит о достаточном размере buffer pool. К сожалению, я не знаю: 94% это процент использования CPU по всем ядрам или только по одному (может быть больше 100%?). Каждый запрос в MySQL может использовать не более одного ядра процессора, и если select работает 30 секунд, одно ядро процессора будет загружено на 100% в течении 30 секунд.

если есть сервер с docker, можно поставить Percona Monitoring and Management (штука основанная на grafana, открытый код, бесплатная) и там уже добавить ваш сервер mysql и посмотреть и запросы в query analytics и статистику типа Handler% в виде графиков.

Спасибо большое, очень интересная информация!

Доброго дня, подскажите это верный синтаксис для добавления внешнего ключа?

ALTER TABLE news ADD FOREIGN KEY (language_id) REFERENCES languages(id);

типы данных у language_id совпадают?
id - это primary key?
Все ли значения new.language_id есть в languages.id

?

да

https://www.percona.com/blog/2017/04/06/dealing-mysql-error-code-1215-cannot-add-foreign-key-constraint/

пробегитесь по списку

ок, спасибо