Как стать автором
Обновить
3.35

MySQL *

Свободная реляционная СУБД

Сначала показывать
Период
Уровень сложности

MySQL шпаргалки

Время на прочтение3 мин
Количество просмотров818K
Часто, когда разрабатываешь сайт, замечаешь, как на одни и те же грабли наступают разработчики при проектировании базы данных.

Сегодня я решил опубликовать свои шпаргалки, на самые часто встречающиеся ошибки при работе с MySQL.

Читать дальше →
Всего голосов 215: ↑193 и ↓22+171
Комментарии230

Новости

Настройка и оптимизация MySQL сервера

Время на прочтение9 мин
Количество просмотров312K
В этой статье будут описаны различные настройки MySQL, преимущественно те, которые влияют на производительность. Для удобства все переменные разделены по разделам (базовые настройки, ограничения, настройки потоки, кэширование запросов, тайминги, буферы, InnoDB). Сначала уточним имена некоторых переменных, которые изменились в версии 4 MySQL, а в сети продолжают встречаться и старые и новые варианты имен, что вызывает вопросы.
Читать дальше →
Всего голосов 180: ↑171 и ↓9+162
Комментарии19

MySQL Performance real life Tips and Tricks

Время на прочтение9 мин
Количество просмотров37K
Пообещал вчера написать статью о реальных случаях оптимизации БД MySQL.
Пришлось сегодня вставать утром пораньше чтобы воплотить обещанное в жизнь.
Централизованное управление мыслями поддерживать еще сложно, поэтому не судите строго за казусы и ляпсусы в моей статье.

В последнее время приходится достаточно часто заниматься оптимизацией производительности сайтов. И как правило «бутылочным горлышком» в производительности работы этих сайтов является именно БД, ошибки как в архитектуре так и в выполнении запросов. Начиная от неправильной расстановки индексов, либо совершенным их отсутствием, неправильным (неэкономным) выбором типов данных под определенное поле, заканчивая абсолютно нелогичной архитектурой БД и такими же нелогичными запросами.

В данной статье опишу несколько приемов, которые были использованы для приложения с 4млн+ пользователей и которое имея порядка 100млн+ хитов в сутки, а в конце опишу задачу, которая решалась недавно и может быть многоуважаемое сообщество предложит мне решения этой задачи более эффективное нежели то, к которому пришел я.

Читать дальше →
Всего голосов 147: ↑141 и ↓6+135
Комментарии93

Постраничная навигация с MySQL при большом количестве записей

Время на прочтение7 мин
Количество просмотров40K
Рано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.
Читать дальше →
Всего голосов 139: ↑135 и ↓4+131
Комментарии81

Истории

Сайт MySQL.com скомпрометирован через внедрение SQL-кода

Время на прочтение1 мин
Количество просмотров2.9K
Офсайт СУБД MySQL вчера взломан двумя злоумышленниками через банальное SQL injection. По ссылке опубликован отчёт о взломе и выложены некоторые части внутренней структуры базы данных, дамп паролей и т.д.

Vulnerable Target : mysql.com/customers/view/index.html?id=1170
Host IP : 213.136.52.29
Web Server : Apache/2.2.15 (Fedora)
Powered-by : PHP/5.2.13
Injection Type : MySQL Blind
Current DB : web


Хуже всего, что пароли юзеров уже пошли в разработку, в том числе уже расшифрован пароль директора по разработке продуктов MySQL (всего четыре символа), пароли многочисленных админов на форуме и т.д. Так что если у вас есть аккаунт на MySQL.com, то рекомендуется срочно сменить данные регистрации.

Кстати, те же два злоумышленника одновременно взломали и Sun.com тем же способом.
Всего голосов 154: ↑142 и ↓12+130
Комментарии94

Sypex Dumper, Долгожданное обновление до версии 2

Время на прочтение1 мин
Количество просмотров1.9K
Я думаю многие знают о Sypex Dumper, если не знают то это менеджер для работы с MySQL, написанный на php и запускаемый естественно на сервере, раньше он поддерживал только функции импорта \ экспорта БД, Но после 2 летнего перерыва автор выпустил новую версию!
Встречайте Sypex Dumper 2.0.1
image
Читать дальше →
Всего голосов 138: ↑133 и ↓5+128
Комментарии78

PostgreSQL vs MySQL

Время на прочтение8 мин
Количество просмотров346K


В преддверии своего доклада на конференции PGCONF.RUSSIA 2015 я поделюсь некоторыми наблюдениями о важных различиях между СУБД MySQL и PostgreSQL. Этот материал будет полезен всем тем, кого уже не устраивают возможности и особенности MySQL, а также тем, кто делает первые шаги в Postgres. Конечно, не стоит рассматривать этот пост как исчерпывающий список различий, но для принятия решения в пользу той или иной СУБД его будет вполне достаточно.
Читать дальше →
Всего голосов 174: ↑149 и ↓25+124
Комментарии173

Оптимизация MySQL запросов

Время на прочтение4 мин
Количество просмотров124K
В повседневной работе приходится сталкиваться с довольно однотипными ошибками при написании запросов.

В этой статье хотелось бы привести примеры того, как НЕ надо писать запросы.
Читать дальше →
Всего голосов 143: ↑132 и ↓11+121
Комментарии142

Все врут или почему в MySQL лучше не использовать партиции

Время на прочтение8 мин
Количество просмотров27K
Начиная с версии 5.1 в MySQL появилась такая полезная фича как партиции. Конечно же большинство разработчиков БД сразу не побрезговали ей воспользоваться. Спустя пару лет работы я наконец пожал плоды всей ущербности реализации этой технологии специалистами MySQL AB …
но обо всем по порядку
Всего голосов 127: ↑123 и ↓4+119
Комментарии68

MySQL Profiler: простой и удобный инструмент профилирования запросов

Время на прочтение2 мин
Количество просмотров46K
Сегодня был неожиданно удивлен, какие удобные штуки таит в себе MySQL. ;-)

Хочу представить вашему вниманию фичу MySQL — профайлинг.
Появилась она начиная с версии 5.0.37.

Всего парой запросов можно узнать, какими запросами формируется страница (для веб-девелоперов)
и почему она тормозит.

И раньше подобный функционал был доступен, но пользоваться журналом запросов не в пример сложнее.

Итак, как пользоваться:


Читать дальше →
Всего голосов 132: ↑125 и ↓7+118
Комментарии52

Девушка с татуировкой ANSI

Время на прочтение2 мин
Количество просмотров19K
Специалисты по СУБД с сайта Oracle WTF заинтересовались, что же такое печатает в терминале юный хакер в фильме «Девушка с татуировкой дракона». По сюжету, это были запросы к базе данных полицейского отделения, с помощью которых она раскрыла убийства 40-летней давности.


Читать дальше →
Всего голосов 226: ↑171 и ↓55+116
Комментарии286

Uber — причины перехода с Postgres на MySQL

Время на прочтение19 мин
Количество просмотров102K


В конце июля 2016 года в корпоративном блоге Uber появилась поистине историческая статья о причинах перехода компании с PostgreSQL на MySQL. С тех пор в жарких обсуждениях этого материала было сломано немало копий, аргументы Uber были тщательно препарированы, компанию обвинили в предвзятости, технической неграмотности, неспособности эффективно взаимодействовать с сообществом и других смертных грехах, при этом по горячим следам в Postgres было внесено несколько изменений, призванных решить некоторые из описанных проблем. Список последствий на этом не заканчивается, и его можно продолжать еще очень долго.


Наверное, не будет преувеличением сказать, что за последние несколько лет это стало одним из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле «Postgres vs MySQL» идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.

Читать дальше →
Всего голосов 112: ↑110 и ↓2+108
Комментарии58

Простая замена phpMyAdmin для гиков

Время на прочтение2 мин
Количество просмотров14K
Довольно часто возникает ситуация, когда надо быстренько запустить пару запросов к MySQL базе у клиента на сервере. При этом есть только FTP и параметры соединения с СУБД. Самый простой выход — загрузить туда phpMyAdmin, ну а дальше дело техники. Обычно все это проиcходит на фоне того, что у клиента уже установлена какая-то CMS — WordPress, Drupal, Joomla…

Я люблю простые, красивые и удобные вещи. Я тепло отношусь к phpMyAdmin но в 90% моих Use Cases мне он не нужен. Нужно что-то простое. В идеале такое, что можно просто залить на сервер и открыть в браузере — не настраивая.

Пара вечеров и пакет готов.
Читать дальше →
Всего голосов 120: ↑114 и ↓6+108
Комментарии116

Ближайшие события

Несколько интересных особенностей MySQL

Время на прочтение8 мин
Количество просмотров63K
В не очень далеком прошлом мне пришлось покопаться немного в исходном коде MySQL, и разобраться в некоторых аспектах его работы. В ходе работы лопаткой, и эксперимeнтов, я наткнулся на несколько очень интересных особенностей, часть из которых просто забавна, а в случае некоторых бывает очень интересно понять, чем руководствовался программист, который принимал решение сделать именно так.

Начнем с такого интересного типа, как ENUM.

mysql> CREATE TABLE enums(a ENUM('c', 'a', 'b'), b INT, KEY(a));
Query OK, 0 rows affected (0.36 sec)

mysql> INSERT INTO enums VALUES('a', 1), ('b', 1), ('c', 1);
Query OK, 3 rows affected (0.05 sec)
Records: 3  Duplicates: 0  Warnings: 0


Итак, у нас есть таблица, в ней есть два столбца. У первого, a, тип ENUM, у второго, b, INT. В таблице три строки, у всех трех значение b равно 1. Интересно, чему равны минимальный и максимальный элементы в столбце a?

mysql> SELECT MIN(a), MAX(a) FROM enums;
+--------+--------+
| MIN(a) | MAX(a) |
+--------+--------+
| c      | b      |
+--------+--------+
1 row in set (0.00 sec)


Кажется странным, было бы разумно, если бы самым маленьким был 'a', а самым большим — 'c'.
А что если выбрать минимум и максимум только среди тех строк, где b = 1? То есть, среди всех строк?

mysql> SELECT MIN(a), MAX(a) FROM enums WHERE b = 1;
+--------+--------+
| MIN(a) | MAX(a) |
+--------+--------+
| a      | c      |
+--------+--------+
1 row in set (0.00 sec)


Вот так мы заставили MySQL поменять свое мнение о том, как сравнивать поля в ENUM, просто добавив предикат.
Разгадка такого поведения заключается в том, что в первом случае MySQL использует индекс, а во втором нет. Это, конечно, не объясняет, почему MySQL сравнивает ENUMы по разному для сортировки в индексе, и при обычном сравнении.

Второй пример проще и лаконичнее:

mysql> (SELECT * FROM moo LIMIT 1) LIMIT 2;
+------+
| a    |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)


Когда я показал этот запрос своему коллеге, который занимается разработкой парсера SQL, его вопрос был не «почему этот запрос возвращает две строки», а «как надо написать SQL парсер так, чтобы такой запрос был валидным, без того, чтобы написать правило, специально разрешающее такой запрос».

Интересно, что далеко не любой SELECT в скобках сработает, в частности, UNION в скобках — это синтаксическая ошибка:

mysql> (SELECT * FROM moo UNION ALL SELECT * FROM hru) LIMIT 2;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UNION ALL SELECT * FROM hru) LIMIT 2' at line 1


Еще несколько интересных примеров под катом
Читать дальше →
Всего голосов 113: ↑110 и ↓3+107
Комментарии95

MySQL: разрушаем стереотипы

Время на прочтение5 мин
Количество просмотров59K
В последнее время часто стал натыкаться на различные рассуждения людей, по поводу того, что MySQL — это плохо, это очень плохо — потому что… а вот дальше идут описания различных фич MySQL, которые четко документированы, но пользователь их просто не знает. Кто-то добавляет в БД данные без валидации и удивляется почему они сохранились в неверном формате, а кто-то описывает кучу особенностей myIsam движка, и на этих основаниях делает вывод, что MySQL это отстой — который невозможно использовать в реальных проектах. Всю документацию прочитать невозможно, и да — я с этим абсолютно согласен, но поверьте у нас есть куча других недокументированных и не менее интересных особенностей. Давайте начнем с малого, к примеру докажем, что NULL равно нулю.
это новогодний пост - отнеситесь к нему с юмором, качаем последний MySQL и поехали
Всего голосов 131: ↑118 и ↓13+105
Комментарии125

Как MySQL оптимизирует ORDER BY, LIMIT и DISTINCT

Время на прочтение16 мин
Количество просмотров15K
Есть задачи, которые в рамках реляционных СУБД не имеют универсальных решений и для того чтобы получить хоть какой-то приемлемый результат, приходится придумывать целый набор костылей, который ты потом гордо называешь “Архитектура”. Не так давно мне как раз встретилась именно такая.

Предположим, имеется некоторые сущности А и Б, связанные между собой по принципу One-to-Many. Количество экземпляров данных сущностей достаточно велико. При отображении сущностей для пользователя необходимо применить ряд независимых критериев, как для сущности А так и для сущности Б. Причем результатом применения критериев являются множества достаточно большой мощности — порядка нескольких миллионов записей. Критерии фильтрации и принцип сортировки задается пользователем. Как (я бы ещё спросил: Зачем им миллионы записей на одном экране? — но говорят надо) показать все это пользователю за время 0 секунд?
Решать такие задачи всегда интересно, но их решение сильно зависит от СУБД, под управлением которой крутится твоя база данных. Если у тебя в рукаве козырной туз в виде Oracle, то есть шанс, что эти костыли он подставит сам. Но спустимся на землю — у нас есть только MySQL, так что придется почитать теорию.
Далее ...
Всего голосов 115: ↑110 и ↓5+105
Комментарии18

Как FriendFeed использует MySQL для хранения данных без схемы

Время на прочтение7 мин
Количество просмотров3.2K

Условия


Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

Все взвесив, мы решили создать систему хранения данных без схемы поверх MySQL, вместо использования полностью нового решения. В этой статье я попытаюсь описать основные детали системы. Так же нам любопытно как другие сайты решили эти проблемы. Ну и мы думаем, что наша работа будет полезна другим разработчикам.
Читать дальше →
Всего голосов 116: ↑110 и ↓6+104
Комментарии60

Как новость про +4 выходных дня уронила нам базу данных

Время на прочтение6 мин
Количество просмотров48K
Этот день — яркий пример того, как несколько вещей, которые сами по себе не приводят к отказу, могут удачно совпасть. Итак, 23 апреля было совершенно обычным днём, с обычным трафиком и обычной загрузкой ресурсов. Как обычно, с запасом больше трети, чтобы при потере любого из ЦОДов пережить это без проблем. Никто не думал, что к серверному мониторингу нужно прикручивать ещё мониторинг того, что говорит президент на прямой линии, поэтому дальше случилось вот что:



Примерно в 13:30 у нас резко подскочила нагрузка на поиск по авиации и по железнодорожным билетам. Где-то в этот момент РЖД сообщила о перебоях на сайте и в приложении, а мы начали экстренно наливать дополнительные инстансы бекендов во всех ЦОДах.

Но на самом деле проблемы начались раньше. Примерно в 8 утра мониторинг прислал алерт про то, что на одной из реплик базы данных у нас что-то подозрительно много долгоживущих процессов. Но мы это прошляпили, сочли не очень важным.
Читать дальше →
Всего голосов 111: ↑107 и ↓4+103
Комментарии53

mysqlnd — проводник между PHP и MySQL

Время на прочтение16 мин
Количество просмотров66K


Расширение mysqlnd появилось ещё в PHP 5.3, но до сих пор малоизвестно среди разработчиков. Однако оно незаменимо, если ваша система основана на MySQL. Если вы хотите узнать, почему это расширение так важно, что оно собой представляет, как его использовать и какие оно даёт преимущества — читайте статью.
Читать дальше →
Всего голосов 129: ↑116 и ↓13+103
Комментарии35

Необычное переполнение жесткого диска или как удалить миллионы файлов из одной папки

Время на прочтение4 мин
Количество просмотров157K

Предисловие


Скорей всего, матерым системным администраторам статья будет не очень интересна. В первую очередь она ориентирована на новичков, а также на людей, которые столкнулись с подобной проблемой — необходимостью удалить огромное количество файлов из одной папки в ОС Linux (Debian в моем случае), а также с закончившимся местом на диске, когда df -h выдает что почти 30% свободно.
Читать дальше →
Всего голосов 111: ↑107 и ↓4+103
Комментарии144
1
23 ...