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

С репликацией серверов MySQL я познакомился относительно недавно, и по мере проведения разных опытов с настройкой, записывал, что у меня получалось. Когда материала набралось достаточно много, появилась идея написать эту статью. Я постарался собрать советы и решения по некоторым самым основным вопросам, с которыми я столкнулся. По ходу дела я буду давать ссылки на документацию и другие источники. Не могу претендовать на полноту описания, но надеюсь, что статья будет полезной.

Я подумал, что здесь наверняка мне помогут решить мою задачу. Я пользовался на сайте движком php+mysql Virtuanews (virtuanews.co.uk), сейчас уже поддержка этого движка закрыта и домен не работает. Так вот, я решил поменять движок на сайте, на WordPress 2.7.1 (Lecactus Edition) и ищу у Вас помощи, сконвертировать базу mysql, в формат WordPress, чтобы импортировать посты. Как делать импорт-экспорт я знаю, а как базу (ту её часть, в которой содержаться топики и заголовки) сконвертировать или сделать ещё какие нибудь шаманские действия для того, чтобы все новости появились в WordPrese? Если кто нибудь знает — подскажите пожалуйста! Базу, которую нужно привести к формату WordPress я выложил на Народ narod.ru/disk/7405716000/db_backup_05-04-2009.sql.html (она весит около 11 мегабайт). Заранее спасибо за помощь!

Последнее время оживилась публика с вопросом случайной выборки из таблицы. Решений по оптимизации полно, и нового сейчас я вам наверное ничего не покажу, просто напомню про основные методы оптимизации — упрощение запроса и индексацию. Без предисловий про фриленсеров, сразу к делу ;)

По долгу службы приходится глубоко разбираться с сабжем.
К сожалению, это не самое лучшее изобретение человечества, поэтому иногда приходится вбивать костыли, чтобы хоть как-то пользоваться этой штукой.

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

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

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

SET @mytable='users';
SELECT * FROM @mytable;

Такая конструкция работать не будет. А что же делать, чтобы она заработала?

Marten Mickos (Мартен Микос?), занимавший пост исполнительного директора MySQL AB до того, как Sun купила компанию, увольняется. После поглощения MySQL AB, Мартен занял пост вице-президента по направлению «базы данных» (senior vice president of Sun Microsystems' database group).