Быстрый лёгкий надёжный форумный движок
Вы не вошли.
Страницы 1
Попробовал InnoDB, непонравилось то, что данные не в директории базы, а в корне, в постоянно растущем (и не сдувающемся) файле ibdata1. Неудобство очевидно, холодный бэкап усложняется.
Что можете сказать?
Offline
Всё таки главное для базы это не то как она расположена в файлах. InnoDB вроде бы надёжней, поддерживает транзакции и лучше справляется со многими параллельными запросами. Для маленького или среднего форума особой разницы нет. Здесь нет долгих операций.
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Offline
Оно понятно, если повсюду твердят, что InnoDB лучше, хочется использовать именно этот двиг, даже не совсем разбираясь в тонкостях. Так бы я и сделал и даже не стал бы спрашивать (не люблю компромиссы), если бы не это неудобство с файлом...
Возможно, кто-то имеет опыт эксплуатации InnoDB? Как решается проблема с ростом файла? Он растёт во всех случаях, при любых манипуляциях, даже если удалять таблицы. Транзакции, что-ли, копит... В сети полно криков о чудовищных файлах в десятки гигабайт. Я не очень владею ангельским, но в силу своего понимания выяснил в документации, что вроде бы решается кардинально, дампом и пересозданием базы. Но, согласитесь, очень уж коряво (даже крайне неудобно). Хочется, чтобы в дальнейшем не надо было решать проблемы, которые сам себе создал.
Далее, все базы хранятся в одном файле. Тоже очень неудобно. Сейчас у меня почти десяток баз от нескольких сайтов, и бэкап-рестор я делаю в файловом менеджере, что быстро и эргономично. Реально при желании даже автоматизировать процесс с помощью простенького скрипта. Просто не представляю, что будет, если потребуются манипуляции с InnoDB. Дампить? Как это... архаично и неудобно. Где-то писали, что в настройках можно побить файл на несколько, но я в этом не очень смыслю...
Думаю, передал животрепещ(ещ?)ность проблемы. Какие будут предложения?
Offline
А ещё подумал: может посмотреть на PostgreSQL?
Offline
Давно задался вопросом, почему в веб-программировании не принято пользоваться prepare? Ответ нашёлся, как ни странно, в доке.
Оказалось, что для MySQL это не даёт какого-либо выигрыша в производительности, поскольку запросы кэшируются после подстановки параметров. Сильно удивился (большой опыт в Oracle). А в доке PostgreSQL чёрным по белому написано, что использование prepare даёт выигрыш в производительности, потому что запросы кэшируются до подстановки параметров.
Про файлы ничего сказать не могу.
Offline
Вот прикол добавился — ставил старые моды от PunBB, долго парился по поводу ошибки создания дополнительных полей. В конце концов, обнаружил, что просит $db_type и не находит нужный, там только варианты
case 'mysql':
case 'mysqli':
а запрос
echo $db_type;
выдаёт
mysqli_innodb
Offline
Только что дропнул InnoDB базу за 300 Мб, файл не сдулся!
С этим надо что-то делать. Сейчас и впрямь, один выход — делать дамп и пересоздавать БД.
Offline
Нашёл, как сделать разделение базы на таблицы:
innodb_file_per_table
При этом файлы хранятся в папках соответствующей базы. Таблицы между базами таскать нельзя, они привязаны к конкретной базе.
В общем, это меня уже устраивает. Пусть файлы и не сдуваются, то, что они отделены друг от друга, заметно облегчают задачу. Можно задампить конкретную распухшую базу, дропнуть и накатить. Подозреваю, что можно такое проделать и с отдельными таблицами.
Редактировался scalemaster (2010-11-11 23:22:39)
Offline
For InnoDB tables, OPTIMIZE TABLE is mapped to ALTER TABLE, which rebuilds the table to update index statistics and free unused space in the clustered index. Beginning with MySQL 5.1.27, this is displayed in the output of OPTIMIZE TABLE when you run it on an InnoDB table, as shown here:
mysql> OPTIMIZE TABLE foo;
+----------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+----------+----------+----------+-------------------------------------------------------------------+
| test.foo | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.foo | optimize | status | OK |
+----------+----------+----------+-------------------------------------------------------------------+
Это не то?
Offline
Freeman, да. И так (Table does not support optimize, doing recreate) пишет по каждому поводу — проверка, оптимизация...
Offline
Страницы 1