Это решение работает для тех таблиц, которые имеют одинаковый префикс, например для таблиц wordpress и других CMS поддерживающих префиксы.

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

1)Получаем список таблиц в файл:

2)Открываем файл outputfile.txt например в vim и делаем следующие замены:

• Префикс меняем на ALTER TABLE prefix_ - для vim: %s/prefix_/ALTER TABLE prefix_/g
• Перенос строки меняем на ENGINE=InnoDB плюс перенос строки - для vim: %s/\n/ ENGINE=InnoDB;\r/g

3)Выполняем скрипт, но прежде делаем бэкап базы:

Может кто нибудь подскажет как сделать то же самое для таблиц без одинакового префикса?

© Yaroslav Vorozhko for Просто про веб технологии, 2009. | Permalink | 3 comments | Add to del.icio.us
Post tags:

© Yaroslav Vorozhko for Просто про веб технологии, 2009. | Permalink | 2 comments | Add to del.icio.us
Post tags:

Первый и самый простой это использовать функцию listTables из Zend_db, но у этой функции есть ограничение, она получает список таблиц только текущей базы данных.

Например вам надо узнать существует ли таблица my_table в подключении к текущей базе данных:

$db = $this->getAdapter();

$tables = $db->listTables();

if (in_array('my_table', $table)){

//todo something with table

}

listTables() возвращает массив имен всех таблиц в текущей базе данных.

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

Пример:

$db = $this->getAdapter();

$sql = "show tables from any_db like 'my_table' ";

if ( $db->fetchOne($sql) ){

//todo something with table

}

fetchOne() вернет строку с именем таблицы, если таблица будет найдена, если ничего не будет найдено, то будет возвращена пустая строка.

С помощью приема с show tables можно проверять на существование одной и более таблиц, что делает этот прием более универсальным.

© Yaroslav Vorozhko for Просто про веб технологии, 2009. | Permalink | No comment | Add to del.icio.us
Post tags: MySQL, ZendFramework

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

Percona XtraDB включает всю InnoDB ACID-совместимую архитектуру и расширенную MVCC архитектуру, добавлены новые возможности, более тюнингована, более информативна, более масштабируема на мульти-процессорных системах, и с улучшенной системой использования оперативной памяти.

Что нового в этом движке? Вот список улучшений:

• INFORMATION_SCHEMA.XTRADB_ENHANCEMENTS. Эта таблица содержит информацию про различия XtraDb и той же версии InnoDb.
• Улучшения в SHOW INNODB STATUS.
• Улучшения в InnoDB IO.
• InnoDB RW-lock fixes. Улучшена масштабируемость для систем с 8+ ядер.
• Buffer pool fixes
• innodb_buffer_pool_pages

В общем это сейчас тунингованый InnoDB, только OpenSource. Для комьюнити публичный OpenSource считаю большим плюсом.

Percona сделала и продолжает делать отличную работу по развитию и поддержке MySQL.

Думаю Percona это новая MySQL и уже в скором будущем мы не раз в этом убедимся. :)

Оффициальный анонс XtraDB

Тесты производительность ввода вывода XtraDB

Тесты производительности и нагрузки CPU XtraDb

Документация по XtraDB http://www.percona.com/docs/wiki/percona-xtradb:start

Исходные коды на XtraDB https://launchpad.net/percona-xtradb

Обсуждения XtraDB и остальных разработок Perocona http://groups.google.com/group/percona-dev

© Yaroslav Vorozhko for Просто про веб технологии, 2008. | Permalink | One comment | Add to del.icio.us
Post tags: MySQL, OpenSource, Percona, Performance, XtraDB

Недавно в списке MySQL internals@list появился анонс, про выпуск нового storage engine. Компания DDengine создала новый движок revision engine, набор встроенных прокси внутри MySQL, которые следят за изменениями данных в вашей базе.

Идея отличная. Вы пишите в свою таблицу, обновляете и удаляете данные, не беспокоясь ни о чем, в то время как revision engine будет сохранять все ваши изменения работая за сценой.

На данный момент revision engine хорошо работает под Linux. Под другие системы пока, что есть проблемы, но это и понятно, так как версия пока еще 0.1.

В документации говорится, что существует два пути использования revision engine. Первый с встроенным хранением, которые тихо изменит структуру таблицы и добавит revision информацию в нее, и второй метод использует две таблицы, одна из которых создается за сценой.

Например:

create table t1 (
 id int not null primary key,
 c char(10)
) engine=revision comment="InnoDB:DOUBLE";
show tables;
+----------------+
| Tables_in_test |
+----------------+
| t1             |
| t1_revision    |
+----------------+
desc t1;
+-------+----------+------+-----+---------+-------+
| Field | Type     | Null | Key | Default | Extra |
+-------+----------+------+-----+---------+-------+
| id    | int(11)  | NO   | PRI | NULL    |       |
| c     | char(10) | YES  |     | NULL    |       |
+-------+----------+------+-----+---------+-------+

desc t1_revision;
+--------------------+---------------------+------+-----+
| Field              | Type                | Null | Key |
+--------------------+---------------------+------+-----+
| id                 | int(11)             | NO   | PRI | 
| c                  | char(10)            | YES  |     |
| revision_id        | int(10) unsigned    | NO   | PRI |
| revision_timestamp | timestamp           | NO   |     | 
| revision_deleted   | tinyint(3) unsigned | NO   |     |
+--------------------+---------------------+------+-----+

Ключевое слово "InnoDB:DOUBLE" говорит engine, что надо использовать метод двух таблиц для хранения revision info, в данном случае t1_revision создается автоматически.

Операции над таблицами прозрачны.

insert into t1 (id,c) values (1, 'aaa'), (2, 'bbb');
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0

insert into t1 (id, c) values (3, 'ccc'), (4, 'ddd');
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0

select * from t1;
+----+------+
| id | c    |
+----+------+
|  1 | aaa  |
|  2 | bbb  |
|  3 | ccc  |
|  4 | ddd  |
+----+------+
4 rows in set (0.00 sec)

select * from t1_revision;
Empty set (0.00 sec)

Ничего необычного. Давайте попробуем, что нибудь поменять.

update t1 set c ='changed' where id = 3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

select * from t1;
+----+---------+
| id | c       |
+----+---------+
|  1 | aaa     |
|  2 | bbb     |
|  3 | changed |
|  4 | ddd     |
+----+---------+
4 rows in set (0.00 sec)

show variables like '%revision%';
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| revision_select_mode | current |
+----------------------+---------+
1 row in set (0.00 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  3 | ccc  |           1 | 2008-09-30 05:45:49 |                0 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

delete from t1 where id = 2;
Query OK, 1 row affected (0.01 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  3 | ccc  |           1 | 2008-09-30 05:45:49 |                0 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

set revision_select_mode = 'deleted';
Query OK, 0 rows affected (0.01 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  2 | bbb  |           1 | 2008-09-30 05:47:14 |                1 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

select * from t1;
+----+---------+
| id | c       |
+----+---------+
|  1 | aaa     |
|  3 | changed |
|  4 | ddd     |
+----+---------+
3 rows in set (0.00 sec)

Переменная сессии revision_select_mode , переключает режим отображения данных в revision engine.

На данный момент, механизма отката изменений нет (или есть, но не документирован), но идея отличная, и я думаю этот engine будет очень полезен в будущем.

Перевод не оригинальный, текст немного видоизменен, без потери смысла статьи передаваемого Автором текста.

© Yaroslav Vorozhko for Просто про веб технологии, 2008. | Permalink | No comment | Add to del.icio.us
Post tags: MySQL, revision engine, контроль версий

Для MySQL, фиксированный формат легче в доступе, кешировании и обновлении информации. Также этот формат менее подвержен порче данных. Если дисковое пространство не является критическим, то фиксированный формат будет хорошим выбором.

Динамический формат использует меньше дискового пространства, но более подвержен риску фрагментации и/или порче данных.

Но давайте сначала посмотрим, на тесты и потом сделаем окончательное заключение.

(...)
Read the rest of MySQL Row Format Tuning (291 words)

© Yaroslav Vorozhko for Просто про веб технологии, 2008. | Permalink | One comment | Add to del.icio.us
Post tags: blob, char, MySQL, row format, text, tuning, varchar, динамический формат, кеширование, обновление, производительность, скорость

Привет,

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

(...)
Read the rest of Zend_DB Out of memory bug (212 words)

© Yaroslav Vorozhko for Просто про веб технологии, 2008. | Permalink | 2 comments | Add to del.icio.us
Post tags: bug, eventum, fetch, fetchall, find, findby, findParentRow, longtext, mediumtext, out of memory, PHP, zend, zend db