Форум MySQL

Проблема очень нестандартная и странная.

При записи данных (а именно строка с кирилицей в UTF-8) в БД (таблица InnoDB utf8_general_ci) иногда(!) русские буквы записываются вот такими кракозябрами Александр.
Записываемые исходные данные нормальные в UTF-8.
Язык PHP.

Кодировки везде установлены правильные. mysql_set_charset() использую. SET NAMES 'utf-8' тоже пробовал. Но это всё не то. Потому как проблема возникает иногда!

Какие особенности появления этой ситуации я заметил?
1. Если только что коряво записанные данные сразу же считать из БД и вывести на экран, то они нормальные! Т.е. в том же PHP скрипте при том же подключении к БД.
2. Почему-то проблема появляется в таблицах, к которым давно (где-то сутки или пол суток) не производился запрос на запись. После этой первой ошибочной записи, все последующие запросы проходят без проблем.
3. Проблема замечена только в двух таблицах из всех. Таблицы не маленькие по полям. В одной 50 столбцов, в другой - 100. Записей в них не много. Данные - обычные тексты (VARCHAR, CHAR) да числа (INT, MEDIUMINT, TINYINT), пару ENUM, и по-одному TIME и DATE.

Прошу специалистов MySQL большущей помощи!

проверяйте кодировки своих файлов (должно быть UTF-8 без BOM), проверяйте логику подключаемых файлов, которые тоже должны быть UTF-8 без BOM, а так же файлы не должны содержать никакого вывода в браузер до <?php и после ?> обычно где-то забывают пробелы или переводы строки, а это уже вывод контента в браузер.
Точно ли у вас единое подключение к БД, возможно их есколько и кодировки отличаются?

Valick, это всё типичные ошибки. С этим всё как надо. Поэтому и пишу что ошибка необычная.
Подключение одно, кодировка одна.

судя по моему горькому опыту - чудес не бывает ;)
где-то что-то упущено

Valick, не отрицаю что что-то упущено. Но только не в этом.

Решено! Проблема была в чрезмерной экономии хостинг провайдера. А именно в мизерных настройках MySQL.
Их можно отобразить SQL командой:

SHOW VARIABLES

Во-первых, кодировка по умолчанию на хостинге стоит cp1251, которую нельзя поменять.

Во-вторых, параметр wait_timeout был равен 15! Это значит, что если между SQL запросами бальше 15 секунд, то текущее MySQL соединение закрывается, а когда делаешь следующий запрос, соединение создаётся снова, но уже с кодировкой по умолчанию!

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

SET wait_timeout = 28800

P.S. Ох уж эти хостинги...

15 секунд между запросами - это вечность по меркам MySQL для обычного соединения.
15 секунд это с огромным запасом для вменяемого времени выполнения веб скрипта, а учитывая то, что хорошим тоном будет использование оператора закрытия соединения с БД после всех запросов для формирования страницы, перед непосредственным формированием этой самой страницы и выводом её в браузер, не дожидаясь окончания работы скрипта когда соединение закрывается автоматически, то 15 секунд - это вечность в квадрате.
Количество одновременно подключенных пользователей к базе данных - это тоже вещь не безразмерная и на фоне этого ваши SET wait_timeout = 28800 , просто как контрольный в голову.
Ну и в конце концов есть запрос на установку постоянного соединения с БД, для использования которого нужны веские причины, а большинство авторов книг, не вдаваясь в подробности, просто предостерегают от использования постоянного соединения.

Valick, для запросов MySQL это и много, но не для PHP скрипта.
Соединение используется не постоянное! И корректно закрывается в конце скрипта оператором, о котором вы пишите.
Значение 28800 - по умолчанию. Изучайте документацию http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_wait_timeout.
А проблема была в том, что наш скрипт общается с API сервером, и иногда приходится ждать ответа от API, ожидание которого может превышать 15 секунд. При этом соединение с MySQL висит. Вот и все дела.

Это называется вы решили проблему? При таких обстоятельствах вам принудительно надо рвать соединение не дожидаясь тайм-аута даже в 15 минут, а вы его еще увеличили.
А теперь расскажите каким таким волшебным образом соединение восстанавливается со значением кодировки по умолчанию?

то есть Вы использовали постоянное соединение?
И ни словом об этом не обмолвились?
Вот уж и вправду - контрольный в голову...

Trianon, постоянное соединение не используется! Поэтому и не обмолвился.
Описание ситуации читайте выше.
И нечего контролить голову.