Комментарии 63
НЛО прилетело и опубликовало эту надпись здесь
Да, не помешало бы. Надоели траблы с "И" и "ш"
Почитайте в конце статьи В помощь вебмастеру: Linux bash скрипт для перевода сайта на новую кодировку
Вас спасет: SET NAMES 'utf8'
Вас спасет: SET NAMES 'utf8'
Вы меня прям смутили. :)
Все свои проекты перевел на UTF-8 уже 4 месяца назад и никаких глюков не заметил (по крайнер мере юзвери не писали в саппорт)
Может уточнить, где конкретно траблы?
Все свои проекты перевел на UTF-8 уже 4 месяца назад и никаких глюков не заметил (по крайнер мере юзвери не писали в саппорт)
Может уточнить, где конкретно траблы?
Ну смотря как как переводить. У меня некоторые(вап-сайты) работают через энное место - кодировка полей cp1251, кодировка клиента и сервера тоже, но данные пишутся и читаются в утф8. Никаких проблем(кроме чтения базы через тот же sqlyog). Где конкретно траблы сейчас уже не скажу, но мучал долго и по-всякому.
Вот, кстати, наглядное проявление подобной проблемы - http://habrahabr.ru/blog/i_am_clever/347… (комментарии)
Вот, кстати, наглядное проявление подобной проблемы - http://habrahabr.ru/blog/i_am_clever/347… (комментарии)
Вот гарантированное спасение:
Сразу после mysql_connect() надо выполнить такие вот запросы:
SET NAMES utf8;
SET character_set_client=utf8;
SET character_set_connection=utf8;
SET character_set_database=utf8;
SET character_set_results=utf8;
Разумеется, кодировки БД, таблиц и полей очень не мешало бы привести к UTF-8 :)
А если база в cp1251 (она же win1251, она же windows-1251) - то скрипт, который сконвертит дамп БД в UTF8, пишется секунд за 30 :)
PS: Да, знаю, что эта пачка SQL-запросов избыточна - но во-первых, эти запросы выполняются за исчезающе малое время. И во-вторых - никаких посторонних косяков они не генерируют :)
Сразу после mysql_connect() надо выполнить такие вот запросы:
SET NAMES utf8;
SET character_set_client=utf8;
SET character_set_connection=utf8;
SET character_set_database=utf8;
SET character_set_results=utf8;
Разумеется, кодировки БД, таблиц и полей очень не мешало бы привести к UTF-8 :)
А если база в cp1251 (она же win1251, она же windows-1251) - то скрипт, который сконвертит дамп БД в UTF8, пишется секунд за 30 :)
PS: Да, знаю, что эта пачка SQL-запросов избыточна - но во-первых, эти запросы выполняются за исчезающе малое время. И во-вторых - никаких посторонних косяков они не генерируют :)
Вообще WAP сайту сам бог велел быть только в UTF-8. На мобильных телефонах как правило нет возможности выбора кодировки, от чего страница в cp1251 становится абсолютно нечитаема на нелокализованых телефонах.
Проверено на апаратах во Франции и паре китайских "игрушек".
Кстати, на w3.org есть строчка о кодировках в WAPе.
Проверено на апаратах во Франции и паре китайских "игрушек".
Кстати, на w3.org есть строчка о кодировках в WAPе.
НЛО прилетело и опубликовало эту надпись здесь
Вы сперва мануалы почитайте и сервер запустите с UTF-8.
храните базы и таблицы в utf8_unicode_ci и будет вам счастье.
всё там с utf-8 нормально.
по-вашему, какую БД использует Википедия?
по-вашему, какую БД использует Википедия?
Нахрена... чем простой UTF8_GENERAL не нравиться, всё прекрасно работает с кирилицей, забудьте просто про кодировку win-1251 в html и всё! это аттавизм...
Поддержки транзакций опять нет. Когда она уже будет?
используйте ИнноДБ
Использую. Но у него свои косяки присутствуют.
Например? Я уже лет 5 на ИнноДБ сижу. Никаких проблем не наблюдал.
При сбое сложно востановить базу (практически не возможно). Перенос в отличии от того же MyISAM только через dump/restore. По умолчанию валит все данные в один файл.
Разные файлы - конфиг вам в руки. А по восстановлению соглашусь - кошмар просто.
innodb-tools
не пробовали?
не пробовали?
Поддержка транзакций обещается в следующем релизе
см. FAQ: http://monty-says.blogspot.com/2008/01/maria-engine-is-released.html
см. FAQ: http://monty-says.blogspot.com/2008/01/maria-engine-is-released.html
поддержки транзакций в MyISAM нет намеренно.
Не так много реальных задач в веб-программировании, где действительно нужны транзакции и ACID. А механизм транзакций - это гарантированное замедление работы бд.
Поэтому всем, кому они нужны - InnoDB и новомодный Falkon в руки.
Не так много реальных задач в веб-программировании, где действительно нужны транзакции и ACID. А механизм транзакций - это гарантированное замедление работы бд.
Поэтому всем, кому они нужны - InnoDB и новомодный Falkon в руки.
Не так много реальных задач в веб-программировании, где действительно нужны транзакции и ACID.
Я бы не был так категоричен.
Интересно было бы услышать тогда примеры.
Очень много людей, кто рассуждает о транзакциях не представляя вообще зачем они нужны. Обычно в ответ слышишь что-то типа: "Для работы с биллингом точно надо" и т.п.
Очень много людей, кто рассуждает о транзакциях не представляя вообще зачем они нужны. Обычно в ответ слышишь что-то типа: "Для работы с биллингом точно надо" и т.п.
Как минимум для поддержания атомарности операции и как следствие целостности данных. К тому же если в MyISAM интенсивно писать в несколько потоков, то с чтением у вас будут серьезные проблемы. В InnoDB кстати с этим лучше, но надо откручивать ACID для получения нормального уровня производительности или тюнить приложение на использование транзакций.
> интенсивно писать в несколько потоков
как много случаев, когда вам в веб-приложении приходилось интенсивно писать в одну таблицу в несколько потоков?
Уверен, что на большой проект - это одна-две таблицы. Делайте их InnoDB и будет вам счастье.
как много случаев, когда вам в веб-приложении приходилось интенсивно писать в одну таблицу в несколько потоков?
Уверен, что на большой проект - это одна-две таблицы. Делайте их InnoDB и будет вам счастье.
в случае если у вас будет посещаемый проект типа хабра то вполне будет. Они правда используют репликацию с узлом на запись и узлом на чтение.
> в случае если у вас будет посещаемый проект типа хабра то вполне будет.
вспоминается выступление программеров с ЖЖ, когда они говорили, что у них ВСЕ таблицы MyISAM. Вы думаете у них слабые нагрузки? На собственном опыте - мы имели > 1000 запросов\сек тоже только на MyISAM - с атомарностью и изоляциями проблем небыло.
вот разделение рид и райт коннектов - это другое дело.
вспоминается выступление программеров с ЖЖ, когда они говорили, что у них ВСЕ таблицы MyISAM. Вы думаете у них слабые нагрузки? На собственном опыте - мы имели > 1000 запросов\сек тоже только на MyISAM - с атомарностью и изоляциями проблем небыло.
вот разделение рид и райт коннектов - это другое дело.
> 1000 запросов\сек тоже только на MyISAM - с атомарностью и изоляциями проблем небыло.
вспоминается выступление программеров с ЖЖ, когда они говорили, что у них ВСЕ таблицы MyISAM.
у и количество читающих и пишущих. К тому же как у вас не может быть проблем с атомарностью и изоляциями если у MyISAM нет поддержки транзакций.
Мои вот измерения показывали что MyISAM дохнет на 20-30 одновременных массированых операциях записи или одной длинной массированной операции записи. Читаться от туда читается, а вот запись особо не ведется.
Ну и сколько из этой тысячи делали запись?
интенсивная запись была в две-три таблицы. Но с ними были проблемы не с целостностью, а с выборками из них. И тут InnoDB только замедляет.
Вы открутите ACID от InnoDB. По умолчанию оно включено, что роняет производительность раза в три.
Гм. Вы просите поддержку транзакций от новых движков, но ни одна из A, C, I, D вам не нужна. Может вам не нужны транзакции?
ACID в случае MySQL подразумевает запись каждой транзакции в лог в fsync затем запись в базу тоже с fsync. Так что если приложение не использует транзакции или транзакции короткие, то производительность сильно падает. Для того чтобы этого не происходило есть возможность отключить принудительный fsync и синкать по таймеру. При этом ACID в целом сохраняется, хотя могут быть повреждения данных или их не попадание в базу в случае обрушения MySQL движка. Транзакции при этом продолжают работать.
мы имели > 1000 запросов\сек тоже только на MyISAM - с атомарностью и изоляциями проблем небыло.
вспоминается выступление программеров с ЖЖ, когда они говорили, что у них ВСЕ таблицы MyISAM. Вы думаете у них слабые нагрузки?
ак нет транзакций. Мой же личный опыт показывает, что MyISAM на запись работает крайне хреново, так-как лочится вся таблица и из-за этого в случае большого числа операций записи или одной длинной операции записи можно или потерять данные или они будут поступать с запозданием.
В Maria 2.0 (после Maria 1.5, текущая - 1.0).
Я что-то не понял из описания - будут транзакции или нет?
Йуху.
А чем же тогда он отличается от ИнноДБ?
Собственно это приведёт к тому, что если сейчас mySQL выигрывает у полноценных БД на операциях INSERT/UPDATE (в частности за счёт отсутствия логов этих операций), то на новой версии движка она перестанет это делать.
Те они собираются убить myisam только из-за лога запросов, которые все давно делают на уровне абстракции бд и страниц, плюс от которых достаточно сомнителен?
Maria поддерживает практически все фичи MyISAM (кроме некоторых неиспользуемых) и все форматы (она сделана на основе MyISAM). Соотвестственно для старых форматов нет логирования и поддержки транзакций (в будущем - сейчас нет восстановления).
Забыл добавить и в Марии можно отключить логирование (вместе с восстанавливаемостью конечно: http://forge.mysql.com/wiki/Maria_Docs )
При правильной архитектуре - будет хватать и mysql 4.
Даже на сложных (по виду :) ) запросах...
Даже на сложных (по виду :) ) запросах...
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MyISAM хотят заменить на новый движок Maria