Ну это может и не дроп быть, а просто транкейт =)косяк админа ж, кто ж кодерам дает доступ с правом на дроп
Порой мораль такую выдадут... смешнее самой истории.Жизненно, мораль: не будь мудаком, сделай отдельный сервер для тестов
dev база 100 Гигов - это проблема. Зачем столько данных в dev базе?реальный диалог, все под стол со смеху попадали
база dev проблемы как таковой нет, просто размер базы 100 гиг, и админу ее восстанавливать
на drop базы пермиссии нет, а на таблицы-то есть
Мое мнение что это не лучший подход, т.к. все равно 1 к 1 нагрузку не с имитируешь, да и затратно мне это кажется по ресурсам держать клон продакшена. Лучше использовать базу гораздо меньшего объема и опираться на данные бенчмарков, если фича с дефектом, то бенчмарк покажет увеличение времени исполнения запросов, экстраполируя эти данные, можно судить о том насколько это плохо отразится на базе в 200 гигов. Но повторю, это только мое мнение.например, быть уверенным что новые фичи работающие со 100 записями, не положат продакшн в 100 гиг
на небольшой базе если таблица полностью постоянно находится в пуле скорость выполнения запроса будет практически идентична (в пределах погрешности измерения) и не будет зависеть от того был это фулскан таблицы или выборка по индексу. Но любой фулскан сразу вылезет на реальных данных >100К записейЛучше использовать базу гораздо меньшего объема и опираться на данные бенчмарков, если фича с дефектом, то бенчмарк покажет увеличение времени исполнения запросов
Но разве нельзя выявить фулскан через EXPLAIN еще на этапе проектирования?на небольшой базе если таблица полностью постоянно находится в пуле скорость выполнения запроса будет практически идентична (в пределах погрешности измерения) и не будет зависеть от того был это фулскан таблицы или выборка по индексу. Но любой фулскан сразу вылезет на реальных данных >100К записей
Конечно можно, но речь то была о другом - о замене реальных данных большого объема, тестовыми данными значительно меньшего объема и о бенчмарках, так бенчмарки на миниданных не помогут.Но разве нельзя выявить фулскан через EXPLAIN еще на этапе проектирования?
Нет, самый тупой пример - создай 3 записи и сделай Explain выборку по индексуНо разве нельзя выявить фулскан через EXPLAIN еще на этапе проектирования?
Я не видел 100Гб базы, поменьше видел, гигов 10, но на вскидку я думаю в той базе есть таблицы по несколько милионов записей, так вот для таких таблиц, мини данные это думаю как раз 50к-100к записей, следовательно если dev сервер слабже по железу prod сервера на порядок и более, и вы пропустили в сложном запросе несколько фулсканов то думаю все же бенчмарки весьма ожидаемо покажут разницу.Конечно можно, но речь то была о другом - о замене реальных данных большого объема, тестовыми данными значительно меньшего объема и о бенчмарках, так бенчмарки на миниданных не помогут.
А вопрос правильного проектирования уже выходит за рамки данного топика
Не совсем понял к чему вы, к тому что MySQL на небольших таблицах предпочитает фул скан вместо индекса?Нет, самый тупой пример - создай 3 записи и сделай Explain выборку по индексу
хм, похоже, ты не в теме, ладно, просто кончай флудить тогдаНе совсем понял к чему вы, к тому что MySQL на небольших таблицах предпочитает фул скан вместо индекса?
Мне просто было интересно почему так, а не иначе. Про зависимости влияющие на построение плана я в курсе.Girakon если ты знаешь что нам делать и хочешь рассказать - присылай резюме, и если ты реально в теме - с удовольствием послушаем конкретные предложения относительно базы и доработки IT-инфраструктуры
хм, похоже, ты не в теме, ладно, просто кончай флудить тогда
да, на разных размерах таблиц базы строят разные планы исполнения запроса