<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
	<title>Хабрахабр / MySQL / Захабренные</title>
	<link>http://habrahabr.ru/rss/blog/mysql/</link>
	<description><![CDATA[Захабренные посты из блога «MySQL» на Хабрахабре]]></description>
	<language>ru</language>
	<managingEditor>editor@habrahabr.ru</managingEditor>
	<generator>habrahabr.ru</generator>
	<pubDate>Fri, 10 Feb 2012 16:34:09 GMT</pubDate>
	<lastBuildDate></lastBuildDate>
	<image>
		<link>http://habrahabr.ru/</link>
		<url>http://habrahabr.ru/i/logo.gif</url>
		<title>Хабрахабр</title>
	</image>
	
		
		
	<item>		
		<title><![CDATA[MySQL / Резервное копирование данных в MySQL]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/137380/</guid>
		<link>http://habrahabr.ru/blogs/mysql/137380/</link>			
		<description><![CDATA[Резервное копирование базы данных — это такая штука, которую вечно приходится настраивать для уже работающих проектов прямо на «живых» production-серверах. <br/>
Подобная ситуация легко объяснима. В самом начале любой проект еще пуст и там просто нечего копировать. В фазе бурного развития головы немногочисленных разработчиков заняты исключительно прикручиванием фишек и рюшек, а также фиксом критических багов с дедлайном «позавчера». И только когда проект «взлетит», приходит осознание, что главная ценность системы — это накопленная база данных, и её сбой станет катастрофой. <br/>
Эта обзорная статья — для тех, чьи проекты уже достигли этой точки, но жареный петух ещё не клюнул. <br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/137380/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Tue, 31 Jan 2012 20:33:13 GMT</pubDate>
		<author>chainik</author>
		<category>mysql</category><category>replication</category><category>backup</category><category>всякаяхрень</category><category>велосипед</category>
	</item>
	
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[MySQL / [Из песочницы] Mysql performance]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/135775/</guid>
		<link>http://habrahabr.ru/blogs/mysql/135775/</link>			
		<description><![CDATA[Написание этой статьи навеяно вот этой трилогией: <a href="http://habrahabr.ru/blogs/mysql/38907/">один</a>, <a href="http://habrahabr.ru/blogs/mysql/39260/">два</a>, <a href="http://habrahabr.ru/blogs/mysql/39818/">три</a>. Захотелось добавить свои 0.02$, по использованию трюков и особенностей.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/135775/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Fri, 06 Jan 2012 11:49:36 GMT</pubDate>
		<author>Casus</author>
		<category>mysql performance tricks</category>
	</item>
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[MySQL / [Из песочницы] Использование бинарного поиска для оптимизации запроса на выборку данных]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/134417/</guid>
		<link>http://habrahabr.ru/blogs/mysql/134417/</link>			
		<description><![CDATA[<h4>Введение</h4><br/>
Сейчас очень популярна тем оптимизации работы с различными СУБД. На многочисленных форумах ведутся дискуссии о «самой лучшей СУБД в мире», но часто все это перетекает в необоснованные выкрики о том, что «я познал смысл жизни и понял, что самое лучшее хранилище данных — Х».<br/>
<br/>
Да, несомненно, сейчас мы можем наблюдать активное развитие NoSQL решений, которые позволяют делать многое. Но данная статья не о них. Так вышло, что я сменил работу и в нагрузку мне достался один очень интересный проект на связке php+MySQL. В нем есть много хороших решений, но он писался без расчёта на большую аудиторию. За несколько лет существования количество активных пользователей начало приближаться к числам с 7 нулями. Так как проект представляет из себя подобие социальной сети с игровыми элементами, то таблица с пользователями оказалась не самой «тяжёлой» из всех. В наследство мне достались таблицы с десятками миллионов вещей пользователей, личных сообщений, биллинговыми записями и т. п. Проект начали рефакторить, разбивать на несколько серверов и достигли значительных результатов. Сейчас все стабильно.<br/>
<br/>
Но недавно мне на почту прислали новую задачу. Суть заключалась в сборе статистики. Проанализировав требования я понял, что для выполнения достаточно написать один единственный запрос, выполняющий 3 INNER JOIN'а на таблицы, размеры которых впечатляли. Каждая таблица в среднем содержала 40 миллионов записей. Получается, что временная таблица состояла бы из 4*4*4*10^21 = 64*10^21 записей. Это колоссальная цифра. И загружать СУБД таким запросом для сбора статистики — непозволительная роскошь. <br/>
<br/>
Далее, собственно, я и хочу представить решение данной абстрактной задачи, которое пришло мне в голову, когда я вспоминал занятия по информатике на первом курсе университета.<br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/134417/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Mon, 12 Dec 2011 01:56:57 GMT</pubDate>
		<author>kazmiruk</author>
		<category>mysql</category><category>базы данных</category><category>бинарные деревья</category><category>оптимизация</category><category>алгоритмы</category>
	</item>
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[MySQL / [Из песочницы] Репликация MySql -&gt; Oracle средствами Tungsten Replicator]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/134179/</guid>
		<link>http://habrahabr.ru/blogs/mysql/134179/</link>			
		<description><![CDATA[Итак, в начале несколько слов, а-ля предисловие. Данный мануал не претендует на истину в первой инстанции и на построчное руководство. Скрипты можно написать куда лучше. Команды — на момент прочтения могут звучать уже по другому (даже на момент написания документация на сайте разниться с реальными командами). Многое в скриптах сделано под рутом, что в целом тоже не правильно, но для «что бы заработало а потом поправить» — оставил пока что так. Ответы на базовые вопросы по настройке Вы найдете в документации на сайте tungsten-а (http://code.google.com/p/tungsten-replicator/). <br/>
<br/>
Задача:<br/>
<br/>
Возникла необходимость в репликации с MySql (5.5) на Oracle (11.2) на сервере с CentOS 5.5. При чем не всего-всего, а только больших таблиц, очень-очень быстро наполняющихся и связанных со статистикой. Добавим к этому, что на сервере MySql наблюдаются проблемы с местом, и как вывод — фильтрация репликации должна происходить на нем. Ну, и при необходимости — сразу подчищаться все возможные временные файлы, опять же по причине места, на обоих серверах.<br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/134179/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Wed, 07 Dec 2011 13:20:23 GMT</pubDate>
		<author>Garr</author>
		<category>mysql</category><category>oracle</category><category>tungsten</category><category>replication</category>
	</item>
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[MySQL / [Из песочницы] Оптимизация запросов MySQL с использованием пользовательских переменных]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/133781/</guid>
		<link>http://habrahabr.ru/blogs/mysql/133781/</link>			
		<description><![CDATA[<b>Введение.</b> В современном мире существует большое количество задач, в рамках которых приходится обрабатывать большие массивы однотипных данных. Яркими примерами являются системы для анализа биржевых котировок, погодных условий, статистики сетевого трафика. Многие из этих систем используют различные реляционные базы данных, в таблицах которых содержатся такие объемы данных, что правильное составление и оптимизация запросов к этим таблицам становится просто необходимым для нормального функционирования системы. В этой статье описаны методы решения ( и сравнительные временные характеристики используемых методов ) нескольких задач по получению данных из таблиц СУБД <i>MySQL</i>, содержащих статистику о проходящем через маршрутизаторы одного из крупных российских сетевых провайдеров сетевом трафике. Интенсивность потока данных, поступающего с главного маршрутизатора такова, что ежесуточно в таблицы базы данных используемой системы мониторинга сетевого трафика поступает в среднем от 400 миллионов до миллиарда записей, содержащих информацию о транзакциях <i>TCP/IP</i> (рассматриваемый маршрутизатор экспортирует данные по протоколу <i>netflow</i>). В качестве СУБД для системы мониторинга используется <i>MySQL</i>.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/133781/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Thu, 01 Dec 2011 22:20:17 GMT</pubDate>
		<author>deadka</author>
		<category>mysql</category><category>оптимизация запросов</category><category>innodb</category><category>myisam</category>
	</item>
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[MySQL / [Из песочницы] Деперсонализация базы MySQL. Интересная техника]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/132869/</guid>
		<link>http://habrahabr.ru/blogs/mysql/132869/</link>			
		<description><![CDATA[<img src="http://servernews.ru/assets/images/articles/593698/mysql.jpg" alt="image"/><br/>
<br/>
В компании, где я работаю, мы используем деперсонализированную базу с Production-a. Ее суммарный объем на данный момент около 30 ГБ. Обфускация ruby скриптом занимала около 6 часов. Ускорение обработки можно добиться, если переписать это все в хранимую процедуру (stored procedure). Но у нас в проекте они запрещены… Увы и ах.<br/>
<br/>
Тогда я задался вопросом: можно ли ускорить процесс по максимуму, деперсонализировать всю базу (или хотя бы полностью одну таблицу) используя только один оператор update? Проблема в том, что некоторые поля д.б. уникальными, а некоторые случайными значениями из списка.<br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/132869/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Thu, 17 Nov 2011 21:32:15 GMT</pubDate>
		<author>xSRGx</author>
		<category>mysql</category><category>case</category><category>техника</category><category>ssn</category><category>деперсонализация</category>
	</item>
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[MySQL / [Из песочницы] Аутентификация через PAM в MySQL]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/131410/</guid>
		<link>http://habrahabr.ru/blogs/mysql/131410/</link>			
		<description><![CDATA[На Хабре уже <a href="http://habrahabr.ru/blogs/mysql/126519/">писалось</a>, что в MySQL появилась возможность подменять встроенную процедуру аутентификации, загрузив соответствующий плагин. В таком плагине можно реализовать совершенно произвольную политику аутентификации пользователей, полностью уходя от традиционной в MySQL схемы <b>username</b>/<b>password</b> в таблице <b>mysql.user</b>.<br/>
<br/>
А недавно Оракл выпустил <a href="http://dev.mysql.com/doc/mysql-security-excerpt/5.5/en/pam-authentication-plugin.html">PAM authentication plugin</a>. При использовании которого сервер не ищет пароли в <b>mysql.user</b>, а перекладывает задачу аутентификации на <abbr title="Pluggable Authentication Modules">PAM</abbr>, подсистему специально разработанную для решения задач аутентификации в различных приложениях и контекстах, с гибко настраиваемыми правилами и на лету подключаемыми модулями.<br/>
<br/>
К сожалению, у этого плагина есть несколько недостатков. Во-первых, он распространяется только с коммерческой версией MySQL и его исходники закрыты. Во-вторых, он не поддерживает коммуникацию между пользователем и pam-модулем, и единственно возможной остается аутентификация по паролю. <s>Что, как-бы, убивает всю идею.</s><br/>
<br/>
«А почему-бы...» — подумал я. «Я напишу свой pam-плагин, с блэкджеком и шлюхами!»<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/131410/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Fri, 28 Oct 2011 09:12:25 GMT</pubDate>
		<author>petropavel</author>
		<category>mysql</category><category>plugin</category><category>authentication</category><category>pam</category>
	</item>
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[MySQL / [Из песочницы] MySQL репликация one-slave-multi-master]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/131111/</guid>
		<link>http://habrahabr.ru/blogs/mysql/131111/</link>			
		<description><![CDATA[<h4>Предисловие.</h4><br/>
Понадобилось сделать репликацию несколькими мастер-серверами с mysql, чтобы данные со всех них грузились на один слэйв-сервер. Готового решения стандартными средствами не нашлось. Но так как проблема оставалась актуальной, со временем подоспел немного усложненный, но работоспособный вариант c использованием средств самой mysql.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/131111/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Mon, 24 Oct 2011 14:22:43 GMT</pubDate>
		<author>printercu</author>
		<category>mysql</category><category>mysqld_multi</category><category>federated</category><category>replication</category><category>multi-master replication</category><category>репликация</category>
	</item>
	
	
	
	
	

		
	<item>		
		<title><![CDATA[MySQL / Все врут или почему в MySQL лучше не использовать партиции]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/130999/</guid>
		<link>http://habrahabr.ru/blogs/mysql/130999/</link>			
		<description><![CDATA[Начиная с версии 5.1 в MySQL появилась такая полезная фича как партиции. Конечно же большинство разработчиков БД сразу не побрезговали ей воспользоваться. Спустя пару лет работы я наконец пожал плоды всей ущербности реализации этой технологии специалистами MySQL AB … <br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/130999/#habracut">но обо всем по порядку</a> </div>]]></description>
		
		<pubDate>Sat, 22 Oct 2011 21:26:58 GMT</pubDate>
		<author>snevsky</author>
		<category>MySQL</category><category>information_schema</category><category>MySQL partitions</category><category>MySQL performance</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[MySQL / Стратегия оптимизации веб-проекта с использованием MySQL]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/130905/</guid>
		<link>http://habrahabr.ru/blogs/mysql/130905/</link>			
		<description><![CDATA[<h4>Введение</h4><br/>
В жизни любого крупного веб-проекта, особенно на PHP, но, в целом, это касается любого серверного ЯП, пригодного для веб-разработки, обычно наступает понимание, что «так дальше жить нельзя», и что настал момент, когда нужно провести оптимизацию работы сайта, чтобы он перестал тормозить (хотя бы на production).<br/>
<br/>
Интересно, что, как правило, даже тяжелые фреймворки (вроде Symfony или RoR) на «медленных» языках, в production-окружении работают достаточно сносно по скорости, а основные «тормоза» вызываются SQL-запросами и неграмотным кешированием (к примеру, инициализация достаточно сложной и большой конфигурации проекта на Symfony занимает около 80 мс, а времена исполнения страницы, при этом, иногда достигают секунды и более).<br/>
<br/>
Если вы смогли определить, что это — ваш случай, и ваш проект на MySQL, то эта статья может вам помочь принять конкретные меры и исправлению ситуации с закреплением результата и предотвращением возникновения откровенных проблем с СУБД впоследствии.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/130905/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Fri, 21 Oct 2011 10:46:41 GMT</pubDate>
		<author>youROCK</author>
		<category>mysql</category><category>php</category><category>выявление узких мест</category><category>performance</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[MySQL / HeidiSQL — клиент к mysql/mssql серверам]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/126950/</guid>
		<link>http://habrahabr.ru/blogs/mysql/126950/</link>			
		<description><![CDATA[<a href="http://www.heidisql.com/"><img src="http://www.heidisql.com/images/heidisql_logo.png" alt="image" align="right"/></a>Приветствую. <br/>
Когда перед мной встал вопрос о переходе с phpmyadmin на любой другой клиент, поддерживающий ssh туннели, я перепробовал много что. Остановился на sqlyog`е. Помимо более менее понятного интерфейса, он умел синхронизировать структуры баз данных. И в общем мирился со всеми его странностями и неудобствами. Однако столкнувшись с тем, что для timestamp полей он ставит по дефолту не «DEFAULT CURRENT_TIMESTAMP», а «DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP» и при этом постоянно врёт, что это просто «DEFAULT CURRENT_TIMESTAMP» (т.е. визуально ON UPDATE нигде не отображает), моё терпение лопнуло. В поисках нового клиента, я открыл для себя гениальное, необычное, удобное и простое решение — <a href="http://www.heidisql.com/">HeidiSQL</a>.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/126950/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Wed, 24 Aug 2011 00:09:13 GMT</pubDate>
		<author>mobilz</author>
		<category>mysql</category><category>mysql client</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[MySQL / MySQL песочница #2]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/126898/</guid>
		<link>http://habrahabr.ru/blogs/mysql/126898/</link>			
		<description><![CDATA[Продолжение. Начало <a href="http://habrahabr.ru/blogs/mysql/126832/">тут</a>.<br/>
<br/>
<b> Множественные песочницы.</b><br/>
Вы можете создавать множественные песочницы командой<br/>
<code>$ make_multiple_sandbox /path/to/tarball</code><br/>
Будут созданы 3 песочницы, одной версии, без репликации.<br/>
 При необходимости, также есть возможность создания множественной (3 шт) пeсочницы с использованием разных версий mysql<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/126898/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Tue, 23 Aug 2011 09:45:43 GMT</pubDate>
		<author>Perkov</author>
		<category>mysql tricks</category>
	</item>
	
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[MySQL / [Из песочницы] MySQL песочница]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/126832/</guid>
		<link>http://habrahabr.ru/blogs/mysql/126832/</link>			
		<description><![CDATA[Периодически( а иногда и достаточно часто) возникает необходимость в тестовых, или иных других целях, поднять пару mysql серверов, а можно и с реплицированием, для откатки или отладки того или иного процесса.<br/>
Автоматизировать самому данное телодвижение зачастую нет смысла, поскольку это не так часто необходимо, как хочется.<br/>
 <div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/126832/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Mon, 22 Aug 2011 13:47:02 GMT</pubDate>
		<author>Perkov</author>
		<category>mysql tricks</category>
	</item>
	
	
	
	
	

		
	<item>		
		<title><![CDATA[MySQL / Читаем (и пишем) MyISAM напрямую]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/126612/</guid>
		<link>http://habrahabr.ru/blogs/mysql/126612/</link>			
		<description><![CDATA[В недрах документации MySQL на <a href="http://dev.mysql.com/">dev.mysql.com/</a> я как-то обнаружил упоминание о том, что в случае, если используется MyISAM, можно получить прирост в скорости чтения из таблицы в 5-7 раз, если читать данные из таблицы самостоятельно. Мне довольно долго хотелось проверить этот факт и вот, наконец, у меня дошли руки до того, чтобы это попробовать. Что из этого вышло, читайте под катом<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/126612/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Thu, 18 Aug 2011 20:27:58 GMT</pubDate>
		<author>youROCK</author>
		<category>mysql</category><category>myisam</category><category>myd</category><category>myisam fixed row format</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[MySQL / Аудит и внешняя аутентификация в MySQL]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/126519/</guid>
		<link>http://habrahabr.ru/blogs/mysql/126519/</link>			
		<description><![CDATA[Сегодня я расскажу как сделать вашу СУБД MySQL ближе к стандартам PCI DSS. Для начала вот что у нас получится:<br/>
Консоль админ пользователя <b>mcshadow</b><br/>
<pre>mcshadow:~$mysql --user=mcshadow --password=mike
mysql&gt; select current_user();
+----------------+
| current_user() |
+----------------+
| mike@localhost |
+----------------+
mcshadow:~$mysql --user=mcshadow --password=root
mysql&gt; select current_user();
+----------------+
| current_user() |
+----------------+
| root@localhost |
+----------------+</pre><br/>
Доступ возможен как с правами рута, так и с правами смертного пользователя mike.<br/>
<hr/><br/>
Консоль смертного пользователя <b>mike</b><br/>
<pre>mike:~$mysql --user=mcshadow --password=mike
ERROR 1698 (28000): Access denied for user 'mcshadow'@'localhost'</pre><br/>
Доступ к БД под администратором невозможен.<br/>
<hr/><br/>
А тем временем в syslog<br/>
<blockquote><sup>mysqld: User:mcshadow TRY access from:localhost with privileges:mike<br/>
mysqld: User:mcshadow <b>SUCCESS</b> access from:localhost with privileges:mike<br/>
mysql: SYSTEM_USER:'mcshadow', MYSQL_USER:'mcshadow', CONNECTION_ID:5, DB_SERVER:'--', DB:'--', COMMAND_RESULT:SUCCESS, QUERY:'select current_user();'<br/>
mysqld: User:mcshadow TRY access from:localhost with privileges:root<br/>
mysqld: User:mcshadow <b>SUCCESS</b> access from:localhost with privileges:root<br/>
mysql: SYSTEM_USER:'mcshadow', MYSQL_USER:'mcshadow', CONNECTION_ID:6, DB_SERVER:'--', DB:'--', COMMAND_RESULT:SUCCESS, QUERY:'select current_user();'<br/>
mysqld: User:mcshadow TRY access from:localhost with privileges:mike<br/>
mysqld: User:mcshadow <b>FAILED</b> access from:localhost with privileges:mike</sup></blockquote><br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/126519/#habracut">Как это работает ...</a> </div>]]></description>
		
		<pubDate>Wed, 17 Aug 2011 15:45:01 GMT</pubDate>
		<author>snevsky</author>
		<category>mysql syslog</category><category>mysql authenticate</category><category>grant proxy</category><category>pluggable authentication</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[MySQL / 8123 байта хватит каждому]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/126375/</guid>
		<link>http://habrahabr.ru/blogs/mysql/126375/</link>			
		<description><![CDATA[Сегодня во время перевода одного сайта с таблиц MyISAM на InnoDB, у последних выяснилась одна интересна особенность. Запрос на изменение движка для двух таблиц возвращал странную ошибку «Got error 139 from storage engine». После поиска информации на эту тему, было выяснено, что данная ошибка возникает тогда, когда какая-либо строка таблицы не вмещается в половину страницы памяти, с которыми работает MySQL. Страницы эти равны 16 Кб, а половина, стало быть, 8 Кб.<br/>
<br/>
Само по себе ограничение довольно странное, но на первый взгляд кажется трудно достижимым, ведь как известно, MySQL хранят текстовые данные в хранилище, отдельном от табличных строк. Оказалось, что это верно только на половину. На самом деле InnoDB хранит в отдельном хранилище только «излишки», к коим он не относит первые 768 байтов каждого текстового поля. Т.е. любой текст будет отъедать от длины строки столько байт, сколько он содержит, но не больше 768. Несложно подсчитать, что максимальное число текстовых полей длиной от 768 байт, которое можно безопасно хранить в одной таблице — 10. И действительно, если <a href="http://pastie.org/2376791">запустить пример</a>, все пройдет гладко. Но стоит увеличить количество полей хотя бы на одно, и мы получим ту же ошибку, что и в начале.<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/126375/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Mon, 15 Aug 2011 20:45:48 GMT</pubDate>
		<author>homm</author>
		<category>mysql</category><category>myisam</category><category>innodb</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[MySQL / Введение в PERFORMANCE_SCHEMA]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/126358/</guid>
		<link>http://habrahabr.ru/blogs/mysql/126358/</link>			
		<description><![CDATA[Много камней было брошено в адрес MySQL, ввиду отсутствия возможности трассировки сессий и снятия <b>stats pack</b> отчетов, показывающих какие именно события нагружают базу данных. Начиная с версии 5.5 MySQL наконец-то озадачился необходимостью решения данной проблемы и выставил прототип, который в будущем, возможно, приведет к созданию аналогичных инструментов в MySQL. Сегодняшний мой рассказ будет о таком мощном (к сожалению пока только для разработчиков MySQL) инструменте как <b>PERFORMANCE_SCHEMA</b>. Итак выставляем <i>performance_schema=ON</i> в конфигурационном файле my.cnf, и приступаем к изучению её ограниченных, но уже крайне интересных возможностей.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/126358/#habracut">У вас есть часок свободного времени? Тогда поехали ...</a> </div>]]></description>
		
		<pubDate>Mon, 15 Aug 2011 14:51:32 GMT</pubDate>
		<author>snevsky</author>
		<category>performance_schema</category><category>performance schema</category><category>innodb atomic</category><category>kernel_mutex</category><category>buf_pool_mutex</category><category>rw_lock_mutex</category><category>btr_search_latch</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[MySQL / Как MySQL оптимизирует ORDER BY, LIMIT и DISTINCT]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/125428/</guid>
		<link>http://habrahabr.ru/blogs/mysql/125428/</link>			
		<description><![CDATA[Есть задачи, которые в рамках реляционных СУБД не имеют универсальных решений и для того чтобы получить хоть какой-то приемлемый результат, приходится придумывать целый набор костылей, который ты потом гордо называешь “Архитектура”. Не так давно мне как раз встретилась именно такая.<br/>
<img src="http://habrastorage.org/storage1/24bf5260/4fde5b0d/5b6d36b9/08844585.png"/><br/>
Предположим, имеется некоторые сущности А и Б, связанные между собой по принципу <b>One-to-Many</b>. Количество экземпляров данных сущностей достаточно велико. При отображении сущностей для пользователя необходимо применить ряд независимых критериев, как для сущности А так и для сущности Б. Причем результатом применения критериев являются множества достаточно большой мощности — порядка нескольких миллионов записей. Критерии фильтрации и принцип сортировки задается пользователем. Как (я бы ещё спросил: Зачем им миллионы записей на одном экране? — но говорят надо) показать все это пользователю за время 0 секунд?<br/>
Решать такие задачи всегда интересно, но их решение сильно зависит от СУБД, под управлением которой крутится твоя база данных. Если у тебя в рукаве козырной туз в виде Oracle, то есть шанс, что эти костыли он подставит сам. Но спустимся на землю — у нас есть только MySQL, так что придется почитать теорию.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/125428/#habracut">Далее ...</a> </div>]]></description>
		
		<pubDate>Mon, 08 Aug 2011 14:22:55 GMT</pubDate>
		<author>snevsky</author>
		<category>order by</category><category>limit</category><category>group by</category><category>distinct</category><category>filesort</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[MySQL / MySQL: оптимизация конструкции between]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/125467/</guid>
		<link>http://habrahabr.ru/blogs/mysql/125467/</link>			
		<description><![CDATA[Оптимизация явно не является коньком MySQL сервера. Цель данной статьи объяснить разработчикам, которые плотно не работают с базами данных и иногда не понимают, по какой причине запрос, который успешно отрабатывает в других СУБД, в MySQL безбожно тормозит, каким образом оптимизируется конструкция between в MySQL.<br/>
MySQL использует rule based оптимизатор. Зачатки cost based оптимизации в нем конечно присутствуют, но не в должной мере, в какой их хотелось бы видеть. По этой причине часто мощности получаемых после применения фильтров множеств вычисляются неверно. Это приводит к ошибкам оптимизатора и выбору неверного плана выполнения. При чем полученные between оптимизации невозможно изменить явным указанием: индексов для выполнения запроса и порядка соединения таблиц.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/125467/#habracut">смотрим далее</a> </div>]]></description>
		
		<pubDate>Tue, 02 Aug 2011 10:27:40 GMT</pubDate>
		<author>snevsky</author>
		<category>mysql</category><category>between</category><category>performance</category><category>cursor</category><category>spatial index</category>
	</item>
	
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[MySQL / [Из песочницы] История восстановления базы MySQL из файлов (InnoDB)]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/mysql/125358/</guid>
		<link>http://habrahabr.ru/blogs/mysql/125358/</link>			
		<description><![CDATA[Как говорит народная мудрость, “админы делятся на две категории: те, которые делают бэкапы, и те, которые уже делают”. В моем случае ответственность за несделанный бэкап упала на разработчика, то есть на меня самого. Данная статья посвящена тому, как найти выход из ситуации, подобной описанной. Надеюсь она будет полезна тем, кто не имея такого опыта, может столкнуться с подобной ситуацией. <div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/mysql/125358/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Mon, 01 Aug 2011 08:15:50 GMT</pubDate>
		<author>dimitrymd</author>
		<category>mysql</category><category>администрирование</category><category>восстановление данных</category>
	</item>
	
	
	
	
	

	

	
	
	
	
	
</channel>
</rss>

