Cегодня MySQL в Facebook опубликовал последующий о производительности MySQL:
Сегодня мы обнаружили проблему с производительностью в совершенно неожиданном месте - если используется тип данных TIMESTAMP и MySQL настроен на использование системного часового пояса, он попадет в код в библиотеке Linux C, который имеет глобальный мьютекс. Чтобы добавить оскорбления к травме, поддержка внутреннего часового пояса MySQL (с использованием таблиц mysql.time_zone *) примерно на 30% быстрее при однопоточной нагрузке. С 30 клиентскими потоками внутреннее преобразование часового пояса MySQL в 30 раз быстрее. День начался с того, что выглядело как ошибка MySQL, но, очевидно, это победа MySQL. - дома
Как я могу определить, использует ли мой экземпляр MySQL более медленный системный часовой пояс или он использует более быстрый mysql.time_zone*
столы? то есть какие параметры конфигурации MySQL я должен проверить?
(на самом деле мы используем Amazon RDS вместо размещения собственной базы данных, однако я не думаю, что это имеет значение, кроме проверки my.cnf
, Мне нужно будет использовать группу параметров RDS для проверки или изменения переменных конфигурации. )
Из связанной статьи
После загрузки файлов (через http://dev.mysql.com/.../time-zone-support.html), просто укажите global
time_zone
параметр конфигурации вmy.cnf
, или измените его с помощьюSET GLOBAL ...
- все равно не забудьте поменять вmy.cnf
. Обратите внимание, вы можете сделать это и на всех подчиненных устройствах, поскольку репликация немного раздражает разные часовые пояса.
Вы можете определить настройку global.time_zone с помощью
mysql> select @@global.time_zone;
+--------------------+
| @@global.time_zone |
+--------------------+
| SYSTEM |
+--------------------+
1 row in set (0.00 sec)