После модификации программного кода и запросов, возникла необходимость изменить конфигурацию индексов в таблице с примерно шестью миллионами записей, а в перспективе -- еще и в одной таблице уже с более чем 33,000,000 записей (статистика посещений большого количества сайтов). Казалось бы, что может быть проще, чем удалить ненужные индексы и создать новые на двухпроцессорной машине с RAID5 и 12GB оперативки? А вот фиг вам, это же опенсорс!
В час ночи тушу web-сервер, чтобы никто не отвлекал mysql от работы и запускаю первый из трех необходимых DROP INDEX. Ближе к двум начинаю понимать, что процесс этот не закончится никогда. В три ночи прерываю процесс, ибо до утра должно все работать, а с учетом уже прошедших двух безрезультатных часов, времени явно недостаточно для удаления остальных индексов и создания новых. Что показывал processlist все это время? Показывал он очень занимательную в контексте выполняемой задачи (напомню, удаление индекса) процедуру: копирование содержимого исходной таблицы во временную. Вот скажите мне, нахрена для удаления индекса создавать копию таблицы?
Начал разбираться и выяснил презабавнейшую вещь. Оказывается, эта поделка использует примерно такой алгоритм удаления индекса:
1. Копируем содержимое исходной таблицы во временную.
2. Создаем для временной таблицы все индексы, которые были в исходной, кроме удаляемого.
3. Замещаем исходную таблицу временной.
Оцените мощь! Для удаления трех индексов, он три раза перельет все шесть миллионов записей и три раза с нуля пересоздаст ненужные индексы. Про реальность этой операции с тридцатитрехмилионной таблицей даже думать смешно. В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи. К счастью, эта операция заняла менее четырех часов для обеих таблиц и к началу рабочего дня все уже летало.
Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
сейчас прибежит сами знаете кто и скажет что ты можешь исправить код как тебе нужно и это огромное преимущество опенсорса.
а атк ты прав, да. хотя без вещей вроде опенсорсных кодеков или линукса в моем маленьком роутере мир был бы совсем другим.
Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Ты — программист?
Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
Не надо сравнивать опенсорс и опенсорс. Есть хорошие продукты, а есть mysql. Так же как хорошие продукты есть в клозед сорс и есть в клозед сорсе какашки.
Здравствуйте, quwy, Вы писали:
Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности, ничего в этом плане не добавляющие. Но постойте ка, оказывается у MySQL есть платные тарифные планы поддержки с SLA! Хочется рулеза — платите за план поддержки 24x7, подскажут или исправят в любое время суток. И можно будет соответственно поддержке все рассказать и про студентов, и про красоту. Они там за деньги работают, все стерпят
Q>Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Я думаю, не найдется человека в здравом уме, который оспорит то, что Оракле превосходит MySql практически по всем статьям... за исключением цены. Тут дело не в опенсорсе.
Здравствуйте, Sheridan, Вы писали:
S>Ты — программист? S>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
То есть ты *всегда*, независимо от СУБД, ни при каких условиях не используешь команду drop index, а будешь создавать новую таблицу и таскать туда записи, даже при том что приличные СУБД (даже упомянуто было какие) делают то что нужно за секунды?
Здравствуйте, Sheridan, Вы писали:
S>Да, и еще. S>Я уже оччень давно говорил — не трогайте мускуль, он воняет. Возьмите постгрес. S>Так нет-же. Трогают.
Здравствуйте, Testator, Вы писали:
T>А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности,
Я правильно понимаю, что все кто выбирает GPL продукты думают не тем местом, каким следует ?
Здравствуйте, IID, Вы писали:
T>>А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности,
IID>Я правильно понимаю, что все кто выбирает GPL продукты думают не тем местом, каким следует ?
Вряд ли энтерпрайзная MySQL удаляет индексы более гуманным образом.
Здравствуйте, quwy, Вы писали: Q>Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Ну так купи Оракл и найми соответствующий персонал. Нищеброд ведь платит дважды, да?
Приветствую, Antikrot, вы писали:
A> То есть ты *всегда*, независимо от СУБД, ни при каких условиях не используешь команду drop index, а будешь создавать новую таблицу и таскать туда записи, даже при том что приличные СУБД (даже упомянуто было какие) делают то что нужно за секунды?
Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей...
Здравствуйте, Sheridan, Вы писали:
A>> То есть ты *всегда*, независимо от СУБД, ни при каких условиях не используешь команду drop index, а будешь создавать новую таблицу и таскать туда записи, даже при том что приличные СУБД (даже упомянуто было какие) делают то что нужно за секунды? S>Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей...
ты два раза повторил слово "только", и еще говоришь другим о крайностях?
кроме того, твои слова о "боевой базе" и "сделать сразу так, как было сделано в итоге" какбе вызывают еле заметные подозрения о том, что ты не отличаешь базу от таблицы. и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2.
Приветствую, Antikrot, вы писали:
A> S>Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей...
A> ты два раза повторил слово "только", и еще говоришь другим о крайностях?
Админу бы такое врядли в голову пришло. А если почитать этот форум, то легко сделать вывод, что только с программистами такое может случиться, ибо "я не админ, мне ентого ниче знать нинада"
A> кроме того, твои слова о "боевой базе" и "сделать сразу так, как было сделано в итоге" какбе вызывают еле заметные подозрения о том, что ты не отличаешь базу от таблицы.
Было бы глупо (а в данном случае и долго) вытаскивать одну таблицу из базы для экспериментов. Намного проще вытащить из бэкапа на резервный сервант копию или вообще скопировать боевую бд и уже там проводить эксперименты. А тем более такие, которые, пусть даже возможно, могут нарушить работу боевого сервака.
A> и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2.
Я бы сделал так: на копии БД на другой машине поэкспериментировал бы с разными способами решения задачи, причем базу бы подрезал на порядок. Прикинул бы время нужное на реформирование боевой БД, написал бы скрипт, вставил бы в крон и пошел бы домой. А потом из дома, за X времени (X==время восстановления из бекапа + еще немного) до момента, когда сервант обязан быть в форме, залез бы по ssh, посмотрел как дела, и если надо — откатился бы.
И ни грамма нервов и времени бы не потратил.
Здравствуйте, Sheridan, Вы писали:
S>... и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
Шеридан, эта фраза.... — это же жесточайший вынос мозга! Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.
Здравствуйте, Sheridan, Вы писали:
S>Ты — программист? S>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
Если говорить о разнице в подходах, то, имхо, всё несколько не так.
Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.
Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe. И, кстати, это принципиально ничем не отличается от того, что сделано в mysql. Ну так получилось, что сделать новую базу оказалось проще, чем таблицу в старой — можно сказать, что просто не повезло.
А первый раз (удалять индекс в большой базе без бекапа) — это было... хм... да, несколько самонадеятельно.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
F>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe.
Что интересно, не обязательно. Как гарантировать то, что данные скопировались в новую базу из старой без потерь?
Здравствуйте, frogkiller, Вы писали:
S>>Ты — программист? S>>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
F>Если говорить о разнице в подходах, то, имхо, всё несколько не так. F>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.
на кой черт? копия и так в бекапе. или вообще ничего не бекапится?
F>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe. И, кстати, это принципиально ничем не отличается от того, что сделано в mysql. Ну так получилось, что сделать новую базу оказалось проще, чем таблицу в старой — можно сказать, что просто не повезло.
это только я не заметил где там в "получилось в итоге" про создание новой *базы*?
В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи.
Q>В три ночи прерываю процесс, ибо до утра должно все работать, а с учетом уже прошедших двух безрезультатных часов, времени явно недостаточно
Q>В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи. К счастью, эта операция заняла менее четырех часов для обеих таблиц
Я, наверное, очень тупой. Но не противоречат ли эти два предложения сами себе?
Здравствуйте, Vamp, Вы писали:
F>>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe. V>Что интересно, не обязательно. Как гарантировать то, что данные скопировались в новую базу из старой без потерь?
Для данных — элементарно — сравнить crc/md5/... Для индексов — чуть сложнее, но наверняка и для них есть какие-то инварианты.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
F>Для данных — элементарно — сравнить crc/md5/... Для индексов — чуть сложнее, но наверняка и для них есть какие-то инварианты.
А что, можно вот так просто посчитать crc таблицы?
Приветствую, andrey.desman, вы писали:
a> S>... и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
a> Шеридан, эта фраза.... — это же жесточайший вынос мозга! Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.
Да, я иногда умею завернуть так, что даже самому потом непонятно что хотел сказать
Здравствуйте, Antikrot, Вы писали:
F>>Если говорить о разнице в подходах, то, имхо, всё несколько не так. F>>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой. A>на кой черт? копия и так в бекапе. или вообще ничего не бекапится?
Бекап — отдельная сущность, создаётся независимо от изменений.
"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция.
F>>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe. И, кстати, это принципиально ничем не отличается от того, что сделано в mysql. Ну так получилось, что сделать новую базу оказалось проще, чем таблицу в старой — можно сказать, что просто не повезло. A>это только я не заметил где там в "получилось в итоге" про создание новой *базы*? A>
A>В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи.
Да, я тут ошибся. Почему-то подумал, что создавалась новая база, а не таблица.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Vamp, Вы писали:
F>>Для данных — элементарно — сравнить crc/md5/... Для индексов — чуть сложнее, но наверняка и для них есть какие-то инварианты. V>А что, можно вот так просто посчитать crc таблицы?
Э... а что — нельзя? Даже как crc от массива байт, полученного простой конкатенацией строк?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Sheridan, Вы писали:
A>> S>Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей... A>> ты два раза повторил слово "только", и еще говоришь другим о крайностях? S>Админу бы такое врядли в голову пришло. А если почитать этот форум, то легко сделать вывод, что только с программистами такое может случиться, ибо "я не админ, мне ентого ниче знать нинада"
я правильно понял, что практически все админы знают как [через жопу] внутри mysql сделано удаление индексов?
A>> кроме того, твои слова о "боевой базе" и "сделать сразу так, как было сделано в итоге" какбе вызывают еле заметные подозрения о том, что ты не отличаешь базу от таблицы. S>Было бы глупо (а в данном случае и долго) вытаскивать одну таблицу из базы для экспериментов. Намного проще вытащить из бэкапа на резервный сервант копию или вообще скопировать боевую бд и уже там проводить эксперименты. А тем более такие, которые, пусть даже возможно, могут нарушить работу боевого сервака.
ну может хоть ты расскажешь где там что вытаскивалось?
A>> и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2. S>Я бы сделал так: на копии БД на другой машине поэкспериментировал бы с разными способами решения задачи
а много тут способов решения задачи?
кроме того, ты тут противоречишь вот этой твоей же фразе:
вместо того чтобы сделать сразу так, как как было сделано в итоге
S>, причем базу бы подрезал на порядок. Прикинул бы время нужное на реформирование боевой БД,
о как. интересно как бы ты прикинул. знаешь сложность алгоритма переиндексации в конкретной СУБД?
S>написал бы скрипт, вставил бы в крон и пошел бы домой. А потом из дома, за X времени (X==время восстановления из бекапа + еще немного) до момента, когда сервант обязан быть в форме, залез бы по ssh, посмотрел как дела, и если надо — откатился бы. S>И ни грамма нервов и времени бы не потратил.
а что не "скопировать базу на другой сервер, удалить там индексы, остановить боевой сервер, скопировать почищенную от индексов базу с рабочего на боевой сервер"?
Здравствуйте, frogkiller, Вы писали:
F>>>Если говорить о разнице в подходах, то, имхо, всё несколько не так. F>>>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой. A>>на кой черт? копия и так в бекапе. или вообще ничего не бекапится? F>Бекап — отдельная сущность, создаётся независимо от изменений. F>"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция.
вообще интересно. с такими mv всё равно надо на время работы с копией останавливать боевую базу, или хотя бы в readonly переводить.
Приветствую, Antikrot, вы писали:
A> я правильно понял, что практически все админы знают как [через жопу] внутри mysql сделано удаление индексов?
Нет. Но все знают что с мускулем надо вести себя осторожно.
A> S>Было бы глупо (а в данном случае и долго) вытаскивать одну таблицу из базы для экспериментов. Намного проще вытащить из бэкапа на резервный сервант копию или вообще скопировать боевую бд и уже там проводить эксперименты. А тем более такие, которые, пусть даже возможно, могут нарушить работу боевого сервака. A> ну может хоть ты расскажешь где там что вытаскивалось?
В том то и дело что нет. Это ты меня хотел обвинить в том что я таблицу от базы не отличу.
A> A>> и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2. A> S>Я бы сделал так: на копии БД на другой машине поэкспериментировал бы с разными способами решения задачи A> а много тут способов решения задачи?
Как минимум два Плюс вариации.
A> кроме того, ты тут противоречишь вот этой твоей же фразе: A>
A> вместо того чтобы сделать сразу так, как как было сделано в итоге
Учись читать смысл а не буквы.
A> S>, причем базу бы подрезал на порядок. Прикинул бы время нужное на реформирование боевой БД, A> о как. интересно как бы ты прикинул. знаешь сложность алгоритма переиндексации в конкретной СУБД?
Ты видел слова "поэкспериментировал бы"? Или читаешь с пятого на десятое?
A> а что не "скопировать базу на другой сервер, удалить там индексы, остановить боевой сервер, скопировать почищенную от индексов базу с рабочего на боевой сервер"?
При наличии последнего бэкапа и выверенном экспериментально методе сие теряет смысл, ибо рубануться все может только при форсмажоре. Плюс быстрее отработает.
Но можно конечно и этот вариант, я не против. Главное тут — предварительно подумать и поэкспериментировать.
Здравствуйте, Antikrot, Вы писали:
F>>"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция. A>вообще интересно. с такими mv всё равно надо на время работы с копией останавливать боевую базу, или хотя бы в readonly переводить.
Не на время работы с копией, а в процессе переключения со старой на новую. От этого практически никуда не деться, разве только какими-то внешними средствами, которые "придержат" все пользовательские запросы на время переключения, а потом отправят их новой базе. Разумеется, "гасить" старую базу желательно уже после подъёма новой. Для пользователей весь процесс может быть практически неотличим от, например, сетевых ретрансмитов.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Sheridan, Вы писали:
A>> я правильно понял, что практически все админы знают как [через жопу] внутри mysql сделано удаление индексов? S>Нет. Но все знают что с мускулем надо вести себя осторожно.
блин, а г#вна то сколько из-за этого мускуля вылили на оракл...
A>> S>Было бы глупо (а в данном случае и долго) вытаскивать одну таблицу из базы для экспериментов. Намного проще вытащить из бэкапа на резервный сервант копию или вообще скопировать боевую бд и уже там проводить эксперименты. А тем более такие, которые, пусть даже возможно, могут нарушить работу боевого сервака. A>> ну может хоть ты расскажешь где там что вытаскивалось? S>В том то и дело что нет. Это ты меня хотел обвинить в том что я таблицу от базы не отличу.
хотел, но не обвинил )) высказал подозрения.
рассмотрим подробнее:
Вариант А ("только программисту могла прийти в голову идея такое вытворять"):
на боевой базе (отключенной от вебсервера):
DROP INDEX
=> 1. копируется содержимое (данные) во временную таблицу
=> 2. во временной создаются индексы \ тот что не нужен
=> 3. основная таблица замещается временной
повторить три раза
Вариант B ("сделать сразу так"):
на боевой базе (отключенной от вебсервера):
1. создается временная таблица и индексы \ те что не нужны
2. переливаются данные
2. замещение таблицы
ну и где разница, кроме тормозов из-за хренового мускуля?
A>> кроме того, ты тут противоречишь вот этой твоей же фразе: A>>
A>> вместо того чтобы сделать сразу так, как как было сделано в итоге
S>Учись читать смысл а не буквы.
учись писать так, чтобы не надо было распространять свой СПГСна других
смысл в том, что нет по сути (но есть по производительности) разницы в методе, который ты назвал эксклюзивным для программистов, и тем, который был сделан в итоге и признан тобой правильным.
A>> S>, причем базу бы подрезал на порядок. Прикинул бы время нужное на реформирование боевой БД, A>> о как. интересно как бы ты прикинул. знаешь сложность алгоритма переиндексации в конкретной СУБД? S>Ты видел слова "поэкспериментировал бы"? Или читаешь с пятого на десятое?
видел. и выразил большое сомнение, что ты (да и не принципиально кто) сможет правильно интерполировать экспериментальные данные с "подрезанной на порядок базы" на полную базу. сколько экспериментов надо, чтобы выявить квадратичную зависимость? а если там меняется что по достижению пороговых значений?
Здравствуйте, quwy, Вы писали:
Q> Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Кстати претензии к компании Oracle. Как Oracle DB, так и MySQL — это сейчас продукты этой компании. Требуйте у них разъяснений почему они делают разные продукты с разными лицензиями, разными ценами и разным набором функционала.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Testator, Вы писали:
T>>А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности,
IID>Я правильно понимаю, что все кто выбирает GPL продукты думают не тем местом, каким следует ?
Судите самостоятельно:
— Продукт очевидно используется в довольно жестком production режиме, где время на поиск и устранение всяких проблем ограничено.
— Время от времени требуется поддержка от производителя, т.к. продукт сложный.
— Для продукта кроме обычной GPL есть доступные планы поддержки, где в соглашении прописан SLA.
Вопрос: а не ССЗБ ли тот кто пользует неподходящий для него вариант лицензии, и жалуется на проблему с продуктом в rsdn, вместо того чтобы купить поддержку и жаловаться непосредственно производителю?
Вопрос №2: чем по-вашему в указанном случае продукт с GPL отличается от продукта с другой лицензией не предусматривающей поддержки с SLA? И что конкретно GPL содержит такого особенного по отношению к внутренним особенностям ПО, что позволяет применять квантор всеобщности с какими-то свойствами к сущности под названием "GPL продукты"?
T>Судите самостоятельно: T>- Продукт очевидно используется в довольно жестком production режиме, где время на поиск и устранение всяких проблем ограничено. T>- Время от времени требуется поддержка от производителя, т.к. продукт сложный. T>- Для продукта кроме обычной GPL есть доступные планы поддержки, где в соглашении прописан SLA.
T>Вопрос: а не ССЗБ ли тот кто пользует неподходящий для него вариант лицензии, и жалуется на проблему с продуктом в rsdn, вместо того чтобы купить поддержку и жаловаться непосредственно производителю?
Я бы поставил вопрос более конструктивно — не разумнее ли нанять приходящего специалиста для таких дел — администратора БД?
Здравствуйте, quwy, Вы писали:
Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Ну видно же по описанию, что у тебя используется MyISAM, который, если кто помнит, транзакции не держал (или до сих не держит). Использовал бы InnoDB (который для больших баз рекомендуется) проблемы бы не было.
Так что в чистом виде ССЗБ...
P.S. На Oracle-то денег хватит? Явно тебе ведь не хватит Express Edition.
P.P.S. Кривых продуктов у того же Oracle хватает, но ты его почему-то не хаешь.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Здравствуйте, quwy, Вы писали:
VV>Не надо сравнивать опенсорс и опенсорс. Есть хорошие продукты, а есть mysql.
MySQL — хороший продукт. Просто имеет границы применимости.
Автор же почему то не стал на MS OLE DB Jet engine (aka Access) делать БД — тем не менее этот engine лежит в основе AD.
Здравствуйте, quwy, Вы писали:
Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.
Здравствуйте, _ABC_, Вы писали:
_AB>Я бы поставил вопрос более конструктивно — не разумнее ли нанять приходящего специалиста для таких дел — администратора БД? :xz:
...который не применяет РСУБД для того, для чего они не предазначены — для временных рядов?
Ну-ну. Админ зачастую ставит просто обновления от разработчика, незабывая бэкапится.
Бэкап базы может идти часами, например на/с всё того же стриммера — всё упирается исключительно в доступные носители и их объем. "Резервный" сервант — это как правило полудохлая (в плане производительности) тачка (к примеру виртуализированная), и равняться на неё смысла не имеет, и ожидать чего-то огромного тоже.
Тестовая "реструктуризация" базы — это хорошо, но всё нужно делать со смыслом и при необходимости. Я такой тест проводил, но упаси боже проверять команды навроде drop index, обычно чистой прикладухи и так сверх головы хватает.
Из моей практике было так — тесты могли занимать около 5 часов, — в то время как то же самое на боевом — ~5-10 минут. При том задачи были в чём-то схожи (drop index был ), но была массовая реструктуризация базы вообще. С таким подходом разумеется ни о каких 5-10 минутах речи быть не могло в принципе, даже если изначально выбрать "правильный" путь.
Q>>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
KDK>Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.
Это, кстати, один самых геморройных моментов мускуля — выбор движка.
Здравствуйте, Mamut, Вы писали:
KDK>>Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.
M>Это, кстати, один самых геморройных моментов мускуля — выбор движка.
Почти как в линуксе — выбор дистрибутива. Интересно, у апача есть ли аналогичная проблема или нет? Мне не попадалась вроде
Здравствуйте, Antikrot, Вы писали:
F>>"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция. A>вообще интересно. с такими mv всё равно надо на время работы с копией останавливать боевую базу, или хотя бы в readonly переводить.
LOCK TABLES WRITE. Или репликация. А еще у них есть прокси, который умеет перенаправлять запросы по разным направлениям.
Здравствуйте, Sharowarsheg, Вы писали:
M>>Это, кстати, один самых геморройных моментов мускуля — выбор движка. S>Почти как в линуксе — выбор дистрибутива. Интересно, у апача есть ли аналогичная проблема или нет? Мне не попадалась вроде
Здравствуйте, Sheridan, Вы писали:
a>> Шеридан, эта фраза.... — это же жесточайший вынос мозга! Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.
S>Да, я иногда умею завернуть так, что даже самому потом непонятно что хотел сказать
Здравствуйте, DOOM, Вы писали:
DOO>MySQL — хороший продукт. Просто имеет границы применимости. DOO>Автор же почему то не стал на MS OLE DB Jet engine (aka Access) делать БД — тем не менее этот engine лежит в основе AD.
Автор почему-то не стал делать — это правда, может просто ему Access не попался на глаза во время придумывания архитектуры.
То, что MySQL хороший продукт — усомнюсь. Ладно бы у них просто не было части функционала — это правда дает границы применимости, так у них же с заявленным функционалом бардак. Впрочем в enterprise мире пользуются и продуктами куда более плохого качества и не жужжат.
VV>То, что MySQL хороший продукт — усомнюсь. Ладно бы у них просто не было части функционала — это правда дает границы применимости, так у них же с заявленным функционалом бардак.
Что не мешает MySQL по распространенности делать любую другую бесплатную СУБД.
VV>Впрочем в enterprise мире пользуются и продуктами куда более плохого качества и не жужжат.
Не только в Enterprise. Можно привести кучу ситуаций, когда "мыши плакали, кололись, но продолжали жевать кактус".
Пока Postgre каких-то внезапных рывков в популярности не делает — значит по суммарному количеству параметров MySQL предпочтительнее.
Здравствуйте, Sheridan, Вы писали:
S>Ты — программист? S>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
Вот ведь жопошники эти программисты. Понакодили тут, еще вытворяют, идеи в головах видите ли. Нет чтоб как люди: прочел ман, поправил конфиг, и все завертелось! Романтика!
Здравствуйте, Anton Batenev, Вы писали:
f>> RO>nginx — наше всё! f>> Он уже научился правильно понимать HTTP-хидеры? AB>Например?
URL-ы с русскими символами, декорированные с помощью % — отказывался понимать, интерпретируя их как есть, — а если передавать их в 8-ми битном виде (а для этого нужно поприседать) — всё было отлично. Ещё какие-то моменты были, всех уже не помню. Дело было года 2 назад, — вот и интересуюсь — может уже исправился?
Здравствуйте, fddima, Вы писали:
f> URL-ы с русскими символами, декорированные с помощью % — отказывался понимать, интерпретируя их как есть, — а если передавать их в 8-ми битном виде (а для этого нужно поприседать) — всё было отлично.
Эм... А можно примерчик, а то мне не совсем понятно, какие проблемы возникают в percent encoding.
f> Ещё какие-то моменты были, всех уже не помню. Дело было года 2 назад, — вот и интересуюсь — может уже исправился?
Он достаточно быстро развивается и обрастает функционалом. Иногда даже кажется, что слишком много на него пытаются навешать.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, fddima, Вы писали:
f>> URL-ы с русскими символами, декорированные с помощью % — отказывался понимать, интерпретируя их как есть, — а если передавать их в 8-ми битном виде (а для этого нужно поприседать) — всё было отлично. AB>Эм... А можно примерчик, а то мне не совсем понятно, какие проблемы возникают в percent encoding.
Эм. Это ж его сейчас ставить надо, пробовать. Грубо говоря — вместо того что-бы отдать файл с именем "ААА.html" — пытался искать файл "%80%80%80.html" (80 — это я к примеру). Увы, думаю концов сейчас уже не найти.
f>> Ещё какие-то моменты были, всех уже не помню. Дело было года 2 назад, — вот и интересуюсь — может уже исправился? AB>Он достаточно быстро развивается и обрастает функционалом. Иногда даже кажется, что слишком много на него пытаются навешать.
Просто не думаю что он хороший пример хорошего софта, хотя, конечно же если учесть его популярность — то да.
M>> Это, кстати, один самых геморройных моментов мускуля — выбор движка.
AB>А разве сегодня есть выбор кроме InnoDB? (MyISAM спокойно почил и используется лишь от "незнания")
Ничего он не почил. До сих пор движок по умолчанию
Здравствуйте, Mamut, Вы писали:
M> AB>А разве сегодня есть выбор кроме InnoDB? (MyISAM спокойно почил и используется лишь от "незнания") M> Ничего он не почил. До сих пор движок по умолчанию
Принцип наименьшего удивления, ИМХО. Я бы тоже не стал менять умолчания, которые были заложены столько лет назад. Ну а для 33 лямов записей даже сомнений быть не должно.
Здравствуйте, fddima, Вы писали:
f> AB>Эм... А можно примерчик, а то мне не совсем понятно, какие проблемы возникают в percent encoding. f> Эм. Это ж его сейчас ставить надо, пробовать. Грубо говоря — вместо того что-бы отдать файл с именем "ААА.html" — пытался искать файл "%80%80%80.html" (80 — это я к примеру). Увы, думаю концов сейчас уже не найти.
Сейчас проверил — нормально отдает. Возможно, бага и была, но Игорь достаточно оперативно на них реагирует. Так что можно повторить подход к снаряду
Здравствуйте, Anton Batenev, Вы писали:
AB>Сейчас проверил — нормально отдает. Возможно, бага и была, но Игорь достаточно оперативно на них реагирует. Так что можно повторить подход к снаряду
Ах тааак?!?! Тогда передавай Игорю респегд.
F>Э... а что — нельзя? Даже как crc от массива байт, полученного простой конкатенацией строк?
Нет, ну если ты точно знаешь, что одна таблица однозначно маппируется на один файл — то конечно можно взять CRC от этого файла.
А вот если это не так — а в общем случае это не так — то как тогда?
Здравствуйте, quwy, Вы писали:
Q>После модификации программного кода и запросов, возникла необходимость изменить конфигурацию индексов в таблице с примерно шестью миллионами записей, а в перспективе -- еще и в одной таблице уже с более чем 33,000,000 записей (статистика посещений большого количества сайтов). Казалось бы, что может быть проще, чем удалить ненужные индексы и создать новые на двухпроцессорной машине с RAID5 и 12GB оперативки? А вот фиг вам, это же опенсорс!
Пойду в сторону от основного направления партии и хаянья MySQL.
При некотором опыте в MySQL можно обнаружить, что создание/удаление нескольких индексов в одной таблице делается одной командой и, следовательно, за одно копирование таблиц. Надо просто все операции записать через запятую.
Здравствуйте, vladimir.vladimirovich, Вы писали:
DOO>>MySQL — хороший продукт. Просто имеет границы применимости. DOO>>Автор же почему то не стал на MS OLE DB Jet engine (aka Access) делать БД — тем не менее этот engine лежит в основе AD. VV>Автор почему-то не стал делать — это правда, может просто ему Access не попался на глаза во время придумывания архитектуры.
Автора просто супруга попросила сделать давно работающий продукт (базирующийся на open-source-скриптах, кстати) менее тормозным, с чем он справился хорошо: отклик web-приложения в удаленном браузере с 30-60 секунд сократился до 0-3.
Здравствуйте, Testator, Вы писали:
Q>>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он. T>А вы каким местом думали когда выбирали СУБД и вид лицензии?
Я ничего не выбирал, меня попросили привести в чувства уже готовое, и я взялся. О своих впечатлениях отписал тут. А т.к. я уже много лет занимаюсь разработкой в области СУБД, то меня сильно обескуражило все увиденное. Вот и все.
Здравствуйте, Vamp, Вы писали:
Q>>Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он. V>Я думаю, не найдется человека в здравом уме, который оспорит то, что Оракле превосходит MySql практически по всем статьям... за исключением цены.
Есть шаровой оракл, для данного проекта его, конечно, не хватило бы, но с другой стороны никто сильно и не думал что будут такие масштабы (специфический сервис, который только потом присосался к более востребованному и со временем начал тормозить).
V>Тут дело не в опенсорсе.
В нем тоже, коммерческая БД, авторы которой заявляют, что она "не хуже других", такого себе позволить просто не может. Вон, например, IB/FB вообще не позволяет переименовывать объекты БД, как бы я выкрутился, если бы она тоже индексы через одно место удаляла?
Здравствуйте, Vamp, Вы писали:
Q>>В три ночи прерываю процесс, ибо до утра должно все работать, а с учетом уже прошедших двух безрезультатных часов, времени явно недостаточно Q>>В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи. К счастью, эта операция заняла менее четырех часов для обеих таблиц V>Я, наверное, очень тупой. Но не противоречат ли эти два предложения сами себе?
Нет, не противоречат. Потому что в первом случае кроме копирования, пересоздавались ненужные индексы (весьма тяжелые). Да и не известно еще, через какое место реализовано скрытое копирование.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, quwy, Вы писали:
Q>>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он. DOO>Ну видно же по описанию, что у тебя используется MyISAM
Где это видно? Используется как раз InnoDB.
DOO>P.S. На Oracle-то денег хватит? Явно тебе ведь не хватит Express Edition.
Я -- фактически приглашенный со стороны специалист, спасательный круг. А при выборе БД, руководствовались в основонм ее совместимостью с кучей опенсорсного php-кода. Так что претензии мимо кассы.
DOO>P.P.S. Кривых продуктов у того же Oracle хватает, но ты его почему-то не хаешь.
Штатные управляющие программы? Дал бы в глаз тому гаду, который из написал! Хорошо, что они не обязательны в повседневной работе.
Здравствуйте, xBlackCat, Вы писали:
Q>>После модификации программного кода и запросов, возникла необходимость изменить конфигурацию индексов в таблице с примерно шестью миллионами записей, а в перспективе -- еще и в одной таблице уже с более чем 33,000,000 записей (статистика посещений большого количества сайтов). Казалось бы, что может быть проще, чем удалить ненужные индексы и создать новые на двухпроцессорной машине с RAID5 и 12GB оперативки? А вот фиг вам, это же опенсорс! BC>Пойду в сторону от основного направления партии и хаянья MySQL. BC>При некотором опыте в MySQL можно обнаружить, что создание/удаление нескольких индексов в одной таблице делается одной командой и, следовательно, за одно копирование таблиц. Надо просто все операции записать через запятую.
Может быть, в итоге я это сделал тоже за один проход, но руками. Проблема только в том, что для удаления индекса, копирование таблицы как бы вообще не нужно...
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Sheridan, Вы писали:
S>> Я уже оччень давно говорил — не трогайте мускуль, он воняет.
AB>Да ладно — отлично работает, если его правильно работать.
Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли.
Здравствуйте, DOOM, Вы писали: DOO>P.P.S. Кривых продуктов у того же Oracle хватает, но ты его почему-то не хаешь.
А его же трудно публично хаять. Пусть проблем и багов — вагон и маленькая тележка, зато багтрекер закрыт от любопытных глаз. В споре всегда можно сказать "у меня все работает" и спрятать голову в песок.
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
KDK>>>Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.
M>>Это, кстати, один самых геморройных моментов мускуля — выбор движка.
S>Почти как в линуксе — выбор дистрибутива. Интересно, у апача есть ли аналогичная проблема или нет? Мне не попадалась вроде
мда, есть примерно тожее самое: выбор подходящего MPM (Multi-Processing Module)
Здравствуйте, frogkiller, Вы писали:
F>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.
А вот интересно: перед удалением файла админ сделает копию ФС?
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, frogkiller, Вы писали:
F>>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.
Т>А вот интересно: перед удалением файла админ сделает копию ФС?
Смотря какой файл
Ну а снэпшот сделать рука не отсохнет — а ситуацию может спасти.
Здравствуйте, quwy, Вы писали:
Q>Проблема только в том, что для удаления индекса, копирование таблицы как бы вообще не нужно...
Не очевидно это ни разу. Я конечно многовато лет назад занимался базами данных, но помню что например в MSSQL и Oracle есть такие кластерные индексы, которые влияют на физическое расположение записей в таблице для оптимизации. И при удалении такого индекса тупое копирование таблицы тут может оказаться более дешевой операцией чем сортировка записей по-новому. Возможно для MySQL тоже есть какие-то особенности, из-за которых было сделано именно так как сделано.
Здравствуйте, Testator, Вы писали: T>А что тут смешного?
Ну ошибся я, есть там кластерные индексы, посыпаю голову пеплом. Оправдывает меня только то, что к кластерным индексам mssql они никакого отношения не имеют.
Здравствуйте, Mr.Cat, Вы писали:
MC>Ну ошибся я, есть там кластерные индексы, посыпаю голову пеплом. Оправдывает меня только то, что к кластерным индексам mssql они никакого отношения не имеют.
С кластерным индексам мсскл скорее имеют отношения оракловские index organized tables, не?
Здравствуйте, _d_m_, Вы писали:
_> S>> Я уже оччень давно говорил — не трогайте мускуль, он воняет. _> AB>Да ладно — отлично работает, если его правильно работать. _> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли.
Эту фразу можно применить к любому программному продукту.
Вот только проблема в подавляющем большинстве случаев не в MySQL, а в том, что люди не читают документацию (которая уж явно меньше BOL).
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, _d_m_, Вы писали:
_>> S>> Я уже оччень давно говорил — не трогайте мускуль, он воняет. _>> AB>Да ладно — отлично работает, если его правильно работать. _>> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли.
AB>Эту фразу можно применить к любому программному продукту.
Вот уж нет.
AB>Вот только проблема в подавляющем большинстве случаев не в MySQL, а в том, что люди не читают документацию (которая уж явно меньше BOL).
Люди как бы ожидают адекватного поведения. А тут такой сюрприз — бац! Оказывается элементарный drop index — это охрененно ресурсоемкая операция. И что перед этим надо делать копию ажно всей БД. Ну а чо, для большинства закоренылых MySQL-евцев это нормально. Потому что от этого, с позволения сказать продукта, всего можно ожидать.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Testator, Вы писали: T>>А что тут смешного? MC>Ну ошибся я, есть там кластерные индексы, посыпаю голову пеплом. Оправдывает меня только то, что к кластерным индексам mssql они никакого отношения не имеют.
Еще бы в Oracle не было, сложнее найти чего там нет.
Даже если подходящих индексов нет, сгенерируется искусственный уникальный. А если есть, возьмется либо primary key, либо первый UNIQUE NOT NULL. Пальцем в небо, но похоже это и есть причина проблемы с drop index.
Здравствуйте, lazymf, Вы писали: L>С кластерным индексам мсскл скорее имеют отношения оракловские index organized tables, не?
Ну да, по идее что-то в таком духе.
Приветствую, Vamp, вы писали:
V> S>Достатояно zfs, она сама будет делать. V> А ее в Linux портировали что ли?
Ты хотел сказать "А ее в ядро включили, чтоли?", да?
Здравствуйте, _d_m_, Вы писали:
_> _>> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли. _> AB>Эту фразу можно применить к любому программному продукту. _> Вот уж нет.
Ты готов озвучить безграбельный продукт?
_> Люди как бы ожидают адекватного поведения. А тут такой сюрприз — бац! Оказывается элементарный drop index — это охрененно ресурсоемкая операция.
А не надо чего-то ожидать или гадать на кофейной гуще — достаточно просто почитать документацию и понять как оно там устроено — все достаточно подробно описано и ничего не скрывают.
_> И что перед этим надо делать копию ажно всей БД.
Здравствуйте, frogkiller, Вы писали:
F>Не на время работы с копией, а в процессе переключения со старой на новую. От этого практически никуда не деться, разве только какими-то внешними средствами, которые "придержат" все пользовательские запросы на время переключения, а потом отправят их новой базе. Разумеется, "гасить" старую базу желательно уже после подъёма новой. Для пользователей весь процесс может быть практически неотличим от, например, сетевых ретрансмитов.
Вообще, правильно это делается не так. Изначально надо было делать master-slave репликацию (а если точнее, то master — second master), все изменения (и индексами и не только) проводить на slave (можно хоть неделю играться, лишь бы вместимости логов хватило), затем когда на слейве сделали все, что надо, меняем их местами (то есть мастер становится слейвом) и он затягивает все изменения (опять таки пусть хоть неделю работает). Пользователи вообще ничего не замечают.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, _d_m_, Вы писали:
_>> _>> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли. _>> AB>Эту фразу можно применить к любому программному продукту. _>> Вот уж нет.
AB>Ты готов озвучить безграбельный продукт?
Черное-белое, оттенков не различаешь? Вопрос не в наличии грабель, а в их количестве. В MySQL по доброму так обильно насыпано грабель-фич.
_>> Люди как бы ожидают адекватного поведения. А тут такой сюрприз — бац! Оказывается элементарный drop index — это охрененно ресурсоемкая операция.
AB>А не надо чего-то ожидать или гадать на кофейной гуще — достаточно просто почитать документацию и понять как оно там устроено — все достаточно подробно описано и ничего не скрывают.
Ну тогда можно придумать и свой язык и назвать его, например SQL. Ну и что, что к всем известному языку он не будет иметь никакого отношения. Просто в документации описать. Типа такого "оператор SELECT — удаляет данные из таблицы".
_>> И что перед этим надо делать копию ажно всей БД.
AB>Ну это ты уже сам придумал.
Да нет, вон народ в этом топике на полном серьезе предлагает и обсуждает.
Здравствуйте, _d_m_, Вы писали:
_> AB>Ты готов озвучить безграбельный продукт? _> Черное-белое, оттенков не различаешь? Вопрос не в наличии грабель, а в их количестве. В MySQL по доброму так обильно насыпано грабель-фич.
Опять общие слова...
_> AB>А не надо чего-то ожидать или гадать на кофейной гуще — достаточно просто почитать документацию и понять как оно там устроено — все достаточно подробно описано и ничего не скрывают. _> Ну тогда можно придумать и свой язык и назвать его, например SQL. Ну и что, что к всем известному языку он не будет иметь никакого отношения. Просто в документации описать. Типа такого "оператор SELECT — удаляет данные из таблицы".
Отвечу твоими же словами: "Черное-белое, оттенков не различаешь?"
_> _>> И что перед этим надо делать копию ажно всей БД. _> AB>Ну это ты уже сам придумал. _> Да нет, вон народ в этом топике на полном серьезе предлагает и обсуждает.
Ну так это от незнания. DROP INDEX делается за доли секунды при правильном администрировании.