Explain delete?

mysql> explain delete  from db.table where id =32554989;
+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+
| id | select_type | table  | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra       |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+
|  1 | DELETE      | events | NULL       | range | PRIMARY       | PRIMARY | 8       | const |    1 |   100.00 | Using where |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+

Проблема - массовые инсерты и делиты. Ловим под нагрузкой LOCk WAIT timeout'ы

А транзакция только один этот запрос выполняет? Или, например, 31585 :)

хм, действительно. Спасибо Света, посмотрим:)

https://www.percona.com/blog/2018/06/05/call-for-questions-webinar-with-mysql-benchmarking-experts/

Хочу как минимум @alexey_kopytov на этом вебинаре. Шлите вопросы!

Отправлю чтоль нашего парнишку который как бенчмарками нового железа и 5.7 у нас начал заниматься, спасибо

@svetsmirnova а сейчас есть более живое по типу anemometer ?

@naimson PMM query analyzer https://pmmdemo.percona.com/graph/d/yq6Vsv4ik/_pmm-query-analytics?from=now-12h&to=now&orgId=1&var-host=ps57

Всем привет! Кто знает на что можно обратить внимание при работе с параметрами

binlog_group_commit_sync_delay
binlog_group_commit_sync_no_delay_count 

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

@acromegale на то что sync_binlog не ноль, и на желаемое количество запросов в секунду. Если на мастере одновременно работают N запросов DML (или коммитится N транзакций с изменениями), то мастер не сможет выдавать больше чем (binlog_group_commit_sync_delay * N / 1e6) транзакций в секунду. Если известно что для производительности слейва будет достаточно M slave_parallel_workers, то binlog_group_commit_sync_no_delay_count  можно выставить в M, тогда вслески запросов на мастере будут позволять не ждать полную задержку binlog_group_commit_sync_delay us.

Если sync_binlog > 1, это это значит, что под одновременным запросом мы понимаем sync_binlog запросов.

Я бы смотрел насколько нагружен сервер по Threads_running и по Handler_commit (или сумме Com_* относящихся к DML). Если лень думать и сервер загружен на 100% DML, то можно принять N и M за количество ядер.

для любого неизвестного сервера нельзя посоветовать правильных значений: будет или слишком маленькая параллельность или затормозят коммиты на мастере.

trx_commit может быть 2 при работающем group commit: https://blogs.oracle.com/mysql/mysql-56-replication-performance

Спасибо за развёрнутый ответ, будем посмотреть)

ребята, подскажите как делать миграцию БД? не имел дел с этим ни разу - хочется пообщаться на эту тему с кем-то имеющим опыт

@Sashasunq если с mysql на mysql, то проще всего поднять репликацию, переключить приложение на новый сервер, выключить старый сервер
Если между разными базами данных, то чаще всего проблемы появляются в приложении (синтаксис запросов, stored procedures на java/python) и общего решения не будет. Если приложение стандартное (не самописное) и поддерживает разные базы, то или надо останавливать приложение, конвертировать дамп в sql в нужный диалект, заливать в целевую базу и стартовать приложение или пользоваться репликациями типа goden gate/ tungsten replicator такие решения (между базами) почти всегда платные, без исходников.

между postgre и aurora postgre

используя репликейшн машинку

Привет, я в MySQL чуть более чем новичок - 3 года пользуюсь всего. Подскажите, если у меня база переваливает за 13-15 миллионов записей, сама таблица на 8 колонок, одна из которых текстовая (TEXT, индекс FULLTEXT и поиск), и две VARCHAR (по ним поиск тоже часто бывает) - таблицу эту стоит бить на несколько таблиц? как добится от нее максимально высокой скорости поиска?

я слышал такую таблицу превращают в связь много-ко-многим
id, param_id, value