Comments 11
Прекрасный пост.
Уважаемая, конечно приводимые по ссылке материалы достойны внимания, однако позвольте указать Вам на Вашу ошибку:
Хабр — не Твиттер. Не стоит судя писать посты, суть которых сводится к «Помыл голову, пойду поем». «Персональный блог» — это не Diary/LJ/Li.Ru…
Но даже если это опустить, то как такового списка изменений Вы не представили. В связи с этим пост можно было бы оформить ссылкой на Ваш сайт, и в качестве описания представить публике краткую информацию о Вашем «гайде».
TL;DR — Спасибо, но пост переоформите.
Хабр — не Твиттер. Не стоит судя писать посты, суть которых сводится к «Помыл голову, пойду поем». «Персональный блог» — это не Diary/LJ/Li.Ru…
Но даже если это опустить, то как такового списка изменений Вы не представили. В связи с этим пост можно было бы оформить ссылкой на Ваш сайт, и в качестве описания представить публике краткую информацию о Вашем «гайде».
TL;DR — Спасибо, но пост переоформите.
И вам спасибо.
> Хабр — не Твиттер. Не стоит судя писать посты, суть которых сводится к «Помыл голову, пойду поем». «Персональный блог» — это не Diary/LJ/Li.Ru…
Люди писали комментарии, поэтому сочла нужным дать эту новость.
> Но даже если это опустить, то как такового списка изменений Вы не представили. В связи с этим пост можно было бы оформить ссылкой на Ваш сайт, и в качестве описания представить публике краткую информацию о Вашем «гайде».
Надо сказать новые правила с чекбоксами так напугали, что ссылку убрала, так как в оригинальном посте всё есть :)
> Хабр — не Твиттер. Не стоит судя писать посты, суть которых сводится к «Помыл голову, пойду поем». «Персональный блог» — это не Diary/LJ/Li.Ru…
Люди писали комментарии, поэтому сочла нужным дать эту новость.
> Но даже если это опустить, то как такового списка изменений Вы не представили. В связи с этим пост можно было бы оформить ссылкой на Ваш сайт, и в качестве описания представить публике краткую информацию о Вашем «гайде».
Надо сказать новые правила с чекбоксами так напугали, что ссылку убрала, так как в оригинальном посте всё есть :)
Переоформила пост
>… используйте опцию --default-character-set и при импорте, и при экспорте данных.
Вот я пару раз терял данные из-за неочевидных комбинаций опций сервера и mysqldump.
Много ли людей с этой скорбной проблемой обращались в техподдержку и не стала ли именно она причиной решения о тотальном переезде mysql в utf8? я имею ввиду заявления soft.mail.ru/pressrl_page.php?id=37668 «Все символы в будущих свободных версиях MySQL планируется хранить с использованием только одного стандарта – UTF-8. Такое жесткое ограничение поможет избежать повреждений БД при вводе данных «не на том языке».»
Вот я пару раз терял данные из-за неочевидных комбинаций опций сервера и mysqldump.
Много ли людей с этой скорбной проблемой обращались в техподдержку и не стала ли именно она причиной решения о тотальном переезде mysql в utf8? я имею ввиду заявления soft.mail.ru/pressrl_page.php?id=37668 «Все символы в будущих свободных версиях MySQL планируется хранить с использованием только одного стандарта – UTF-8. Такое жесткое ограничение поможет избежать повреждений БД при вводе данных «не на том языке».»
> Много ли людей с этой скорбной проблемой обращались в техподдержку
Да, довольно много. Также было много публичных сообщений об ошибках. Это послужило в плюс решению изменить default-character-set для mysqldump на UTF-8
> «Все символы в будущих свободных версиях MySQL планируется хранить с использованием только одного стандарта – UTF-8. Такое жесткое ограничение поможет избежать повреждений БД при вводе данных «не на том языке».»
Имеются в виду названия таблиц, баз данных и других сужебных объектов. Пользовательские данные как хранились в любой из поддерживаемых кодировок, так и хранятся. Также в 5.5.x добавились новые кодировки. А касательно служебных объектов UTF-8 видится логичным выбором, так как эта кодировка поддерживает все языки.
Да, довольно много. Также было много публичных сообщений об ошибках. Это послужило в плюс решению изменить default-character-set для mysqldump на UTF-8
> «Все символы в будущих свободных версиях MySQL планируется хранить с использованием только одного стандарта – UTF-8. Такое жесткое ограничение поможет избежать повреждений БД при вводе данных «не на том языке».»
Имеются в виду названия таблиц, баз данных и других сужебных объектов. Пользовательские данные как хранились в любой из поддерживаемых кодировок, так и хранятся. Также в 5.5.x добавились новые кодировки. А касательно служебных объектов UTF-8 видится логичным выбором, так как эта кодировка поддерживает все языки.
>net_read_timeout
>Сколько ждать ответа на запрос SELECT
>net_write_timeout
>Сколько ждать ответа на запрос, модифицирующий данные.
Вот здесь непонятно. Это работает? Вы что-то скрываете, чего нет в документации или это ошибка? в документации смысл совсем другой. И на практике я не наблюдаю прерывание запроса.
Какие вообще есть способы заставить mysql прерывать длинные запросы по времени, кроме написания программы-монитора?
>Сколько ждать ответа на запрос SELECT
>net_write_timeout
>Сколько ждать ответа на запрос, модифицирующий данные.
Вот здесь непонятно. Это работает? Вы что-то скрываете, чего нет в документации или это ошибка? в документации смысл совсем другой. И на практике я не наблюдаю прерывание запроса.
Какие вообще есть способы заставить mysql прерывать длинные запросы по времени, кроме написания программы-монитора?
Ответила здесь: svetasmirnova.habrahabr.ru/blog/76205/#comment_3111237
Sign up to leave a comment.
Изменения в «Методах выявления ошибок в SQL приложении»