Это из-за того, что на сайте я задаю timezone отличную от той, которая используется в mysql с помощью функции date_default_timezone_set.

По-началу я думал что ситуация неразрешима, что настройка временной зоны внутри mysql глобальная для всего сервера. Но это оказалось не так. Можно изменить временную зону для mysql-сессии запросом: “SET time_zone = ‘<имя зоны>’”.

Список временных зон, которые поддерживаются mysql сервером можно получить запросом: SELECT Name FROM mysql.time_zone_name;

После того как я стал задавать временную зону, такую-же как в PHP сессии то странные расхождения во времени пропали. После установки mysql-соединения рекомендую выполнить команду:

mysql_query(”/*!40101 SET time_zone = ‘”.date_default_timezone_get().”‘ */”,$db_resource);

ну или просто запрос “SET time_zone = ‘имя зоны’;”

Но, как говорится, для каждой бочки меда всегда найдется ложка дегтя. Через пару дней наткнулся на странный глюк (думаю это глюк PHP версии 5.1.6, проверить насколько это верно сейчас нет возможности).

Проблема заключается в следующем:

После вызова функции date_default_timezone_set(), я уже не могу задать другую временную зону для скрипта.

Такое чувство что она “одноразовая” – что поставил в первый раз, то и работает.. хотя date_default_timezone_get() возвращает при этом разные результаты.

После массы тестов пришел к совсем чудесному результату… Код работает, но какой!!!

Есть у меня файл config.php, там строки:

$config['timezone'] = ‘Europe/Dublin’;

date_default_timezone_set($config['timezone']);

далее, в классе где мне нужно переключать часовой пояс (в недрах класса, который генерирует отчеты для пользователей в разных часовых поясах), работает такая штука:

global $config;

$config['timezone'] = ‘Europe/Paris’;

А инструкция date_default_timezone_set(’Europe/Paris’) которая там была до этого не работает! Я в шоке Буду рад комментариям по делу.

P.S. Не совсем в тему, но информативно – статья на Хабре про часовые пояса в PHP.

Проблема: при попытке открыть WEB страницу которой необходимо подключение к базе данных Apache падает, в журнале событий появляется ошибка:

Сбойное приложение httpd.exe, версия 2.2.11.0, штамп времени 0×493f5d44, сбойный модуль php5ts.dll, версия 5.2.10.10, штамп времени 0×4a3908cf, код исключения 0xc0000005, смещение ошибки 0×00096f85, ИД процесса 0×4f8, время запуска приложения 0×01ca12759c60e3ac.

Так как операционка свежая, Apache и PHP только что установлены, то прежде чем понять в чем проблема, я ходил несколько часов вокруг да около (поставил PHP 5.2 вместо 5.3, снёс Apache с поддержкой SSL и поставил без этой поддержки, долго вчитывался в конфиги и менял их по мелочи). Однако решение проблемы оказалось лежит на поверхности – ведь она происходит только при попытке подключения к базе, значит виноват MySQL!

Проблема решилась сносом MySQL 5.1.0 и установкой MySQL 5.0.84!

Хотя осознание этого факта до меня дошло только после того как я нашел в сети несколько подтверждений этому:

• [PHP-DB] Apache crashes every time I call mysqli_fetch_assoc()
• mysql connection causes apache 2.2.8 x64 to crash on Vista
• How to install Apache 2.2.X and PHP5 as a Module on Windows Vista without crashing?

Возможно данная проблема актуальна только когда Apache запускает PHP как модуль, а если установить его для запуска в режиме CGI то она также исчезнет. Но я не уверен в этом, – не проверял.

Дополнительные материалы:

• Установка Apache 2.11, MySQL, PHP (хорошее детальное описание процесса)
• Сообщение в форуме о похожей ошибке c php5ts.dll, но для меня почему-то оказалось не актуальным (не нашел я в PHP.ini приведенных там строк)

На днях я решил перенести мою Wiki на другой сервер, и столкнулся с неожиданными проблемами, которые растянули этот процесс на 3 дня.

Сначала застрял на том, что при попытке отображении статей мне выдавалась ошибка mysql:

MySQL returned error “1267: Illegal mix of collations (latin1_bin,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation ‘=’ (localhost)”.

Избавиться от ошибки получилось после того, как я задал в рабочей базе кодировку utf8 вместо latin1 для столбцов с типом VARCHAR (рецепт взят отсюда). При этом, пришлось модифицировать индекс “cl_to” в таблице “categorylinks” (уменьшить число символов, учавствующих в индексе), потому что иначе выдавалось сообщение об ошибке:

Specifiend key was too long; max key length is 1000 bytes

После обновления полей базы сделал дамп, загрузил его на сервер назначения, и столкнулся с другой засадой – русский текст в статьях показывается “кракозябами”, а статьи с русскими названиями вообще не находятся. Танцы с бубном не помогли:

1. выгружал дамп с опцией –default-character-set=utf8;
2. пытался сконвертировать дамп различными утилитами в utf8 (в итоге так и не нашел ни одной программы, которая корректно бы показала то что создается с помощью mysqldump);

В конце-концов, наткнулся на рецепт в блоге, который мне помог: создал дамп базы с помощью утилитки Sypex Dumper (написанной на PHP, кстати), и развернул его с её же помощью на сервере. Надо только явно задать значения констант CHARSET и RESTORE_CHARSET внутри скрипта перед его запуском:

define(’CHARSET’, ‘latin1′);
define(’RESTORE_CHARSET’, ‘utf8_general_ci’);

И это действительно работает! Mediawiki успешно перенесена на другой сервер, проблема с кодировками решена!

Да, саму Wiki я не переинсталлировал, просто скопировал директорию и поправил файл LocalSettings.php – поменял пути к базе и установил значение TRUE для переменной $wgDBmysql5.

К своему стыду я и не знал, что mysql с версии 4.1 поддержит предварительную подготовку запросов (prepare) и их последующее выполнение с передаваемыми параметрами. Пока не выяснил только, расшаривает ли сервер (по идее должен), подготовленные запросы для всех подключений. Это ведь может резко снизить нагрузку на базу данных!

Единственно что плохо – похоже не все хостеры поддерживают его даже на данный момент (на хостинге РБК, по крайней мере не увидел где его можно включить). Поэтому лучше написать класс-враппер, чтобы можно было легко переключаться на старый протокол работы с mysql.

Полезные ссылки: толковая статья по теме (оригинал тут).

Например, существует таблица “test” с полями “day” (дата, без времени) и “counter” (число – счетчик). Есть уникальный индекс по полю “day”. Надо его увеличивать при наступлении какого-то внешнего события (у меня это downloads).

Довольно часто я применял такой метод – делаем SELECT (ищем запись в базе), если ее нет – INSERT, иначе – UPDATE. В последнее время стал использовать функцию PHP mysql_affected_rows(), а вчера увидел еще одно решение – всегда делается вставка, и если произошла ошибка дублирования ключа – выполняем UPDATE.

Сначала я подумал что это решение ужасно, но потом сильно задумался.

Решил опросить коллег, вызвался помочь 1 человек, порекомендовал mysql_affected_rows(), но без всяких пояснений. Тогда я закинул вопрос в сервис Google “Вопросы и ответы”, там мне рассказали что в MySQL существует встроенный оператор для осуществления того что мне надо -
“INSERT INTO … ON DUPLICATE KEY UPDATE”.

Как оказалось он наиболее эффективен из всех решений. Продублирую сюда свои выкладки:

Я написал тестовый скриптик с обновлением счетчика 100тыс раз а таблицу заполнил случайными данными (2200записей).

Тестировалсь 4 метода:

1. Встроенный синтаксис MySQL (INSERT INTO test(day, counter) VALUES (…) ON DUPLICATE KEY UPDATE…
2. Внутри PHP пытаемся делать update, если mysql_affected_rows()<>1 то вставляем новую запись.
3. Делаем SELECT (ищем есть ли в таблице запись на нужный нам Day), если запись найдена – update, иначе – insert (именно этот способ я чаще всего использвал в своих приложениях, поэтому интересно было сравнить).
4. Делаем INSERT, если вернулась ошибка mysql DUPLICATE KEY выполняем update.

Скриптик написал с использованием нативных функций PHP mysql_.. Выполнил его 3 раза, на компе остановил все тяжелые задачи, даже проигрывание музыки
Версия PHP 4.3.11, mysql – 4.1.11-nt. Конектился к localhost.

Результаты такие:

первый запуск:

Start of testing method1..finished, executed time: 10.931 (100000 iterations)
Start of testing method2..finished, executed time: 11.207 (100000 iterations)
Start of testing method3..finished, executed time: 27.775 (100000 iterations)
Start of testing method4..finished, executed time: 20.738 (100000 iterations)

второй запуск:

Start of testing method1..finished, executed time: 10.354 (100000 iterations)
Start of testing method2..finished, executed time: 11.048 (100000 iterations)
Start of testing method3..finished, executed time: 27.807 (100000 iterations)
Start of testing method4..finished, executed time: 20.449 (100000 iterations)

третий запуск:

Start of testing method1..finished, executed time: 10.571 (100000 iterations)
Start of testing method2..finished, executed time: 11.101 (100000 iterations)
Start of testing method3..finished, executed time: 28.179 (100000 iterations)
Start of testing method4..finished, executed time: 20.634 (100000 iterations)

(Время дано в секундах)

Вывод:

Для подобной операции наиболее эффективна встроенная команда, хотя метод с mysql_affected_rows проигрывает совсем немного. Наиболее часто используемый мной способ почти в 3 раза медленней, а тот код, с которого я начал разбирательство – в 2 раза.

PS Кстати, использование сервиса от Google “Вопросы и ответы” было экспериментальным, – хотел проверить насколько он эфективен в работе. И мне понравилось. Ответ я получил буквально в течении часа. Видимо сервис очень популярен (на данный момент у меня 95 просмотров моего вопроса). Так что всем рекомендую его использовать, и не только для вопросов но и ответов

b.day >= SUBDATE(sysdate(),INTERVAL 31 DAY)

то MySQL почему-то не использует индекс, который создан по полю day, а если в текст запроса поместить константу:

b.day >= ‘2008-03-30′

тогда индекс используется!

Чудеса какие-то, вообще я ожидал что он только 1 раз вычислит результат функции SUBDATE и будет его использовать как константу, но не тут то было.. почему-то.

Вывод: используем константы в запросах, не умничаем знанием встроенных функций.

PS Версия MySQL 5.0.42