У нас есть два одинаковых сервера с жесткими дисками CentOS 7 для двух разных клиентов в разных странах, у обоих клиентов одна и та же база данных и одинаковые индексы.
Хранилище MySQL для клиента B находится на NAS, который имеет интерфейс 1 ГБ с сервером и скорость ввода-вывода 5 МБ / с. На NAS выполняются только чтение / запись. Причина в том, что на сервере установлен небольшой жесткий диск, 250 ГБ. Может быть, это причина того, что он такой медленный?
Обратите внимание: если в запросе нет соединений, он выполняется быстро, а если в нем есть соединения, это не так. Может быть, NAS пытается что-то кэшировать?
Какова ваша модель чтения / записи?
Если вы записываете много небольших записей, дисковая и сетевая задержка - ваш враг, а NAS добавляет уровень двусторонней сетевой задержки.
В зависимости от вашего NAS вы также можете страдать от усиления записи (например, если ваша база данных считает, что блоки составляют 8 КБ, а блоки NAS - 64 КБ).
Это меньшая проблема с чтениями, потому что данные кэшируются на сервер, но записи заставляют вас немедленно платить налог за задержку.
На современных компьютерах задержка является основной проблемой.
https://blog.morizyun.com/computer-science/basic-latency-comparison-numbers. html
интерфейс 1 ГБ с сервером и скорость ввода-вывода 5 МБ / с
5 МБ медленнее по каналу 1 ГБ.
сервер имеет небольшой жесткий диск, 250 ГБ.
Это удобный размер для Windows Server, но какая часть бесплатна для использования?
Windows действительно не любит нехватку места на диске, особенно с учетом того, что часть этого пространства передана файлу подкачки (подкачки)!
Сколько памяти (RAM) у этого сервера доступно?
если в запросе нет объединений, выполняется быстро, но если в нем есть объединения, это не ...
Объединения не делают медленный запрос ... если только эти объединения не не должным образом поддерживается индексами.
Мы все предполагаем, что ваш запрос в основном
select * from table1 ;
, что будет медленным, потому что он должен тянуть каждую страницу данных через этот [медленное] сетевое соединение в память и затем передать его клиентскому приложению. Когда вы начинаете добавлять предложения «where» на основе индексированных полей, тогда MySQL может начать делать что-то более умное.
Нам было бы полезно увидеть фактический запрос, который вы выполняете, и структуры таблиц, которые он использует .
. Обратите внимание, что если в запросе нет соединений, он выполняется быстро, а если в нем есть соединения, это не так. Может быть, NAS пытается что-то кэшировать?
В этом случае я сначала рассмотрел бы неоптимизированную схему, замаскированную более умным алгоритмом, - MySQL 8 отсутствует в MySQL 5.7 или не может использоваться в других настройках.
выполняете соединение, у вас обычно должен быть index. Затем база данных просканирует одну из таблиц и выберет совпадающие строки из другой, используя индекс.
Если вы этого не сделаете, база данных может сортировать таблицы по столбцу соединения, в памяти, и объединить их, или построить в-временный индекс памяти при условии, что
В противном случае он просто возвращается к O ( n ²), и это убийца производительности для больших таблиц.
Итак, я предполагаю, что для более нового сервера выполняются три вышеуказанных условия, и он оптимизирует запрос, но для старый, у некоторых из них нет, и он запускает два вложенных полных сканирования.
Поэтому я сначала использую EXPLAIN , чтобы убедиться, что запросы используют индексы, и создать соответствующие индексы, если они не .