MySQL *

Доброго времени суток.

Очень хотелось поднять вопрос о древовидных структурах в MySql. А конкретно о выборках и хранении данных…
Пользователям Oracle и PostgresSQL живется хорошо, в этих БД есть встроенные средства выборки рекурентных данных (см. Иерархические (рекурсивные) запросы).
Пользователям Mysql приходится работать уже с тем, что есть, то есть работа на стороне клиента.
Поскольку эта тема не однократно поднималась, то я попробую рассказать о конкретной задаче и способе её решения.

Так получилось, что я довольно давно не работал с MySQL, поскольку в Рамблере используется, в основном, PostgreSQL. Сейчас у меня, наконец, появилось свободное время, и я решил догнать упущенное. Как выяснилось, за последние полтора года в мире MySQL изменилось довольно многое.

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

В недавнем своем топике я приводил три на мой взгляд интересные задачи по MySQL с желанием посмотреть на возможные решения хабралюдьми. Как я и обещал, я привожу свои решения этих задач. Для того, чтоб текст был интересным и познавательным я решил детально разжевать что зачем и как. Итак…

Сегодня был неожиданно удивлен, какие удобные штуки таит в себе MySQL. ;-)

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

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

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

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

Буквально несколько часов назад, после внимательного изучения комментариев вот к этому топику я был несколько удивлен что многие не очень любят использовать условия HAVING и похоже другие возможности СУБД. Скажу прямо — мне очень понравилась обсуждение простейшего и не работающего запроса, в результате которого многие узнали для себя много нового и познавательного (это мое личное мнение). Поэтому я решил сделать вот что — вывести три моих самых любимых задачи по знанию SQL (MySQL) на суд общественности.

Данные задачи абсолютно реальные, и в отдаленном светлом прошлом действительно имели место, и были благополучно решены жертвой некоторого количества рабочего времени и нервных клеток. Я уверен на 100% что они актуальны и по сей день, и будут актуальны еще долго. Сложными их назвать нельзя, но и очень простыми тоже (в зависимости от уровня подготовки конечно).

В MySQL 5 есть несколько типов данных для хранения даты и времени. Это TIMESTAMP, DATE, DATETIME, TIME и YEAR. Все они обладают своими особенностями, и выбор в пользу того или иного календарного типа должен производиться отдельно в каждой конкретной ситуации. Я хотел бы поделиться с вами результатом моего сегодняшнего миниисследования этих типов, в том числе в аспекте работы с временными зонами.

Статья о том, как избежать путаницы с датами, хранимыми в mysql.
Эти путаницы возникают по двум причинам:
1. Разные территории нашей планеты имеют разный сдвиг времени.
2. Некоторые страны переходят на летнее время и обратно(карта со странами, переходящими на летнее время).

Многие решают эти проблемы по-разному. Кто-то делает сдвиг даты в SQL запросах, кто-то в php. Кто-то хранит даты в TIMESTAMP, кто-то в DATETIME. Я переискал много источников, но нигде не нашел верного решения данной проблемы на русском. В родной документации по mysql нашел информацию о том, как добиться корректной автоматической конвертации TIMESTAMP в локальное время, но тут тоже свои подводные камни.

Если в php настройка временной зоны делается просто, в mysql возникают сложности, особенно, если доступ к mysql серверу вам ограничен и там еще не установлены некоторые таблицы.

Компания Sun Microsystems и Образовательный Центр i∙klass и приглашают вас на семинар «Производительность MySQL».

Докладчик:
Дмитрий Кравчук, Principal Benchmark Engineer, Sun Microsystems, Париж, Франция

Здравствуйте. В этой статье я хотел бы написать про один очень интересный способ хранения иерархических структур в базах данных, не относящийся при этом к общепринятым и общеизвестным трём (Adjacency List, Nested Set, Materialized Path). Я не встречал в интернете упоминания о нём, о чём очень удивлен, ведь, по моему мнению, — это лучший и единственный способ хранить иерархические структуры. При разработке console-like форума я воспользовался именно этим способом, о чём ни на грамм не жалею. Это авторская статья и ни одно предложение не было вставлено метотодом копипаста.

Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.

Несмотря на то, что ещё в середине июня 2008 года Джим Старки (в тот момент глава команды, работающей над движком Falcon) покинул проект, и вообще на весьма туманные перспективы использования данного движка в следующих версиях mySQL, хотелось бы поделиться тем, что разработчики хотели в нём реализовать.

Цель этой статьи — дать краткий, очень сжатый обзор движков, для того, чтобы статьей можно было пользоваться при выборе движка на этапе проектирования \ создания \ оптимизации таблицы. Предполагается, что читатель знает суть вопроса по крайней мере поверхностно и способен сам отыскать всю дополнительную информацию (вопросы в комментах можно задавать всегда :) )

Один хороший человек хочет попасть на хабр. Для подтверждения своих благих намерений он написал статью, которую я привожу вам.

Наверняка многие знают о существовании в mySQL функции FOUND_ROWS(). Её чаще всего используют для подсчета общего числа строк в таблице, удовлетворяющих заданным условиям. Используют её обычно совместно с директивой SQL_CALC_FOUND_ROWS следующим образом:

Mysql> SELECT SQL_CALC_FOUND_ROWS * FROM table WHERE column > 1 LIMIT 0, 50;
Mysql> SELECT FOUND_ROWS();

Результатом второго запроса будет общее количество строк в таблице «table», удовлетворяющих условию «column > 1» (а не только тех, что были возвращены первым запросом).
Следует учитывать некоторые особенности этой функции, когда используете её без директивы SQL_CALC_FOUND_ROWS, о чём добросовестно предупреждает документация mySQL: в этом случае она вернёт общее количество обработанных строк (не возвращённых!). Например:

Mysql> SELECT * FROM table LIMIT 0, 50;
Mysql> SELECT FOUND_ROWS();

Результатом, как и ожидается, будет «50». Но следующие запросы вернут не слишком ожидаемый результат:

Mysql> SELECT * FROM table WHERE column > 1 LIMIT 50, 50;
Mysql> SELECT FOUND_ROWS();

Несмотря на то, что первый запрос вернёт 50 строк, результатом будет «100», т.к. mySQL пришлось просмотреть именно 100 строк.

денормализация — это зло, или просто надо уметь её готовить?

Денормализация- это не результат кривых рук. Это не недоделанная нормализация, это намеренное нарушение нормальных форм, для увеличения производительности.
Вопрос о денормализации у меня возникал не раз. Каждый раз, когда приходилось идти на сделку с совестью, нарушая принципы нормальных форм, оставалось ощущение неудовлетворённости, ложное осознание своей некомпетентности. Со временем, при работе в команде, обнаружилось, что это не только моя проблема. Настало время разобраться: денормализация — это зло, или просто надо уметь её готовить?

Задача

Задача такая же как и в предыдущей статье, только применимо к MySQL.

Грабли

Хорошая новость ребята! В MySQL нет проблемы с рекурсивными триггерами! Разработчики MySQL просто тупо лочат изменяемую таблицу даже на уровне триггера, вот редиски. Но, собственно, нас может остановить только отключение электричества.
Есть небольшая лазейка, с… объединенными таблицами. Хотя я не нашел в документации подтверждения того, что это так специально было задумано, но и отрицания тоже не было. Правда есть вероятность того, что эту лазейку могут прикрыть, хотя я не вижу в этом смысла.
Увы, механизм триггеров в MySQL новый и довольно сырой, что накладывает некоторые ограничения на его использование, но все же его достаточно для решения нашей задачи.

Доброго времени суток. Недавно я задался вопросом о том, как делать горячие BackUp`ы MySQL-серверов — ниже компиляция из прочитанного. Заранее хочу сказать, что данный пост является скорее большой заметкой, чем полноценной статьёй. Я намеренно уклоняюсь от описания синтаксиса — на эту тему уже немало написано — я же ставил перед собой другую цель — составить краткий обзор основных методов с характерными особенностями:

Хочу поделиться простым эмпирическим методом, который я использую для определения того, в каком порядке должны идти столбцы в составном индексе. Этот способ подходит не только для MySQL, он также применим к любым СУБД, в которых используются b-tree индексы.

Давайте начнем с запроса, который возвращает пустой результат, но при этом делает полный скан таблицы. EXPLAIN покажет на нем, что нет доступных индексов (т.е. possible_keys = NULL)

SELECT * FROM tbl
WHERE
  status='waiting' AND
  source='twitter' AND
  no_send_before <= '2009-05-28 03:17:50' AND
  tries <= 20
ORDER BY date ASC LIMIT 1;


На Хабре прошла незамеченной интересная новость о том, что Монти Вайдениус, которого называют «отцом MySQL», а также Пётр Зайцев (основатель компании Percona) объявили о создании общественной организации Open Database Alliance, под крышей которой предлагается объединить все проекты, связанные с MySQL. По мнению основателей организации, будущее MySQL выглядит неопределённо в свете покупки Sun компанией Oracle. Новый альянс должен стать центром разработки MySQL и главным хабом по превращению этой СУБД в поистине открытую и прозрачную систему.

В данной ситуации речь идёт даже о том, чтобы переделать MySQL в стиле Dizzle. Говорят, что этот проект начался ещё в январе 2009 года в стенах Sun, а теперь Вайдениус/Зайцев с помощью сообщества могут продолжить его уже независимо от нового владельца MySQL.

via PRWeb, slashdot

Когда Ларри Эллисон, директор Oracle, объявил в понедельник о покупке компании Sun, он ни словом не обмолвился о MySQL, своём конкуренте на рынке малых СУБД. Именно этот сегмент остаётся непокрытым в продуктовой линейке Oracle. Все хорошо помнят, как страстно Ларри Эллисон жаждал завладеть этой шведской компанией три года назад. В течение всего 2006 года Ларри Эллисон неоднократно предлагал выкупить MySQL, но трое друзей-шведов, основателей MySQL, неизменно отвергали его предложение от «империи зла», взлёт которой произошёл благодаря сотрудничеству с ЦРУ, после чего MySQL в итоге продалась Sun.

Теперь же мечта Эллисона сбылась, и он даже не говорит, что купил Sun только ради MySQL.

В свете всех известных фактов очень странно смотрятся размышления некоторых аналитиков о том, что MySQL не является конкурентом Oracle. Это слишком узкий взгляд на вещи, потому что не принимаются в расчёт долговременные планы Эллисона, а также перспективы развития самой MySQL (например, в версии 5.4 этой СУБД уже появилась поддержка 16-процессорных серверов x86, а по некоторым тестам производительность выросла на 40000%).

Кстати, по странной случайности выход MySQL 5.4 был запланирован на 21 апреля, но за день до этого произошла сделка с Oracle.

via betanews