InnoDB в MyISAM

А в чём именно траблы?

У таблиц InnoDB не возникает "накладных расходов" => нет нужды в оптимизации.

ВП вряд ли использует какие-то фишки MyISAM и для него вряд ли есть разница.

А поменять тип таблиц можно с помощью phpMyAdmin или просто SQL-ем

ALTER TABLE `table` ENGINE = MYISAM

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

Да как сказать..

До этого из 5,5 мб получилось 1,1.

Как бэ уже в 5 раз. И ещё можно, но.. не даёт.

SELECT же!

Хм, а вот тут я пас (надо погуглить, но уже завтре ;) ). Это об чём? Как убедится?

Точно InnoDB? И phpMyAdmin это показывает? :)

Таблички InnoDB сами по себе жирнее.

Эээммм... SELECT? а что с ним не так в InnoDB?

В дампе посмотреть, есть ли упоминания об FOREIGN KEY.

Или в phpMyAdmin нажать "Связи" и посмотреть, есть ли они.

---------- Добавлено 07.03.2014 в 03:01 ----------

Вот ещё информация для размышления:

http://dev.mysql.com/doc/refman/5.5/en/optimize-table.html

Абзац "InnoDB Details".

Лично я бы до упора пытался оптимизировать InnoDB, чтобы не откатываться на MyISAM. Всё же движки разного уровня (сравнение "на пальцах" — как Win9x и WinNT).

Конвертация sed -i s/ENGINE=InnoDB/ENGINE=MyISAM/g dbname.sql > dbname.myisam.sql, в принципе, должна сработать, но нужно пробовать на коротком тестовом дампе в конкретной среде, с последующей заливкой и проверкой. Неожиданности случаются.

[umka] выдал более коррректный вариант, лучше менять запросом на самом сервере.

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

#!/bin/sh

DB_NAME="имя_базы";

mysql --user=root -p --execute="USE information_schema; SELECT CONCAT(\"ALTER TABLE \`\", TABLE_SCHEMA,\"\`.\`\", TABLE_NAME, \"\` TYPE = InnoDB;\") as

#delete first line

sed '/MySQLCMD/d' ${DB_NAME}-temp.sql > ${DB_NAME}-innodb.sql;

mysql --user=root -p < ${DB_NAME}-innodb.sql;

rm ${DB_NAME}-temp.sql;

rm ${DB_NAME}-innodb.sql;

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

Никаких, если внутри данных не встречается подстрока "ENGINE=InnoDB" (если блог не посвящен работе с MySQL, то вероятность ее встретить стремится к нулю). Т.е. можно практически смело использовать.

А проблемы какого именно рода?

Разница в производительности на таких нанообъемах лежит в статистической погрешности - практического смысла это почти не имеет.

Скрин не с ПМА, конечно, там чисто :).

Но это показывают как минимум 3 плага (я больше не использовал).

Если бы один - я б забил, но 3! Нет оснований не верить. ПМА тоже ж не панацея и я вполне допускаю, что какие-то его настройки\возможности это не позволяют показывать.

SELECT же на MyISAM значительно быстрее чем на InnoDB.

Эм.. таблица УЖЕ в 5 раз больше чем могла бы быть. И это сайт ещё практически пустой (100 постов всего). Страшно представить что может быть дальше.

:) ну как бэ невозможность оптимизировать :) Ну т.е. в данном контексте - наверное не просто уменьшить объём, а важно удалить мусор\косяки, которые влияют на скорость работы и надёжность получения данных в целом.

Повторю - это только начало. Что будет когда сайт разрастётся (там претензии на нормальный такой портальчик)? Поэтому я и хочу сразу обрубить возможность роста косяков.

Конечно, MyISAM нужно периодически проверять-лечить, но ИМХО это лучше, чем отсутствие такой возможности при всех шансах роста косяков. Ну и опять же - скорость SELECTа..

ИМХО ты не совсем прав. Они просто разные. Как вида и линукс :)

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

Там же, где вы прочитали про SELECT-ы, наверняка написано про кучу преимуществ InnoDB.

И я рекомендовал бы использовать MyISAM только в том случае, когда вы чётко прдставляете, зачем вы это делаете.

Там не прямая зависимость.

Я сейчас ради интереса кнопки понажимал, таблички InnoDB в среднем в 2 раза жирнее MyISAM.

Экономить на размере имеет смысл, если у вас БД конского размера и мало памяти/места.

Я не первый раз сравниваю преимущества\недостатки. И не вижу каких-то особых преимуществ InnoDB, при основном недостатке - скорости селекта (да и др запросах).

Надёжность же InnoDB если и несколько выше, то ИМХО не на столько, что бы жертвовать скоростью (да и объёмами на серверах). Бекапы решают всё :).

Акцентирую внимание: я сейчас (и вообще - во всём топике) говорю не о "вообще" что лучше использовать, а о конкретном применении - при использовании готовых движков, основными используемыми функциями которых является вывод данных из БД.

Если я не прав - с радостью выслушаю аргументы.

ЗЫ. ну как вылечить те 2 таблички в InnoDB - тоже интересно ;)

---------- Добавлено 07.03.2014 в 11:49 ----------

:)

В моей практике попадались ВП-шные базы и по 2 гб.

Точно помню, что БД на 800-900 мб после оптимизации уменьшилась в 16 раз!

Думаю, это стоит того, что бы заморачиваться подобными вопросам :)

У вас ещё всё впереди :D

И всё полезная текстовая информация? :)

Это речь о фрагментации таблиц MyISAM.

Если вес таблицы MyISAM, скажем 100 МБ, то из-за фрагментации она может разрастаться практически бесконечно и тогда "оптимизация" даст хороший результат.

А таблица InnoDB с теми же данными будет занимать 200-220 МБ всегда.

Т.е. не будет разрастаться и "оптимизация" не требуется.

Во всей красе преимущества InnoDB появляются на больших объемах данных (десятки и сотни GB) и при необходимости соблюдать транзакционность и ссылочную целостность.

WordPress все эти навороты не нужны, плюс он умрет от нагрузки гораздо раньше, плюс по умолчанию для него родной движок все же MyISAM (не знаю откуда у вас вдруг взялся InnoDB), плюс over 99% разработчиков не умеют готовить InnoDB (делают что-то типа SELECT COUNT(*) FROM `big_table` и очень удивляются почему так долго по сравнению с MyISAM, после чего делают неверные выводы о производительности).

Другими словами, если нет специфического кода, который требует InnoDB, то я не вижу причин на нем оставаться. Более того, при наличии "кое-какерских" расширений это будет даже вредно для сайта.