MySQL 8.0 принес огромные изменения и модификации, которые были выдвинуты Oracle MySQL Team. Физические файлы были изменены. Например, * .frm, * .TRG, * .TRN и * .par больше не существуют. Было добавлено множество новых функций, таких как CTE (общие табличные выражения), оконные функции, невидимые индексы, регулярные выражения (или регулярные выражения) — последнее было изменено и теперь обеспечивает полную поддержку Unicode и является многобайтовой безопасностью. Словарь данных также изменился. Теперь он включен в словарь транзакционных данных, в котором хранится информация об объектах базы данных. В отличие от предыдущих версий, словарные данные хранились в файлах метаданных и нетранзакционных таблицах. Безопасность была улучшена с новым дополнением caching_sha2_password, который теперь является аутентификацией по умолчанию, заменяющей mysql_native_password, и предлагает большую гибкость, но ужесточенную защиту, которая должна использовать либо защищенное соединение, либо незашифрованное соединение, поддерживающее обмен паролями с использованием пары ключей RSA.
Со всеми этими классными функциями, улучшениями, улучшениями, которые предлагает MySQL 8.0, наша команда заинтересовалась, чтобы определить, насколько хорошо работает текущая версия MySQL 8.0, особенно учитывая, что наша поддержка версий MySQL 8.0.x в ClusterControl находится в процессе (так что следите за обновлениями). на этом. В этом посте не будут обсуждаться возможности MySQL 8.0, но мы намерены сравнить его производительность с MySQL 5.7 и посмотреть, как она улучшилась.
Для этого теста мы намерены использовать минимальную настройку для производства с использованием следующей среды AWS EC2:
Есть несколько переменных, которые мы установили для этого теста, а именно:
Остальные переменные, устанавливаемые здесь для обеих версий (MySQL 5.7 и MySQL 8.0), уже настроены ClusterControl для своего шаблона my.cnf.
Кроме того, пользователь, которого мы здесь использовали, не соответствует новой аутентификации MySQL 8.0, которая использует caching_sha2_password. Вместо этого обе версии сервера используют mysql_native_password, а переменная innodb_dedicated_server имеет значение OFF (по умолчанию), что является новой функцией MySQL 8.0.
Чтобы упростить жизнь, мы настроили узел версии MySQL 5.7 Community с ClusterControl с отдельного узла, затем удалили узел в кластере и выключили узел ClusterControl, чтобы сделать узел MySQL 5.7 бездействующим (без трафика мониторинга). Технически, оба узла MySQL 5.7 и MySQL 8.0 неактивны, и через них никакие активные соединения не проходят, так что это по сути чистый тест бенчмаркинга.
Для этой задачи sysbench используется для тестирования и моделирования нагрузки для двух сред. Вот следующие команды или сценарий, используемые в этом тесте:
#!/bin/bash
host=$1 #host192.168.10.110 port=3306 user='sysbench' password='@MysqP@66w0rd' table_size=500000 rate=20 ps_mode='disable' sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --threads=1 --max-requests=0 --time=3600 --mysql-host=$host --mysql-user=$user --mysql-password=$password --mysql-port=$port --tables=10 --report-interval=1 --skip-trx=on --table-size=$table_size --rate=$rate --db-ps-mode=$ps_mode prepare
#!/usr/bin/env bash
host=$1
port=3306
user="sysbench"
password="@MysqP@66w0rd"
table_size=100000
tables=10
rate=20
ps_mode='disable'
threads=1
events=0
time=5
trx=100
path=$PWD
counter=1
echo "thread,cpu" > ${host}-cpu.csv
for i in 16 32 64 128 256 512 1024 2048;
do
threads=$i
mysql -h $host -e "SHOW GLOBAL STATUS" >> $host-global-status.log
tmpfile=$path/${host}-tmp${threads}
touch $tmpfile
/bin/bash cpu-checker.sh $tmpfile $host $threads &
/usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --events=$events --threads=$threads --time=$time --mysql-host=$host --mysql-user=$user --mysql-password=$password --mysql-port=$port --report-interval=1 --skip-trx=on --tables=$tables --table-size=$table_size --rate=$rate --delete_inserts=$trx --order_ranges=$trx --range_selects=on --range-size=$trx --simple_ranges=$trx --db-ps-mode=$ps_mode --mysql-ignore-errors=all run | tee -a $host-sysbench.log
echo "${i},"`cat ${tmpfile} | sort -nr | head -1` >> ${host}-cpu.csv
unlink ${tmpfile}
mysql -h $host -e "SHOW GLOBAL STATUS" >> $host-global-status.log
done
python $path/innodb-ops-parser.py $host
mysql -h $host -e "SHOW GLOBAL VARIABLES" >> $host-global-vars.log
Таким образом, скрипт просто подготавливает схему sbtest и заполняет таблицы и записи. Затем он выполняет чтение/запись нагрузочных тестов, используя скрипт /usr/share/sysbench/oltp_read_write.lua. Сценарий сбрасывает глобальное состояние и переменные MySQL, собирает данные об использовании процессора и анализирует операции строки InnoDB, обработанные сценарием innodb-ops-parser.py. Затем сценарии генерируют файлы * .csv на основе выгруженных журналов, которые были собраны во время теста, затем мы использовали электронную таблицу Excel, чтобы сгенерировать график из файлов * .csv.
Теперь перейдем к результатам графика!
В основном здесь мы извлекли только строковые операции InnoDB, которые выполняют выбор (чтение), удаление, вставку и обновление. Когда количество потоков увеличивается, MySQL 8.0 значительно превосходит MySQL 5.7! Обе версии не имеют каких-либо конкретных изменений конфигурации, но только заметные переменные, которые мы установили. Таким образом, обе версии в значительной степени используют значения по умолчанию.
Интересно, что в отношении заявлений MySQL Server Team о производительности операций чтения и записи в новой версии графики указывают на значительное улучшение производительности, особенно на сервере с высокой нагрузкой. Представьте разницу между MySQL 5.7 и MySQL 8.0 для всех операций с строками InnoDB, есть большая разница, особенно когда количество потоков увеличивается. MySQL 8.0 показывает, что он может работать эффективно независимо от его рабочей нагрузки.
Как показано на графике выше, производительность MySQL 8.0 снова показывает огромную разницу во времени, необходимом для обработки транзакций. Чем ниже, тем лучше он работает, а значит быстрее обрабатывать транзакции. Обработанные транзакции (второй график) также показывают, что оба числа транзакций не отличаются друг от друга. Это означает, что обе версии выполняют почти одинаковое количество транзакций, но отличаются тем, насколько быстро они могут завершиться. Хотя мы могли бы сказать, что MySQL 5.7 все еще может справляться с большими нагрузками при более низкой нагрузке, но можно ожидать, что реалистичная нагрузка, особенно в производстве, будет выше, особенно в самый загруженный период.
Приведенный выше график все еще показывает транзакции, которые он смог обработать, но отделяет чтение от записи. Тем не менее, на графиках есть выбросы, которые мы не включили, так как они представляют собой небольшие кусочки результата, которые искажают график.
MySQL 8.0 показывает большие улучшения, особенно для чтения. Он показывает свою эффективность в записи особенно для серверов с высокой рабочей нагрузкой. Некоторая отличная дополнительная поддержка, которая влияет на производительность MySQL для операций чтения в версии 8.0, — это возможность создавать индексы в порядке убывания (или прямого сканирования индекса). Предыдущие версии имели только сканирование по возрастанию или обратному индексу, и MySQL должен был выполнять сортировку файлов, если требовался сортировка по убыванию (если нужна сортировка файлов, вы можете проверить значение max_length_for_sort_data). Нисходящие индексы также позволяют оптимизатору использовать многостолбцовые индексы, когда наиболее эффективный порядок сканирования смешивает восходящий порядок для некоторых столбцов и нисходящий порядок для других. Смотрите здесь для более подробной информации.
Во время этого бенчмаркинга мы решили использовать некоторые аппаратные ресурсы, в частности, загрузку процессора.
Позвольте нам сначала объяснить, как мы используем ресурсы ЦП здесь во время бенчмаркинга. sysbench не включает в себя коллективную статистику для аппаратных ресурсов, использованных или используемых в процессе, когда вы сравниваете базу данных. Из-за этого мы создали флаг, создав файл, подключившись к целевому хосту через SSH, а затем собрав данные из команды top в Linux и проанализировав их во время сна на секунду, а затем собрали снова. После этого возьмите самое значительное увеличение использования ЦП для процесса mysqld, а затем удалите файл флага.
Итак, давайте снова поговорим о графике, кажется, что он показывает, что MySQL 8.0 потребляет много ресурсов процессора. Больше, чем MySQL 5.7. Однако, возможно, придется иметь дело с новыми переменными, добавленными в MySQL 8.0. Например, эти переменные могут повлиять на ваш сервер MySQL 8.0:
Переменные с их значениями оставлены значениями по умолчанию для этого теста. Первые три переменные обрабатывают ЦП для повторного ведения журнала, что в MySQL 8.0 было улучшением из-за перепроектирования того, как InnoDB записывает в журнал REDO. Переменная innodb_log_spin_cpu_pct_hwm имеет привязку к процессору, что означает, что она будет игнорировать другие ядра процессора, если mysqld прикреплен только к 4 ядрам, например. Для параллельных потоков чтения в MySQL 8.0 добавлена новая переменная, для которой вы можете настроить количество используемых потоков.
Однако мы не стали углубляться в эту тему. Могут быть способы повышения производительности за счет использования функций, предлагаемых MySQL 8.0.
Есть множество улучшений, которые присутствуют в MySQL 8.0. Результаты тестирования показывают, что произошло впечатляющее улучшение не только в управлении рабочими нагрузками чтения, но также и в высокой рабочей нагрузке чтения/записи по сравнению с MySQL 5.7.
Переходя к новым функциям MySQL 8.0, похоже, что он использует преимущества самых современных технологий не только в программном обеспечении (например, значительное улучшение для Memcached, удаленное управление для лучшей работы DevOps и т. д.), Но и также в оборудовании. Например, замена latin1 на UTF8MB4 в качестве кодировки символов по умолчанию. Это будет означать, что для этого потребуется больше дискового пространства, поскольку UTF8 требуется 2 байта для символов, не входящих в US-ASCII. Хотя в этом тесте не использовался новый метод аутентификации с caching_sha2_password, это не повлияет на производительность, если он использует шифрование. После аутентификации он сохраняется в кеше, что означает, что аутентификация выполняется только один раз. Поэтому, если вы используете одного пользователя для своего клиента, это не будет проблемой и будет более безопасным, чем предыдущие версии.
Поскольку MySQL использует самое современное аппаратное и программное обеспечение, он меняет свои переменные по умолчанию.
В целом, MySQL 8.0 эффективно доминирует над MySQL 5.7.
(Пока оценок нет)
Загрузка...
Заполните форму и наш менеджер перезвонит Вам в самое ближайшее время!
Спасибо! Ваша заявка принята
Спасибо! Ваша заявка принята
Там посоему проблема какая то со связкой Myql8 + Phpmyadmin