К каким данным относятся системные переменные MariaDB, например, innodb_log_buffer_size

Question

Многие системные переменные MariaDB определяют максимальные размеры данных, и мне не ясно, какие именно данные измеряются, в контексте операций записи, когда я отправляю много данных через JDBC, например:

innodb_buffer_pool_size= 24696061952

и

innodb_log_buffer_size= 8388608

и

max_allowed_packet= 562036736

Я использую эталонный тест, где я вставляю, обновляю или удаляю 50000 строк с 2 МБ необработанных данных, то есть даты и двойных данных.

Итак, когда MariaDB реализует эти заданные переменными пределы, он смотрит на необработанное значение параметров, передаваемых по проводам, или включает в себя также всю строку SQL?

то есть он измеряет просто

2012-01-01,0.1234
2012-01-02,0.4321
2012-01-03,0.9999
...

или учитывает байты в строке SQL:

UPDATE data SET value = 0.1234 WHERE date = '2012-01-01'
UPDATE data SET value = 0.4321 WHERE date = '2012-01-02'
UPDATE data SET value = 0.9999 WHERE date = '2012-01-03'

, что в этом примере, очевидно, в 2-3 разабольше?

Answer 1

Innodb_log_buffer_size

Это относится к чему-то внутреннему.транзакции регистрируются в журнале повторов (ib_logfile0 / ib_logfile1).записи журнала повторов буферизируются в буфере журналов повторов, пока транзакция не завершится. Формат записей журналов повторов не задокументирован, а также может изменяться между версиями.Вы можете увидеть, сколько записано в журнал, наблюдая за изменениями переменной состояния innodb_os_log_written .

 MariaDB [test]> show global status like 'innodb_os_log_written';
 +-----------------------+-------+
 | Variable_name         | Value |
 +-----------------------+-------+
 | Innodb_os_log_written | 12800 |
 +-----------------------+-------+
 1 row in set (0.00 sec)

innodb_buffer_pool_size

Ваши данные крошечные, а буферный пул достаточно большой.Буферный пул - это то, как innodb кэширует данные.Если ваши данные больше, чем буферный пул, чего нет в вашем случае, Innodb придется чаще читать с диска.Поэтому оставьте все как есть, или вы можете уменьшить его.

max_allowed_packet

Это всего лишь мера безопасности, пытающаяся предотвратить DDOS.Если отправлять очень большие пакеты, они заставляют сервер выделять больше памяти и, возможно, исчерпывают память.Но если вы не отправляете большие пакеты, сервер не выделяет много памяти, и если вы не боитесь DDOS, вы можете получить его размером до 1G.

Чтобы понять, сколько данных было отправлено или получено на стороне сервера, вы можете посмотреть переменную состояния

MariaDB [test]> show status like 'bytes%';
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| Bytes_received | 570   |
| Bytes_sent     | 1716  |
+----------------+-------+
2 rows in set (0.00 sec)

Как это соответствует размеру отправляемых данных?Там не всегда прямой ответ.

• Заявления, которые не подготовлены (на стороне сервера)

  Если вы просто отправите неподготовленные запросы, вы отправите заголовок пакета 4 байта + 1 байт для команды (COM_QUERY)) + ваша строка запроса SQL.если ваш запрос больше 16M, он будет разбит на несколько пакетов, и на каждый пакет будет накладываться 4 байта.

• Операторы, подготовленные на стороне сервера.

  С инструкциями, подготовленными на стороне сервера, это сложнее.Каждый тип данных имеет свою собственную кодировку., поэтому целые числа не отправляются как текст, ни плавающие, ни даты.строки по-прежнему отправляются в виде строк.Как правило, объем отправляемых данных будет немного меньше (в конце концов, вы не отправляете команды SQL, только данные).

• Оптимизация для отдельных пакетов

  MariaDB 10.2Сервер и JDBC также имеют оптимизацию для отправки нескольких данных для одного подготовленного оператора.Это может уменьшить количество данных, отправляемых клиентом (немного), но объем данных, полученных клиентом, будет значительно уменьшен, это всего лишь один пакет для всех команд, а не по одной на команду.Эта оптимизация еще не работает для DELETE.

Для пакетирования операторов, которые не подготовлены на стороне сервера, JDBC имеет еще одну оптимизацию, которая преобразует множество похожих запросов INSERT в одинmulti-insert, который также уменьшает количество отправленных и полученных байтов, но это только INSERT (теперь есть задача , чтобы сделать что-то подобное для DELETE)