|
Задавайте вопросы, мы ответим
Вы не зашли.
Доброго времени суток,
Хотел проконсультировать по следующим вопросам:
1. Как правильно посчитать фактическое выделение памяти под конкретную таблицу (и базу целиком) на движке InnoDB.
Насколько понимаю SHOW TABLE STATUS никакой конкретики по этому поводу не выдает.
Стоит ли в данном случае считать по следующей формуле: v*n+id*n (где v - байты под каждый тип столбца, n - количество строк в таблице, id - байты выделенные под индекс, в InnoDB насколько я понял - 6 байтов?)
2. При увеличении записей в таблицах файлы базы не увеличиваются. Это нормально?
Возможно это происходит до какого-то предела. Так как в таблицах MyISAM файлы базы увеличиваются пропорционально увеличению записей в таблицах.
Заранее благодарен.
Очень надеюсь на Вашу помощь!
Неактивен
На самом деле, как раз в SHOW TABLE STATUS и кроется ответ на Ваш вопрос 
Место, занимаемое таблицей, равно месту, которое занимают данные (Data_length),
индексы (Index_length), и месту, которое резервирует хранилище под расширение
таблицы (оно пишется в комментарии — InnoDB free: xxx kB).
В последних версиях InnoDB plugin комментарий не пишется. Я подозреваю, что
связано это с тем, что сжатые таблички тяжело оценивать по размеру. Впрочем,
никто не мешает просто посмотреть размер файлов в ФС
Неактивен
Спасибо за оперативный ответ.
Но вот, что я читаю по этому поводу: "Команда SHOW TABLE STATUS не выдает точных статистических данных по таблицам InnoDB, за исключением размера физического пространства, зарезервированного для таблицы."
Ключевое слово "зарезервированного", а не фактически используемого.
Мне не совсем понятно, почему объем файлов базы меньше, чем тот объём который предоставляется при SHOW TABLE STATUS. Index_length у меня вообще = 0.
Опять же, с таблицами MyIsam таких сложностей нет. Там и Data_length и Index_length присутствует и всё нормально с этим.
При желании могу позже привести код создания таблиц.
А что насчёт второго пункта. Есть какие-нить соображения?
Неактивен
Размер не растет, пока новые данные влезают в зарезервированную область.
Как только перестанут влезать — InnoDB увеличит размер файла на
innodb_autoextend_increment процентов.
Размеры, разумеется, приблизительные. Точные размеры имеет смысл считать
с помощью du
Неактивен
Как всегда мануал решает.
Не совсем понял, что такое du.
В моем случае нужно использовать innodb_file_per_table, а также для оптимизации производительности изменить
параметр innodb_doublewrite, так как данные я постоянно перезаписываю.
Но насколько я понял, определённая информация всё равно будет храниться в общем таблспейсе.
"InnoDB always needs the shared tablespace because it puts its internal data dictionary and undo logs there. The .ibd files are not sufficient for InnoDB to operate."
И если у меня 2 базы в innodb, я так понимаю, что мне информацию из этого таблспейса будет не достать (имеется в виду, физически занятый объём данных)
Я правильно понимаю?
Неактивен
du — это программа, которая считает занятое место в каталоге.
Да, определенная информация будет храниться в ibdata, а данные будут храниться
в *.ibd.
Что означает «информацию будет не достать»?
Неактивен
Спасибо,
Я имел в виду то, что не знаю, как посчитать распределение физ. памяти для каждой из баз, так как для них используется один общий файл ibdata.
Да и вообще нигде на написано, как оптимизировать лучше. Откуда я знаю, какое минимальное значение объёма задать для ibdata, чтобы он изначально не был слишком сильно раздут.
Неактивен
И ещё вопрос, у меня в папке с базой нет файла my.ini, есть различные другие, скорее всего за основу берётся mysql-innodb-heavy-4G.ini. чтобы включить innodb_file_per_table я должен прописать просто innodb_file_per_table или innodb_file_per_table = 1 (делаю я это в любой области раздела mysqld)?
Неактивен
Можете поиграть с INFORMATION_SCHEMA:
SELECT TABLE_SCHEMA, SUM(DATA_LENGTH) + SUM(INDEX_LENGTH) FROM INFORMATION_SCHEMA.TABLES GROUP BY TABLE_SCHEMA;
Скорее всего — не работает. Можете запустить mysqld --help --verbose, чтобы
увидеть файлы настроек, которые он читает. Добавлять — да, в любое место
в разделе mysqld.
Неактивен
Данные полученные при помощи предложенного вами способа ни чем не отличаются от тех, что получены при получении значений из show table status. В принципе - этого и следовало ожидать, но всё равно спасибо!
Так как при вызове show table status я тоже складываю значения Data_length и Index_length. В моём случае всё равно Index_Length равен нулю, не понимаю почему!
Я запускал mysqld --help --verbose, данные быстро проскакивают и окно закрывается. Как сделать так, чтоб их можно было нормально просмотреть?
И всё таки innodb_file_per_table или innodb_file_per_table = 1?
Неактивен
Даже боюсь себе представить, как Вы запустили приложение, не открыв
консоль. Откройте консоль и попробуйте еще раз.
Не принципиально.
Неактивен
Посмотрел через консоль, так и не смог найти строчку, где указывается файл конфигурации.
Поставил новую версию базы 5.1.53, что самое интересное, там по умолчанию движок innodb стоит.
Там у меня заработало innodb_file_per_table, правда в некоторые таблицы не заносятся значения из скрипта, буду разбираться, что к чему.
Неактивен
Был крайне удивлён, что не поддерживаются значения not null (только, если это не auto increment), база требует от меня default null иначе не хочет помещать значения в таблицу...
Неактивен
Честно говоря, не понял, что Вы хотели сказать 
[celestia] root test > create table notnulldemo (a int not null); Query OK, 0 rows affected (0.54 sec) [celestia] root test > insert into notnulldemo values (NULL); ERROR 1048 (23000): Column 'a' cannot be null
Неактивен
Я скину пояснение чуть позже...появился немного другой вопрос:
можете посоветовать программы для общего тестирования баз дынных DB, MSSQL, MySQL, Oracle (основные критерии: тестирование времени работы и объёмов СУБД).
И вообще, спасибо за помощь!
Неактивен
Смотря что Вы понимаете под тестированием. Если Вы хотите сравнить, какая
БД больше подходит для конкретной задачи, то лучше, чем запустить задачу
на этой БД, теста Вы не найдете. Если хотите протестировать, работают ли они —
все вышеперечисленные работают.
Неактивен
Вопрос о переносимости таблиц путем прямого копирования файлов таблицы.
Итак, доколе известно что таблицы типа MyISAM будут работать если их просто скопировать (*.MYI, *.MYD, *.frm) из одной системы в другую (удаленный сервер FreeBSD, локальный сервер Windows 7).
А как обстоит дело с таблицами типа InnoDB, если я включу innodb_file_per_table, такой трюк будет работать?
Что надо сделать что такой трюк работал?
Предвидя ваш встречный вопрос об использовании встроенные средства / скрипты дампа бд. Это запрещено моей религией.
Отредактированно Джон Симпсон (28.06.2011 11:26:11)
Неактивен
Не будет работать, независимо от религии. Попробуйте, чтобы убедиться, но не на рабочей базе.
Неактивен
Попробовал, не работает.
Теперь вопрос стоит так: как починить все это дело?
Косяк в том что `show tables` показывает что есть таблица X.
Когда же делаю `show columns from `X`, имею /* SQL Error (1146): Table 'X' doesn't exist */
Неактивен
Для начала расскажите, что Вы сделали, чтобы сломать — тогда можно будет
попробовать починить. Если просто скопировали *.frm и *.ibd — работать не
будет. Нужно по крайней мере еще ibdata (и все эти файлы при этом должны
быть взяты на один интервал времени).
Неактивен
(а что такое *.ibd?)
Неактивен
Это такие файлики с расширением ibd 
Появляются, если включить
innodb_file_per_table.
Неактивен
