Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: файл ibdata1 растёт в ширину
Покинул форум
Сообщений всего: 280
Дата рег-ции: Апр. 2013
Помог: 0 раз(а)
Создал бд на mysql, сами таблицы с которыми работает скрипт занимают 5 мегабайт, зато файл ibdata1 занимает 1.5 гегабайт и растёт постоянно, я так понимаю там пишутся логи, кто знает как сделать так чтобы этот файл не рос? и что там записывается?
LIME
Отправлено: 01 Февраля, 2019 - 13:44:27
Активный участник
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Покинул форум
Сообщений всего: 280
Дата рег-ции: Апр. 2013
Помог: 0 раз(а)
а почему оно всё время растёт если у меня таблица на 5 метров, какие индексы и данные всех таблиц? там всех данных на пять мегабайт а индексов на 1.5 гигабайт? х)
как такое может быть?
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
я не dba
могу только предполагать из того скудного что знаю
лучше тебе дождаться мелкого...он хоть и пг но думаю пояснит лучше меня
короче...
глянь количество индексов
пойми что каждый индекс это почти новая копия таблицы только с данными входящими в индекс...+ в мускуле действует btree++ ... это значит что в каждом индексе повторяются данные которые участвуют в индексе + верхние страницы индекса
проверь свою архитектуру на индексы
для проверочки удали все индексы и проверь размер файла
потом верни их и подумай есть ли лишние
новички очень часто индексируют всё направо и налево
индекс помогает в выборке но это несет в себе некие расходы
надо уметь индексировать и понимать как устроены индексы
погугли как устроено дерево индексов... "btree для школьников"
Мелкий
Отправлено: 01 Февраля, 2019 - 22:55:13
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
keep all InnoDB tables and indexes inside the system tablespace, often causing this file to become very large. Because the system tablespace never shrinks, storage problems could arise if large amounts of temporary data were loaded and then deleted.
То есть два момента:
- в этом файле хранятся все таблицы и индексы созданные при выключенном innodb_file_per_table.
- mysql просто не умеет уменьшать этот файл
Насколько знаю, единственный выход - сдампить всё, удалить все innodb объекты, полностью стопнуть базу, удалить ibdata и ib_log, запустить базу и восстановить таблички. Ну или сдампить всё нужное и полностью переинициализировать инстанс.
Как именно он переиспользует свободное место - не знаю.
----- PostgreSQL DBA
LIME
Отправлено: 02 Февраля, 2019 - 00:51:59
Активный участник
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
Мелкий пишет:
Насколько знаю, единственный выход
нуу
а как насчет table optimize
не вакуум но хоть чтото
я точно знаю что ты знаешь
не будь пг шовинистом
хотя в случае мскл это по сути и есть новая бд
LIME пишет:
лучше тебе дождаться мелкого...он хоть и пг но думаю пояснит лучше меня
не...не смог он (Добавление) Мелкий привет)) даже не поправил мну.... я что все правильно сказал?)) ураааа)))
Мелкий
Отправлено: 02 Февраля, 2019 - 15:48:28
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
LIME пишет:
а как насчет table optimize
Я намеренно даже выделил never shrinks.
mysql никогда не обрезает этот файл. Не умеет. Перестроение таблицы каким-либо образом переместит данные в другое место внутри этого файла-tablespace или в другой файл при включенном per file, но файл этот уменьшить не может. Вообще. Штука очень древняя. https://bugs[dot]mysql[dot]com/bug.php?id=1341
Для btree - да, всё верно, индекс хранит копии индексируемых значений. Поэтому индексы занимают место, но и потому по btree можно сделать index only scan. Специфика кластеризованного innodb - во вторичные индексы всегда неявно входит ещё и значение первичного ключа.
----- PostgreSQL DBA
LIME
Отправлено: 02 Февраля, 2019 - 16:28:31
Активный участник
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
Мелкий пишет:
во вторичные индексы всегда неявно входит ещё и значение первичного ключа.
перевожу на людской
в ключе иннодиби хранится не ссылка на данные а значение пк(второй поиск)
эдакий симлинк
Мелкий пишет:
mysql никогда не обрезает этот файл. Не умеет.
жееесть...спасибо за инфо...но капееец (Добавление)
Мелкий пишет:
Поэтому индексы занимают место, но и потому по btree можно сделать index only scan.
извините синьор но это уже особенности алгоритма
в любой субд
и приемчики и триксы
но это уже совсем другая история) (Добавление)
для любознательных это называется покрывающий индекс
grafillo
Отправлено: 04 Февраля, 2019 - 10:11:55
Посетитель
Покинул форум
Сообщений всего: 280
Дата рег-ции: Апр. 2013
Помог: 0 раз(а)
кароч если в ручную бахнуть этот файл то потом как его востсановить7
всё должно заработать же?
таблицы то у меня все есть.
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.