Создал бд на mysql, сами таблицы с которыми работает скрипт занимают 5 мегабайт, зато файл ibdata1 занимает 1.5 гегабайт и растёт постоянно, я так понимаю там пишутся логи, кто знает как сделать так чтобы этот файл не рос? и что там записывается?

первый из гугл по ibdata
http://www[dot]sql[dot]ru/forum/230338/i[dot][dot][dot]ta1-chto-za-fayl

так что этот файл нельзя удалить или уменьшить чтоли?

удаляй

а почему оно всё время растёт если у меня таблица на 5 метров, какие индексы и данные всех таблиц? там всех данных на пять мегабайт а индексов на 1.5 гигабайт? х)
как такое может быть?

я не dba
могу только предполагать из того скудного что знаю
лучше тебе дождаться мелкого...он хоть и пг но думаю пояснит лучше меня
короче...
глянь количество индексов
пойми что каждый индекс это почти новая копия таблицы только с данными входящими в индекс...+ в мускуле действует btree++ ... это значит что в каждом индексе повторяются данные которые участвуют в индексе + верхние страницы индекса
проверь свою архитектуру на индексы
для проверочки удали все индексы и проверь размер файла
потом верни их и подумай есть ли лишние
новички очень часто индексируют всё направо и налево
индекс помогает в выборке но это несет в себе некие расходы
надо уметь индексировать и понимать как устроены индексы
погугли как устроено дерево индексов... "btree для школьников"

Что могу однозначно процитировать, так это вот тут: https://dev[dot]mysql[dot]com/doc/refman[dot][dot][dot]ystem_tablespace

То есть два момента:
- в этом файле хранятся все таблицы и индексы созданные при выключенном innodb_file_per_table.
- mysql просто не умеет уменьшать этот файл

Насколько знаю, единственный выход - сдампить всё, удалить все innodb объекты, полностью стопнуть базу, удалить ibdata и ib_log, запустить базу и восстановить таблички. Ну или сдампить всё нужное и полностью переинициализировать инстанс.

Как именно он переиспользует свободное место - не знаю.

нуу
а как насчет table optimize
не вакуум но хоть чтото
я точно знаю что ты знаешь
не будь пг шовинистом
хотя в случае мскл это по сути и есть новая бд
не...не смог он
(Добавление)
Мелкий привет)) даже не поправил мну.... я что все правильно сказал?)) ураааа)))

Я намеренно даже выделил never shrinks.
mysql никогда не обрезает этот файл. Не умеет. Перестроение таблицы каким-либо образом переместит данные в другое место внутри этого файла-tablespace или в другой файл при включенном per file, но файл этот уменьшить не может. Вообще. Штука очень древняя.
https://bugs[dot]mysql[dot]com/bug.php?id=1341

Для btree - да, всё верно, индекс хранит копии индексируемых значений. Поэтому индексы занимают место, но и потому по btree можно сделать index only scan. Специфика кластеризованного innodb - во вторичные индексы всегда неявно входит ещё и значение первичного ключа.

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

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