Marten Mickos (Мартен Микос?), занимавший пост исполнительного директора MySQL AB до того, как Sun купила компанию, увольняется. После поглощения MySQL AB, Мартен занял пост вице-президента по направлению «базы данных» (senior vice president of Sun Microsystems' database group).
![](http://habrastorage.org/getpro/habr/hub/d9c/7e0/51c/d9c7e051c85e8c5364cc500a16cac2e0.png)
16.44
Рейтинг
MySQL *
Свободная реляционная СУБД
Сначала показывать
Порог рейтинга
Уровень сложности
Особенность оптимизатора MySQL 5.1.30 порядок следования таблиц в UPDATE
1 мин
977Добрый день. Я расскажу об одной из забавных особенностей оптимизатора MySQL 5.1.30, которая заставляет перед обновлением внимательно проверить запросы.
Для любопытных: «теперь SET-выражения выполняются не в порядке следования выражений слева направо, а в порядке следования обновляемых таблиц».
Для любопытных: «теперь SET-выражения выполняются не в порядке следования выражений слева направо, а в порядке следования обновляемых таблиц».
+41
Восстановление базы MySQL из бинарных логов
2 мин
43KБазы данных иногда пропадают. Человеческий фактор и всё-такое… Если вы не делали бекапов (а надо бы) или они уже устарели, не отчаивайтесь, — есть ещё возможность восстановить утерянную информацию.![](https://habrastorage.org/getpro/habr/post_images/842/75d/bb3/84275dbb38214aafef60cd7f25bebcfa.gif)
![](https://habrastorage.org/getpro/habr/post_images/842/75d/bb3/84275dbb38214aafef60cd7f25bebcfa.gif)
+55
Кто победит — слон или кит? Совместная встреча московских групп пользователей MySQL и PostgreSQL.
2 мин
1.7KPostgreSQL и MySQL — две самых распространенных системы управления базами данных в интернете.
![image](http://blog.styleru.net/_files/habrbanner.jpg)
MySQL используется в таких высоконагруженных проектах как Wikipedia, facebook, flickr, Digg, YouTube, на хабрахабре и практически на всех сайтах, работающих под управлением Drupal и Wordpress.
Не уступает и Postgres — без него не работал бы Skype, его используют популярные в Америке социальные сети myyearbook.com и hi5.com, не работали бы без него и наши отечественные Мой Круг, smotri.com и Мир Тесен.
Свежие версии Друпала декларируют поддержку PostgreSQL, а вместо Wordpress можно использовать Movable Type. Из других любопытных приложений, использующих Postgres можно вспомнить 1С: Предприятие 8 и некоторые другие корпоративные информационные системы.
Какая же СУБД лучше? Для каких задач? Как одни и те же задачи решают в разных средах?
22 января 2009 года в Москве при поддержке клуба «Бизнес в стиле .RU» состоится уникальное событие — cовместная встреча московских групп пользователей MySQL и PostgreSQL.
Две команды экспертов (хакеры-разработчики каждой из систем, ведущие технические специалисты крупных проектов) опишут достоинства и недостатки обеих систем и ответят на вопросы гостей.
Предварительный состав участников встречи:
Встреча пройдет в здании Государственного университета — Высшей школы экономики на Покровском бульваре, дом 11 (станции метро Курская/Чкаловская или Китай-город), в аудитории В-201. Вход — со стороны Покровского бульвара, через корпус Е.
Начало — в 19-00.
Для участия во встрече необходимо пройти предварительную регистрацию: reg.styleru.net/registration/pgsqlvsmysql
Итак!
1. Регистрируемся.
2. Приходим к 19-00 на главный вход.
3. Показываем документ (паспорт, водительское удостоверение, студенческий билет, что угодно, где есть ваше имя и фамилия).
4. Проходим по указателям до аудитории В-201 и общаемся с докладчиками!
![image](http://blog.styleru.net/_files/habrbanner.jpg)
MySQL используется в таких высоконагруженных проектах как Wikipedia, facebook, flickr, Digg, YouTube, на хабрахабре и практически на всех сайтах, работающих под управлением Drupal и Wordpress.
Не уступает и Postgres — без него не работал бы Skype, его используют популярные в Америке социальные сети myyearbook.com и hi5.com, не работали бы без него и наши отечественные Мой Круг, smotri.com и Мир Тесен.
Свежие версии Друпала декларируют поддержку PostgreSQL, а вместо Wordpress можно использовать Movable Type. Из других любопытных приложений, использующих Postgres можно вспомнить 1С: Предприятие 8 и некоторые другие корпоративные информационные системы.
Какая же СУБД лучше? Для каких задач? Как одни и те же задачи решают в разных средах?
22 января 2009 года в Москве при поддержке клуба «Бизнес в стиле .RU» состоится уникальное событие — cовместная встреча московских групп пользователей MySQL и PostgreSQL.
Две команды экспертов (хакеры-разработчики каждой из систем, ведущие технические специалисты крупных проектов) опишут достоинства и недостатки обеих систем и ответят на вопросы гостей.
Предварительный состав участников встречи:
- Константин Осипов, Sun/MySQL
- Виктория Резниченко, Sun/MySQL
- Алексей Рыбак, Badoo.com
- Фёдор Сигаев, PostgreSQL Global Development Group
- Олег Бартунов, PostgreSQL Global Development Group
- Андрей Смирнов, NetStream
Встреча пройдет в здании Государственного университета — Высшей школы экономики на Покровском бульваре, дом 11 (станции метро Курская/Чкаловская или Китай-город), в аудитории В-201. Вход — со стороны Покровского бульвара, через корпус Е.
Начало — в 19-00.
Для участия во встрече необходимо пройти предварительную регистрацию: reg.styleru.net/registration/pgsqlvsmysql
Итак!
1. Регистрируемся.
2. Приходим к 19-00 на главный вход.
3. Показываем документ (паспорт, водительское удостоверение, студенческий билет, что угодно, где есть ваше имя и фамилия).
4. Проходим по указателям до аудитории В-201 и общаемся с докладчиками!
+21
Истории
Через год
1 мин
1.1KМожет это и правильно, но как-то неожиданно.
UPD По результатам обсуждения резюмирую:
а) это стандартное поведение и других СУБД и более того
б) данный способ расчета годового периода узаконен и применяется в офлайн.
select
'2008-02-27' + INTERVAL 1 YEAR, -- 2009-02-27
'2008-02-28' + INTERVAL 1 YEAR, -- 2009-02-28
'2008-02-29' + INTERVAL 1 YEAR, -- 2009-02-28
'2008-03-01' + INTERVAL 1 YEAR; -- 2009-03-01
UPD По результатам обсуждения резюмирую:
а) это стандартное поведение и других СУБД и более того
б) данный способ расчета годового периода узаконен и применяется в офлайн.
+49
Представления (VIEW) в MySQL
10 мин
450KВ комментариях Хабра упоминались вопросы по использованию представлений. Данный топик является обзором представлений, появившихся в MySQL версии 5.0. В нем рассмотрены вопросы создания, преимущества и ограничения представлений.
Представление (VIEW) — объект базы данных, являющийся результатом выполнения запроса к базе данных, определенного с помощью оператора SELECT, в момент обращения к представлению.
Представления иногда называют «виртуальными таблицами». Такое название связано с тем, что представление доступно для пользователя как таблица, но само оно не содержит данных, а извлекает их из таблиц в момент обращения к нему. Если данные изменены в базовой таблице, то пользователь получит актуальные данные при обращении к представлению, использующему данную таблицу; кэширования результатов выборки из таблицы при работе представлений не производится. При этом, механизм кэширования запросов (query cache) работает на уровне запросов пользователя безотносительно к тому, обращается ли пользователь к таблицам или представлениям.
Что такое представление?
Представление (VIEW) — объект базы данных, являющийся результатом выполнения запроса к базе данных, определенного с помощью оператора SELECT, в момент обращения к представлению.
Представления иногда называют «виртуальными таблицами». Такое название связано с тем, что представление доступно для пользователя как таблица, но само оно не содержит данных, а извлекает их из таблиц в момент обращения к нему. Если данные изменены в базовой таблице, то пользователь получит актуальные данные при обращении к представлению, использующему данную таблицу; кэширования результатов выборки из таблицы при работе представлений не производится. При этом, механизм кэширования запросов (query cache) работает на уровне запросов пользователя безотносительно к тому, обращается ли пользователь к таблицам или представлениям.
+103
Блокировки в MySQL
4 мин
109KНа хабре часто обсуждаются принципы работы MySQL. Данный хабратопик посвящен механизмам блокировок, используемым в MySQL. Топик поможет начинающим изучать MySQL и, в некоторой степени, опытным хабралюдям.
Одновременный доступ нескольких клиентов к хранилищу данных может приводить к ошибкам различного типа. Например, одновременное чтение одним клиентом и запись другим клиентом одной и той же строки таблицы с большой вероятностью приведет к сбою или чтению некорректных данных. Механизмы блокировок позволяют избежать ситуаций одновременного доступа к данным, регламентируя механизм взаимодействия пользователей между собой.
Механизм блокирования в MySQL
Одновременный доступ нескольких клиентов к хранилищу данных может приводить к ошибкам различного типа. Например, одновременное чтение одним клиентом и запись другим клиентом одной и той же строки таблицы с большой вероятностью приведет к сбою или чтению некорректных данных. Механизмы блокировок позволяют избежать ситуаций одновременного доступа к данным, регламентируя механизм взаимодействия пользователей между собой.
+59
Курсоры в Mysql.
6 мин
111KПо долгу службы мне пришлось сталкиваться с курсорами. Хотелось бы рассказать, что это такое и о некоторых особенностях работы с ними. Официальная документация тут — dev.mysql.com/doc/refman/5.1/en/cursors.html Википедия даёт такое определение курсору курсор:
+36
Форматирование длинных SQL-запросов
1 мин
15KВступил недавно в локальный оффлайн-холивор на тему форматирования длинных SQL-запросов.
Собственно, весь холивор сводится к тому, что удобнее читать — INNER JOIN ДО таблицы, или ПОСЛЕ неё, а так же — AND — до или после обьявления условия.
Два варианта и вопрос к хабровчанам под катом:
Собственно, весь холивор сводится к тому, что удобнее читать — INNER JOIN ДО таблицы, или ПОСЛЕ неё, а так же — AND — до или после обьявления условия.
Два варианта и вопрос к хабровчанам под катом:
+17
Хранение файлов в MySQL и их быстрая раздача
3 мин
97KДумаю у многих возникала необходимость хранить файлы, связанные с записью в таблице. Это может быть картинка к новости, аватар, загруженный пользователем файл — да все, что угодно. Обычно в этому случае поступают просто — файл ложится в файловую систему, а ссылка на него — в запись БД.
Но у такого классического похода множество недостатков:
Больше о проблемах, возникающих при хранении файлов отдельно от БД можно почитать в презентации SQL Antipatterns, раздел Phantom Files, страница 60. Кстати, автор презентации предлагает решение — хранить файлы прямо в БД, в поле типа BLOB. Правда следует замечание, что это должно быть взвешенное решение в каждом конкретном случае. Ведь при таком способе хранения файлов вебсервер должен при каждом запросе вызывать некий скрипт, который будет извлекать файл из БД и отдавать пользователю, что неминуемо отрицательно скажется на производительности.
Для поиска решения данной проблемы был проведен мозговой штурм и придумано несколько вариантов решения проблемы:
Но у такого классического похода множество недостатков:
- файлы не удаляются при удалении соответствующей записи БД
- проблемы при одновременной попытке обновления файла
- нарушение синхронизации между БД и файловой системой при откате транзакции
- при резервном копировании и восстановлении информации в БД может возникнуть рассинхронизация с файловой системой
- файлы не подчиняются ограничениям доступа, наложенным с помощью БД
Больше о проблемах, возникающих при хранении файлов отдельно от БД можно почитать в презентации SQL Antipatterns, раздел Phantom Files, страница 60. Кстати, автор презентации предлагает решение — хранить файлы прямо в БД, в поле типа BLOB. Правда следует замечание, что это должно быть взвешенное решение в каждом конкретном случае. Ведь при таком способе хранения файлов вебсервер должен при каждом запросе вызывать некий скрипт, который будет извлекать файл из БД и отдавать пользователю, что неминуемо отрицательно скажется на производительности.
Для поиска решения данной проблемы был проведен мозговой штурм и придумано несколько вариантов решения проблемы:
+47
Kaj Arnö: MySQL и Sun — как дела?
2 мин
791![Кай Арно Кай Арно](https://habrastorage.org/getpro/habr/post_images/192/019/d9c/192019d9c25eddddd18c02f87f46d178.jpg)
Кай Арно, вице-президент MySQL AB по работе с сообществом пользователей — удивительный человек.
Он родом из Финляндии, а сам по происхождению швед (и похож этим на Линуса Торвальдса).
Он любит Россию, но не знает русского. Это не мешает ему вести свой блог на русском языке — blogs.arno.fi/fandorin.
Для этого он пишет текст на английском, переводит его на русский через Google Translate, и если в обратном переводе с русского на английский ещё что-то можно понять — публикует. Получается неплохо.
В 2001 году он продал MySQL AB половину своей компании, занимающуюся обучением MySQL, и с тех пор работал в корпорации вице-президентом по консалтинговым услугам, вице-президентом по разработке, и в итоге, с 2005 года — вице-президентом по связям с с пользовательским сообществом.
С тех пор как Sun купила MySQL AB в феврале этого года, Кай ездит по всему миру и помогает разработчикам, клиентам и сообществам пользователей Sun и MySQL найти общий язык и научиться сосуществовать в гармонии.
На днях Кай Арно приезжает в Москву и будет рассказывать о том, какой будет новая жизнь MySQL и каковы перспективы его развития при поддержке Sun — компании, которая известна своей благосклонной к opensource-сообществу политикой.
Встречу с Каем организует московская группа пользователей MySQL при поддержке клуба «Бизнес в стиле .RU».
Встреча начнется сегодня, в понедельник 1 декабря в 19-00 в Москве в здании Высшей школы экономики на улице Мясницкой, дом 20, в аудитории 124.
Времени чтобы зарегистрироваться на встречу осталось очень мало, но ещё можно успеть — для этого надо заполнить форму по адресу reg.styleru.net/registration/mmug.
Помимо Кая на встрече выступит Константин Осипов — лидер команды разработчиков ядра MySQL. Он поделится откровениями о том, что нового будет в MySQL 6.0 и расскажет о различных хитростях оптимизации работы версии 5.1, которая на прошлой неделе наконец-то вышла из статуса беты и обрела статус Generally Available.
Итак!
1. Регистрируемся.
2. Приходим к 19-00.
3. Показываем документ (паспорт, водительское удостоверение, студенческий билет, что угодно, где есть ваше имя и фамилия).
4. Проходим по указателям до аудитории и общаемся с докладчиками!
+38
Все то, о чем мы так долго мечтали — первый официальный релиз MySQL 5.1
1 мин
728Собственно сегодня наткнулся на ссылку http://lists.mysql.com/announce/565 и сразу спешу поделиться с хабро-сообществом.
Здесь говорится, что сегодня вышел первый релиз MySQL Server 5.1.30 Generally Available (GA), который является первым релизом, рекомендованным для использования на продакшн серверах.
Основные нововведения в версии 5.1. представлены по этой ссылке http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html
А также описаны в статье tuta_larson — Что нового в MySQL 5.1
Также немаловажно будет ознакомится со списком открытых багов для версии 5.1. — http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html
Ну и собственно ссылка на скачивание — http://dev.mysql.com/downloads/
Здесь говорится, что сегодня вышел первый релиз MySQL Server 5.1.30 Generally Available (GA), который является первым релизом, рекомендованным для использования на продакшн серверах.
Основные нововведения в версии 5.1. представлены по этой ссылке http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html
А также описаны в статье tuta_larson — Что нового в MySQL 5.1
Также немаловажно будет ознакомится со списком открытых багов для версии 5.1. — http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html
Ну и собственно ссылка на скачивание — http://dev.mysql.com/downloads/
+49
MySQL и JOINы
6 мин
148KПоводом для написания данной статьи послужили некоторые дебаты в одной из групп linkedin, связанной с MySQL, а также общение с коллегами и хабролюдьми :-)
В данной статье хотел написать что такое вообще JOINы в MySQL и как можно оптимизировать запросы с ними.
В данной статье хотел написать что такое вообще JOINы в MySQL и как можно оптимизировать запросы с ними.
+81
Ближайшие события
![](https://habrastorage.org/getpro/habr/upload_files/ce8/1f8/4fe/ce81f84fe4c22e2e3ef85388797db6ac.jpg)
Больше событий в календаре
Администрирование
Менеджмент
![](https://habrastorage.org/getpro/habr/upload_files/fd0/255/4d3/fd02554d346912bf8fc4bc81f9406174.png)
Больше событий в календаре
Разработка
Менеджмент
Маркетинг
![](https://habrastorage.org/getpro/habr/upload_files/8ca/d72/5e6/8cad725e62dafcc18e20f6e3dd3f2ccd.png)
Больше событий в календаре
Разработка
Постраничная навигация с MySQL при большом количестве записей
7 мин
41KРано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.
Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.
Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.
+131
Медленный UPDATE vBulletin — в чем подвох?
1 мин
1.1KКупил лицензию на vBulletin на два форума. На одном — летает круглые сутки (около 20000 зарегистрированных пользователей), на другом — начинает тормозить к вечеру (120000 пользователей).
Посещаемость одинаковая — 50-100 человек онлайн. Запустил на тормозящем форуме Debug Mode, оказалось что самый последний запрос занимает вплоть до 16 секунд!
Посещаемость одинаковая — 50-100 человек онлайн. Запустил на тормозящем форуме Debug Mode, оказалось что самый последний запрос занимает вплоть до 16 секунд!
UPDATE user
SET lastactivity = 1226505039
WHERE userid = 1
+6
Оптимизация MySQL запросов
4 мин
125KВ повседневной работе приходится сталкиваться с довольно однотипными ошибками при написании запросов.
В этой статье хотелось бы привести примеры того, как НЕ надо писать запросы.
В этой статье хотелось бы привести примеры того, как НЕ надо писать запросы.
+121
MySQL Query Cache
5 мин
110KВ MySQL есть очень полезная функциональность — кеш запросов. Кеш запросов доступен в MySQL начиная с версии 4.0.
Многие СУБД имеют подобную функциональность, но в отличие от MySQL они кешируют планы выполнения запросов, тогда как MySQL кеширует результаты запросов.
Дальше о том, как работает кеш запросов, как его настраивать и оптимально использовать.
Многие СУБД имеют подобную функциональность, но в отличие от MySQL они кешируют планы выполнения запросов, тогда как MySQL кеширует результаты запросов.
Дальше о том, как работает кеш запросов, как его настраивать и оптимально использовать.
+64
MySQL Performance real life Tips and Tricks. Part 3-rd.
14 мин
23KРешил продолжить цикл заметок по данной тематике. В данной статье особое место хотел уделить профайлингу MySQL запросов. Описать средства, которые предоставляются MySQL для профайлинга, и что нужно делать для определения узких мест запроса.
Также, после опубликования первых двух статей я получил пару отзывов и вопросов, связанных с проектированием БД / расстановкой индексов / составлением запросов. На многие вопросы старался отвечать. С некоторыми из них поделюсь и в этой статье.
Также, после опубликования первых двух статей я получил пару отзывов и вопросов, связанных с проектированием БД / расстановкой индексов / составлением запросов. На многие вопросы старался отвечать. С некоторыми из них поделюсь и в этой статье.
+52
Что нового в MySQL 5.1
3 мин
4.2KОсталось совсем немного времени до выхода MySQL 5.1. В статье будут рассмотрены изменения и новые возможности этой версии.
+78
MySQL Performance real life Tips and Tricks. To be continued.
6 мин
8KПо заявкам трудящихся решил написать еще одну статью, посвященную оптимизации запросов в MySQL.
В прошлой статье habrahabr.ru/blogs/mysql/38907 рассматривались вопросы оптимизации LIMIT, GROUP BY, COUNT.
В данной статье я немного вернусь к вышеописанному и опишу пару примеров, с которыми столкнулся на проекте недавно, после этого приведу еще пару небольших примеров относительно того что такое хорошо и что такое плохо в MySQL.
В прошлой статье habrahabr.ru/blogs/mysql/38907 рассматривались вопросы оптимизации LIMIT, GROUP BY, COUNT.
В данной статье я немного вернусь к вышеописанному и опишу пару примеров, с которыми столкнулся на проекте недавно, после этого приведу еще пару небольших примеров относительно того что такое хорошо и что такое плохо в MySQL.
+76
![](https://assets.habr.com/habr-web/img/practicum-banner-inn.90f37e91.webp)
Вклад авторов
alizar 732.0maghamed 424.0snevsky 400.0olegbunin 346.2moscas 269.0tuta_larson 263.0youROCK 241.0zabivator 206.0mcshadow 197.0rdruzyagin 179.4