Upgrade MySQL 5.7 до MySQL 8.0 не придал двукратной производительности сайту!

sergv,

Так они все должны быть MyISAM или InnoDB?

Оптимизация базы – это удаление ревизий, использование команды OPTIMIZE TABLE, использование какого ни будь плагина типа Optimize DB и т.п.?

Про сервер и версии ПО не соглашусь, я хоть и не профессионал в этом деле, но из личного опыта переход с обычного хостинга на средний VPS увеличил скорость работы WordPress сайта, и из последнего где было замечено увеличение производительности — это переход с PHP5 на PHP7.2 причем видно это было так на глаз, ну и по циферкам.

Про нормально настроить согласен, но согласитесь поменять версию ПО или тариф увеличить намного проще, особенно для меня.

Уже в InnoDB они должны быть все.

LEOnidUKG,

Посмотрел что по умолчанию MySQL 8 делает таблицы с движком InnoDB, в принципе их легко переконвертировать из MyISAM, но некоторые таблицы почему-то не переконвертируются.

Чудеса. И с какой же ошибкой они это делают?

LEOnidUKG,

Например вот так пишет:

wp_comments

#1067 - Invalid default value for 'comment_date'

wp_links

#1067 - Invalid default value for 'link_updated'

wp_users

#1067 - Invalid default value for 'user_registered'

В my.cnf вставьте:

sql_mode=NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

и перезагрузите mysql

или же изменяйте не правильные стандартные значения в этих полях.

LEOnidUKG,

Блин, вы правы, с меня пиво!

Только пару заметок от непрофессионала и любителя, который делает многое методом тыка:

Вставив sql_mode в my.cnf и перезапустив сервер базы данных, он не запустился и скорее всего это из-за NO_AUTO_CREATE_USER – где-то в интернете кто-то сказал, что он то ли не поддерживается в новой версии толи что-то такое, но это не точно:

MySQL 8.0 does not support NO_AUTO_CREATE_USER

Documentation: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-11.html

Более того некоторые параметры по умолчанию уже были у меня включены, такие как:

NO_ZERO_IN_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_ENGINE_SUBSTITUTION

Получается я добавил лишь: NO_ZERO_DATE и после этого как это не странно все остальные таблицы переконвертировались в InnoDB без каких-либо вопросов.

И возможно стало побыстрее работать, хотя это тоже не точно, нужно еще чо нить оптимизировать в БД.

Такого плана статьи:

http://blogiseo.ru/blogovedenie/optimizaciya-bazy-dannyx.html

Это же про оптимизацию, ну или другие похожие.

Просто старый подход руководства mysql был такой:

- Да не парьтесь о мелочах и разрабатывайте с нами! Мы вам поможем.

Руководство сменилось:

- КАК вы делаете не по ГОСТ-у! Всё ппц! Переделывайте, читайте тонны мануалов! Ататата! Не ну есть вломы, то ладно вот вам костыль, живите как раньше примитивы.

измените данные в свой таблице, чтобы не было #1067 - Invalid default value for 'comment_date'

или выключите проверку этих данных.

Два подхода.

2-й похож на sqlite, которому все равно что написали в CREATE (с некоторыми оговорками, типа автоинкремент).😂 В mysql такое наверное не прокатит? Похоже, идут к этому.

CREATE TABLE "city" (

 "id" NOT NULL PRIMARY KEY,

 "locality" INT, 

 "inflect", 

 "region_name", 

 "coords" )

В sqlite, не смотря на то, что "locality" INT, туда без проблем зайдет "Магадан", ну или "Баден" с "22С". А у "region_name" и "coords" вообще тип не указан

По факту, 2-й путь перекладывает ответственность на "сайторазработчика" - базар данные фильтровать надо перед записью😂 Ваша КМС, вордпресс судя по всему, это делает корректно?🍿

А как из за этого /вз?ломы/? Eсли "INSERT INTO [table] (id, name) VALUES (:id, :name) ;" ? Или я неверно понял?

Вы конспиролог? :D

Вломы = лень :)