Comments 43
а если на время изменения поля дропнуть индекс? потом его восстановить, или бред?
145 миллионов записей? БД граждан России? :)
а в уникальном ключе код днк :D
Полторы сотни — это не предел. У меня в ежедневной работе несколько таблиц от пары сотен миллионов до миллиарда записей.
Говорят у физиков-ядерщиков после экспериментов данные некуда складывать. Метеорологи уже без суперкомпьютеров не могут. А ведь раньше всю их погоду предсказывал сосед-радикулитик :)
Говорят у физиков-ядерщиков после экспериментов данные некуда складывать. Метеорологи уже без суперкомпьютеров не могут. А ведь раньше всю их погоду предсказывал сосед-радикулитик :)
а я бы как лох в цикле по 10000-100000 записей бы переносил. спасибо!
По-моему, у автора топиков подозрительная любовь к уникальным индексам по VARCHAR'а длиной в полтораста знаков. Не спроста это, попомните мое слово! :-)
2lexxscorp: Все ждут третьего топика, где вы все-таки триумфально объявите, зачем вам такие индексы! :-)
2lexxscorp: Все ждут третьего топика, где вы все-таки триумфально объявите, зачем вам такие индексы! :-)
Да бог с ними, с индексами (хотя мне тоже интересно)… А вот то, что человек в течение одной недели второй раз меняет структуру таблицы с 145 МегаЗаписями, немного странно :)
у меня тоже такой вопрос вознк, зачем такой индекс и почему бы не сделать CHAR и сделать ROW_FORMAT FIXED
Хотя я предполагаю что в этом поле может храниться имя файла.
Хотя я предполагаю что в этом поле может храниться имя файла.
В обеих статья одна и таже таблица. Просто с прошлого раза она ужалась с 15 до 12 гигов.
Тогда возникает уже заданный ваше вопрос — зачем эту несчастную таблицу так часто ковырять? :-)
Нет, серьезно, скиньте задачу. Я думаю, Хабр с удовольствием поделится советами по организации базы… Просто я честно не могу придумать задачу, требующую такого индекса, которую нельзя оптимизировать и реализовать иначе…
Нет, серьезно, скиньте задачу. Я думаю, Хабр с удовольствием поделится советами по организации базы… Просто я честно не могу придумать задачу, требующую такого индекса, которую нельзя оптимизировать и реализовать иначе…
А для InnoDB такое сработает?
Перетаскиваете потихоньку сюда свежак из блога Пети Зайцева? :-)
www.mysqlperformanceblog.com/2007/10/29/hacking-to-make-alter-table-online-for-certain-changes/
www.mysqlperformanceblog.com/2007/10/29/hacking-to-make-alter-table-online-for-certain-changes/
А если сделать ALTER TABLE ADD COLUMN — тоже будет временная таблица?
На мотив Pinky and the Brain:
Pinky: «Gee, Brain, what do you want to do tonight?»
The Brain: «The same thing we do every night, Pinky — try totake over the world! change the table structure!»
:-)
Pinky: «Gee, Brain, what do you want to do tonight?»
The Brain: «The same thing we do every night, Pinky — try to
:-)
на практике человек застремается без бэкапа заменять какие-то файлы в /var/lib/mysql — там же пипец ценные данные! поэтому к затрачиваемому времени добавьте время на изготовление дампа базы, так что выигрыш невелик.
зачем вы используете уникальный ключ на 160 символов?
А что вы предложите взамен? Задача — гарантировать уникальность строкового поля.
1. перейти на CHAR с меньшей длиной не могу, придётся пожертвовать частью данных; а если задать CHAR (160), то сильно вырастет объём данных.
2. можно конечно использовать 16-байтовый хеш типа MD5, который хранить в 2-х BIGINT'ах.
3. можно разбить таблицу горизонтально на несколько других.
Какие есть ещё идеи?
1. перейти на CHAR с меньшей длиной не могу, придётся пожертвовать частью данных; а если задать CHAR (160), то сильно вырастет объём данных.
2. можно конечно использовать 16-байтовый хеш типа MD5, который хранить в 2-х BIGINT'ах.
3. можно разбить таблицу горизонтально на несколько других.
Какие есть ещё идеи?
145 миллионов записей на таблице MyISAM?
Похоже, у вас тяжёлое наследие.
Похоже, у вас тяжёлое наследие.
второй пост уже всех интригуете своей странной таблицей
может уже пора шардить, или InnoDb+partitioning
может уже пора шардить, или InnoDb+partitioning
Only those users with full accounts are able to leave comments. Log in, please.
Большие таблицы и ENUM