Очень низкая производительность MySQL на NAS - PullRequest
Новая
       17

Очень низкая производительность MySQL на NAS

0 голосов
/ 22 сентября 2018

Я только что получил себе Asustor NAS для управления моими видео, фотографиями, музыкой и т. Д. Имея рабочий стол и ноутбук в доме, я подумал, что было бы неплохо настроить мою базу данных на NAS (которая уже поставляетсяс предустановленной MariaDB).

Настройка: RAID 1, макс. скорость чтения около 110 МБ / с с диска, подключенного через 1,3 Мбит / с WiFi с гигабитным соединением.Получение около 60 МБ / с с использованием BlackMagic Benchmark.

Запрос: 

    SELECT items.title, items.discount, items.qtd, items.price,  ((price * qtd) - discount) AS total, DATE_FORMAT(orders.created_at, '%m-%y')
    FROM items
    INNER JOIN orders ON orders.order_id = items.order_id
    ORDER BY created_at;

Таблица orders содержит около 1,8 тыс. Строк, таблица items - около 4,7 тыс. Строк.Запрос затрагивает 5 тысяч строк и занимает от 4,8 до 7,0 секунд, что кажется абсурдом для такого простого запроса.Раньше я выполнял тот же запрос на моем локальном хосте (хорошо, это SSM NVMe, который я получаю намного быстрее), за миллисекунды.order_id - это VARCHAR, содержащий около 10 символов.

Потребовалось около 7 (9 последних раз) минут, чтобы вставить все данные во все таблицы: 

`orders` - 1.7k rows, 11 columns
`items` - 4.8k rows, 12 columns
`customers` - 1.7k rows, 9 columns

Мой вопрос:

  1. Это действительно так плохо с производительностью, или я получаю неправильный тест производительности после использования SSM-накопителей NVMe?
  2. Если это действительно плохо, что я могу сделать, чтобы улучшитьэто (все еще хостинг моей БД на моем NAS)?
  3. Чего можно ожидать с точки зрения производительности в размещенной в Интернете базе данных?

Большое спасибо. 

**Tables:**
`CREATE TABLE `orders` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `order_id` varchar(15) DEFAULT NULL COMMENT 'VA',
  `created_at` datetime DEFAULT NULL,
  `gateway` varchar(25) DEFAULT NULL,
  `total` decimal(15,0) DEFAULT NULL,
  `subtotal` decimal(15,0) DEFAULT NULL,
  `status` varchar(20) DEFAULT NULL,
  `discounts` decimal(15,0) DEFAULT NULL,
  `total_price` decimal(15,0) DEFAULT NULL,
  `order_number` varchar(15) DEFAULT NULL,
  `processing` varchar(15) DEFAULT NULL,
  `customer_id` varchar(15) DEFAULT NULL,
  `number` varchar(15) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `number` (`number`),
  UNIQUE KEY `order_id` (`order_id`),
  KEY `customer_id` (`customer_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1712 DEFAULT CHARSET=utf8;`

1 Ответ

0 голосов
/ 22 сентября 2018
  1. Это действительно так плохо с производительностью, или я получаю неправильный тест производительности после использования SSM-накопителей NVMe?

Да, это плохая производительность.Правильная индексация для запроса будет частично способствовать решению проблемы производительности запроса.Добиться, чтобы NAS использовал innodb_buffer_pool и свободную память в качестве дискового кэша, будет сложно, если на борту будет всего 512M.

Если это действительно плохо, что я могу сделать, чтобы улучшить его (по-прежнему размещая свою БД на своем NAS)?

Корректная индексация таблиц с помощью объединения и порядка.Изменения дизайна для использования целочисленных первичных ключей для объединений.В качестве первого шага, если order_id на самом деле не utf8 и просто латиница 1 изменяется для этого столбца, что приведет к уменьшению ключа, можно также изменить его на первичный ключ.

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

Чего можно ожидать в плане производительности для размещенной в сети базы данных?

Размещаемая база данных предложит больше оперативной памяти и, возможно, более быстрый процессор.

...