Есть вопрос! — MySQL и все-все-все. Какой клиент вы используете (если вдруг)?

Собственно, подскажите, какими пользуетесь гуи-клиентами для MySQL

У меня в постоянном пользовании два (а гуи так вообще один):
* консольный mysql + великолепный maatkit для всех особенных нужд и очень простых проверок
* работающий в вайне HeidiSQL

Переводы — PostgreSQL vs. MySQL

Оригинал
Традиционно, сравнение PostgreSQL и MySQL с обеих сторон подогревается фанатиками. Это технически сильные, открытые базы данных с большим количеством установок. Однако, на самом деле, редко какая-то из сильных сторон любой из них дает явное преимущество при выборе.

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

Урок, пишем свой движок блога. — Урок 1: Начнем!

Привет!
Решил написать движок блога под свои нужды, так как обычно в сети, кроме заезженного wordpress'a, ничего и нет.

У меня есть своя CMS, но меня, скажем так, попросили описать процесс, и я решил для особо жаждущих написать движок блога с самого нуля.

Урок, пишем свой движок блога. — Урок 2: Обзор папок themes, lang. Детали папки include.

Начнем второй урок. Сразу предупреждаю что буду отвечать только на здоровые комментарии, относящиеся строго к сути статьи, остальные комменты типа "зачем велосипед" будут игнорироваться, давайте не будем захламлять флеймом.

Урок, пишем свой движок блога. — Урок 3: Обзор папки include.

Продолжаем.

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

Ubuntu — Ускоряем InnoDB в десятки раз (во время разработки/тестирования проекта)

Проблематика

При разработке проекта в локальной связке Mysql+PHP часто приходилось пересоздавать структуру базы данных (далее — БД). Под пересозданием я подразумеваю следующее:

1. 
   
2. Удаление всех таблиц в БД (т.к. нормальной реализации удаления всех таблиц из БД да еще и с учетом зависимостей нету, удаление реализовано через пересоздание БД).
   
3. Создание таблиц путем выполнения SQL-файла.
   
4. Наполнение БД при помощи ORM в Kohana.
   

Во время тестирования проекта приходилось сохранять текущее состояние БД, производить тестирование, а затем откатывать до прежнего состояния. На все эти процессы терялось достаточно много времени. Например, указанная выше последовательность операций по пересозданию БД длилась приблизительно 50 секунд. Со временем это стало раздражать и я задался вопросом разогнать Mysql.

Цель

Ускорить работу Mysql во время разработки/тестирования проекта.

Есть вопрос! — Xeon 2 x E5504 vs E3-1230

Сейчас уходим с henzner'овского хостинга с i7 920.
На сервере крутится mysql под 64битной CentOS. В проекте, в основном, много мелких select'ов, сейчас LA около 4.

Я так понимаю, в любом случае, система E3-1230 будет быстрее, чем текущая конфигурация. Поправьте, если не прав.

Как оно в сравнении с системой 2 x E5504? Смущает, что такая конфигурации почти в два раза дороже.

вот спеки Intel® Xeon® Processor E5504

вот спеки Intel® Xeon® Processor E3-1230

Есть проблема! — MySQL: резко возрастает нагрузка на CPU и падает после flush-tables

Помогите пожалуйста советом по проблеме.

Обычная нагрузка на cpu 20-30% us+sy. После восстановления копированием файлов базы со slave сервера(той же версии) началась периодическая проблема.
mysql начинает грузить cpu под 100% вырастает us+sy пропорционально. Растет очередь запросов все тормозит.
Но при mysqladmin flush-tables все нормализуется на несколько часов.

vrusinov — Нужно ли переходить с MyISAM на Innodb?

Оригинал
Автор: Peter, Percona

Перевод: Vladimir Rusinov



Существует значительная часть проектов, которые используют MyISAM и задаются вопросом, стоит ли им перейти на InnoDB, или же лучше продолжить использовать MyISAM?



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

Tips & tricks — Дамп БД mysql по ssh

Проблема: есть сервер БД, где мало свободного места (на дамп не хватит). Нужно сделать дамп БД.

Решение:

1	ssh -T <user>@<host> “mysqldump -u <db_user> -p <other> database | bzip2 -9” | bzip2 -dc > database.dump

Стоит обратить внимание на опцию -T, с которой не будет создаваться псевдотерминал и не испортится бинарный поток.

Кросспост с блога