Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 62
Милота какая :3
Приколист. :)
Хотя формально, по-моему, это не баг.
Хотя формально, по-моему, это не баг.
AUTO_INCREMENT=xxx относится к метаданным таблицы, а не к данным. Думаю, ему надо было завести не баг-репорт, а фиче-реквест о добавление ключа --no-autoincrement-value и давно бы была решена проблема.
Что бы проблема «давно была бы решена» лучше тогда уж предложить патч, а не фича-реквест делать.
Согласен, что скорее нужно писать фичереквест :) Я в Sypex Dumper добавил опцию для сброса автоинкремента именно после просьб юзеров.
с одной стороны да, а с другой — снятие двух дампов, один с no-data, а другой с no-create-info, по идее должны дать полноценный дамп, которые при последовательной заливке должны привести к оригинальному состоянию. А при существующем поведении эти два дампа залитые последовательно приведут к сдвигу на это самое auto-increment значение.
Так что как по мне — это скорее баг. А вот для тех, кому нужно наличие autoincrement value в no-data дампе можно делать фичу.
Так что как по мне — это скорее баг. А вот для тех, кому нужно наличие autoincrement value в no-data дампе можно делать фичу.
Вы правда думаете, что если бы инженеры MySQL посчитали, что это feature request — никто бы тип бага не поменял?
Формулировка не та, чтобы считать это фичереквестом.
А что тогда советуете? Какая разница какая формулировка? Баги открывают люди из разных стран с разным уровнем английского языка. Если только по формулировкам судить, то можно прийти к тому, чтобы работать исключительно над багами, открытыми исключительно филологами.
База данных MySQL — открытая, поиск в ней работает. Зайдите и посмотрите сколько багов было за это время, сколько исправлено, сколько просто Verified и сравните процентное отношение с feature request-ами.
База данных MySQL — открытая, поиск в ней работает. Зайдите и посмотрите сколько багов было за это время, сколько исправлено, сколько просто Verified и сравните процентное отношение с feature request-ами.
Не нужно быть филологом чтобы почувствовать разницу между «уберите вывод AUTOINCREMENT» и «добавьте возможность отключать вывод AUTOINCREMENT». Первое деструктивно, второе конструктивно.
Да причём здесь это вообще! Вы правда считаете, что инженеры MySQL не могут две минуты подумать как баг пофиксить лучшим образом? Мой личный комментарий хотя бы прочитайте:
Он был сделан до того, как я этот топик увидела.
И такое происходит с каждым первым багом. Пользователи не обязаны думать за разработчиков какое решение лучше или какое нет.
Нет, конечно, если формулировка совсем плохая, инженер может просто не понять что хочет пользователь. И такие случаи бывали. Как правило мы всё равно отвечаем почему bug rejected и большинство пользователей объясняют уже подробно. После чего решение о закрытии бага пересматривается.
[28 Jun 19:54] Sveta Smirnova
…
Although now, in year 2013, I don't like that this will break backward compatibility for --no-data option: I assume some of users like current behavior. Probably official patch should have separate option for resetting current AUTO_INCREMENT value.
Он был сделан до того, как я этот топик увидела.
И такое происходит с каждым первым багом. Пользователи не обязаны думать за разработчиков какое решение лучше или какое нет.
Нет, конечно, если формулировка совсем плохая, инженер может просто не понять что хочет пользователь. И такие случаи бывали. Как правило мы всё равно отвечаем почему bug rejected и большинство пользователей объясняют уже подробно. После чего решение о закрытии бага пересматривается.
Судя по смеху в конце, это достаточно опытный разработчик. Своеобразная профессиональная деформация. У нас так тимлид начал смеяться когда послал волею судеб 8000 SMS директору конторы-заказчика и ещё нескольким до этого случая неизвестным ему людям. И вообще слово «смех» в данном случае не совсем верно по смыслу. Аналогичные звуки издают самцы некоторых обезьян, которые опасаются что волею судеб их поймают другие и самцы случайно перепутают их с самками. (Несколько раз)
А дальше было не так?
The cake is a lie :)
Так это и не баг, так как AUTO_INCREMENT добавляет не mysqldump, а сам mysql. Так что нужно добавлять какую-то опцию для mysqldump, чтобы он этот AUTO_INCREMENT удалял.
Ну, понятно, что это не сложно, просто это лишние телодвижения :)
убрать ненужные строки из дампа базы
скриптом на баше
Никогда, никогда не парисите башем дампы баз! Никогда!
А что с MariaDB? Там пофиксили этот баг или он ещё тоже висит?
Я конечно хз как там внутре сделано, но в последних версиях myphpadmin при экспорте есть галочка, указывать ли в дампе auto_increment.
innodb table last update time 27 октября 8 лет исполняется.
Подарю себе в этот день сервер с Percona, и обещание начать забывать mysql.
Ладно бы фигня какая, но такое я уже прощать дальше не в состоянии. Ни в моральном ни в архитектурном.
Подарю себе в этот день сервер с Percona, и обещание начать забывать mysql.
Ладно бы фигня какая, но такое я уже прощать дальше не в состоянии. Ни в моральном ни в архитектурном.
Ээээ, это sarcastic mode? Можно же в табличку добавить поле TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP и будет таже функциональность. Просто если во всех табличках такое поле внутренне мэйнтейнить, имхо, на производительности скажется.
шчто?
Нет, это не саркэстик мод.
А вы еще предложите мне отдельную табличку создать, куда непрозрачно писать все ластапдейты, дополнительным скрытым вызовом на каждый чих. Ну, или там демоном файлики БД мониторить.
Нет, это не саркэстик мод.
А вы еще предложите мне отдельную табличку создать, куда непрозрачно писать все ластапдейты, дополнительным скрытым вызовом на каждый чих. Ну, или там демоном файлики БД мониторить.
> А вы еще предложите мне отдельную табличку создать, куда непрозрачно писать все ластапдейты, дополнительным скрытым вызовом на каждый чих.
Вообще этот баг предлагает такое сделать всем пользователям, независимо от того надо им или нет. Если я правильно поняла комментарий Heikki, то это приведёт к потере производительности для всех польлзователей.
Вообще хорошо, что сейчас появилась кнопка «Affects Me»: я бы лично никогда не подумала, что это реально серьёзный баг для многих. Серьёзнее неправильного поведения или crash.
> Ну, или там демоном файлики БД мониторить.
В случае InnoDB это не поможет. Точнее поможет, если у вас опция innodb_file_per_table, но всё равно погрешность в несколько миллисекунд будет.
Вообще этот баг предлагает такое сделать всем пользователям, независимо от того надо им или нет. Если я правильно поняла комментарий Heikki, то это приведёт к потере производительности для всех польлзователей.
Вообще хорошо, что сейчас появилась кнопка «Affects Me»: я бы лично никогда не подумала, что это реально серьёзный баг для многих. Серьёзнее неправильного поведения или crash.
> Ну, или там демоном файлики БД мониторить.
В случае InnoDB это не поможет. Точнее поможет, если у вас опция innodb_file_per_table, но всё равно погрешность в несколько миллисекунд будет.
Вы не подскажете ещё зачем это нужно для всех таблиц? Я могу придумать только две причины:
1. Отладка.
2. Инкрементный бэкап. Но для бэкапа хранится LSN и его прекрасно используют MySQL Enterprise Backup и Percona XtraBackup
А вот в плане бизнес-логики обычного приложения мне кажется, что поле TIMESTAMP гораздо удобнее. Потому что, если поменялась таблица, скажем, с ценами, мне будет интересно узнать какая именно цена изменилась, а не сам факт того, что что-то поменялось.
1. Отладка.
2. Инкрементный бэкап. Но для бэкапа хранится LSN и его прекрасно используют MySQL Enterprise Backup и Percona XtraBackup
А вот в плане бизнес-логики обычного приложения мне кажется, что поле TIMESTAMP гораздо удобнее. Потому что, если поменялась таблица, скажем, с ценами, мне будет интересно узнать какая именно цена изменилась, а не сам факт того, что что-то поменялось.
Да, вы все верно написали.
Еще можно триггер повесить. Можно перехватывать обращения к сокету наверное и еще кучу вещей… Но это всеравно, что топором гвозди забивать. Вроде и забиваются, но ведь не для того он… Да и полбу можно получить.
Мне же нужно сам факт случившегося апдейта. Точное время. Одним быстрым и правильным запросом.
Еще можно триггер повесить. Можно перехватывать обращения к сокету наверное и еще кучу вещей… Но это всеравно, что топором гвозди забивать. Вроде и забиваются, но ведь не для того он… Да и полбу можно получить.
Мне же нужно сам факт случившегося апдейта. Точное время. Одним быстрым и правильным запросом.
Не поняла зачем триггер вешать? Одно поле, автоматически обновляющееся, не должно затронуть правильно спроектированное приложение вообще. То есть, таблица
, переписанная во что-то вроде:
позволит, не меняя правильно написанные запросы, получить точно сам факт свершившегося апдейта. Одним запросом.
Но Вы мне так и не ответили зачем Вам это нужно для всех таблиц.
CREATE TABLE t1(
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
f1 INT,
f2 VARCHAR(255)
....
, переписанная во что-то вроде:
CREATE TABLE t1(
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
last_updated TIMESTAMP NOT NULL,
f1 INT,
f2 VARCHAR(255)
....
позволит, не меняя правильно написанные запросы, получить точно сам факт свершившегося апдейта. Одним запросом.
Но Вы мне так и не ответили зачем Вам это нужно для всех таблиц.
Вот здесь я вас поддержу — зачем?!
last_updated TIMESTAMP NOT NULL,
Вы это и правда серьезно?
Вы вот прям серьезно предлагаете, там где нужен ластапдейт неважно каких данных, вмешиваться в структуру, да еще и цеплять это поле каждой записи?
Вы с таблицами больше 10 млн записей работали?
Insert и update в InnoDB? оптимизация запросов? компактное расположение полей, помочь встроенному оптимизатору?
Борешься, блин, за каждый лишний байт в длине полей, количестве и качестве индексов…
Лучше будем mysql оправдывать.
И я не говорил про
всетаблицы. Где вы это увидели?
Пишите какие хотите костыли, а я с этого недоразумения точно ухожу.
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY
зачем здесь примари кей id с инкрементом?
зачем его вообще бездумно везде лепят?
last_updated TIMESTAMP NOT NULL
т.е. получить самый последний апдейт надо так:
SELECT max(`last_updated`) FROM `t1`
, а `t1` count(*) > 10,000,000
неужели не очевидно, что это большой косяк, отсутствие нативного last_update?
замечательно! Percona + xtradb тоже не имеет last_update...(((
> зачем здесь примари кей id с инкрементом?
> зачем его вообще бездумно везде лепят?
Хорошо, поторопилась. В данном случае, конечно, он не обязателен.
Но вот я правда не понимаю зачем нужен нативный last_update. Тем более, что он есть и называется LSN.
> зачем его вообще бездумно везде лепят?
Хорошо, поторопилась. В данном случае, конечно, он не обязателен.
Но вот я правда не понимаю зачем нужен нативный last_update. Тем более, что он есть и называется LSN.
Вы можете мне ответить зачем нужен «ластапдейт неважно каких данных»? Я, правда, не вижу business case для этого. Что Вы будете с ним делать? Объясните, пожалуйста.
Инвалидацию кэша.
Кэша на уровне приложения?
Я правильно понимаю, что работает это примерно так.
1. При старте MySQL создаётся независимый от него кэш
2. Какое-то приложение читает данные из кэша и в MySQL вообще не ходит
3. Другое приложение пишет в MySQL, но о кэше из п. 1 ничего не знает
4. Демон раз в N секунд проверяет, изменились ли данные и если да, то обновляет кэш для одной таблицы.
?
1. При старте MySQL создаётся независимый от него кэш
2. Какое-то приложение читает данные из кэша и в MySQL вообще не ходит
3. Другое приложение пишет в MySQL, но о кэше из п. 1 ничего не знает
4. Демон раз в N секунд проверяет, изменились ли данные и если да, то обновляет кэш для одной таблицы.
?
Примерно так, да. Как вариант, приложение читает last update кэша и таблицы, сравнивает их и если отличаются, то обновляет кэш. Рассчитывать на то, что приложение и так само знает когда в последний раз писало, нельзя.
Понятно, спасибо! С одной стороны, логично зачем эта фича нужна и тут, в самом деле, хоть дату модификации файлов смотри. Но у меня есть 2 вопроса.
Вопрос 1. В исходном комментарии человек упомянул таблицу с 10 миллионами записей. Я так полагаю, что все они в кэше? Так как демон из п. 4 проверяет, изменились ли какие-то данные, то какие именно изменились его не интересует. То есть при изменении одной строки обновляется кэш целиком? Все 10 миллионов записей?
Вопрос 2. В версии 5.6 вот такая фича появилась: dev.mysql.com/doc/refman/5.6/en/innodb-memcached-benefits.html Она не поможет в этом случае?
Вопрос 1. В исходном комментарии человек упомянул таблицу с 10 миллионами записей. Я так полагаю, что все они в кэше? Так как демон из п. 4 проверяет, изменились ли какие-то данные, то какие именно изменились его не интересует. То есть при изменении одной строки обновляется кэш целиком? Все 10 миллионов записей?
Вопрос 2. В версии 5.6 вот такая фича появилась: dev.mysql.com/doc/refman/5.6/en/innodb-memcached-benefits.html Она не поможет в этом случае?
По вопросу 1: проверка кеша может быть многоуровневый. Сначала проверяем дату таблицы и если не совпадает, то ищем конкретные записи. Это быстрее чем
MAX(table.updated_at).Это разумно, но опять-таки, я боюсь, что если сделать эту фичу для InnoDB мы упрёмся в поддержку ACID и, в связи с этим, в производительность. Хотя в памяти, наверное, можно сделать. Или в performance schema.
В принципе имеет смысл написать как это может использоваться и нажать кнопку «Affects Me».
PS: Баг этот, кстати, типичный пример внтуренней конвертации бага в feature request.
В принципе имеет смысл написать как это может использоваться и нажать кнопку «Affects Me».
PS: Баг этот, кстати, типичный пример внтуренней конвертации бага в feature request.
пример выше хороший, у меня же в одной из компонент нужно уведомить другой, что данные изменились. Это в случае таблиц myisam очень красиво, быстро и логично выглядит и работает.
В другом месте, примерно тот же случай что VolCh описал, с той разницей, что проверяются части одной «таблицы» разбитой на части приоритетого и временного значения с разной интенсивностью, для опять же проверки и сообщения подсистеме кеширования.
В другом месте, примерно тот же случай что VolCh описал, с той разницей, что проверяются части одной «таблицы» разбитой на части приоритетого и временного значения с разной интенсивностью, для опять же проверки и сообщения подсистеме кеширования.
Спасибо!
А точный момент этих изменений, стало быть, не важен? Удобнее раз в, скажем, час ходить и проверять время изменения таблицы, чем повесить тот же trigger?
Вы тоже сходите проголосуйте за баг, плиз. И/или за второй, который я по мотивам этого топика открыла: bugs.mysql.com/bug.php?id=69673
А точный момент этих изменений, стало быть, не важен? Удобнее раз в, скажем, час ходить и проверять время изменения таблицы, чем повесить тот же trigger?
Вы тоже сходите проголосуйте за баг, плиз. И/или за второй, который я по мотивам этого топика открыла: bugs.mysql.com/bug.php?id=69673
Нормально, разрабы не фиксяк баг 7 лет и едят тортик в радость этому факту.
А это, кстати, много где так. В OpenSource-проектах вообще сплошь и рядом: баг известен, найден бажный кусок кода, и даже понятно, как его исправить… но по каким-то непонятным причинам оно не правится годами.
Недавно столкнулся с этим на примере Inkscape. Когда понял, что фильтр feComposite глючит при использовании отрицательных коэффициентов, а при некоторых значениях даже приводит к падению программы, я сразу же полез в исходники.
Баг обнаруживается буквально за 5 минут — в инлайновой функции NR_NORMALIZE_31 (определена в файле src/libnr/nr-pixops.h). Код писал явно какой-то школьник-максималист, т.к. там используется грязный хак с «быстрым делением» — собственно деление заменяется хитрым набором логических операций и сдвигов (вынесено в обёртку FAST_DIV_ROUND). Но вот в чём засада — не для всего интервала входных данных функция вообще работает, как собственно и ожидалось от таких «кульных» фишек.
И что же? Оказывается, данный баг давно уж в багтрекере, все про него знают. До сих пор не могу понять, по какой причине этот баг до сих пор не исправлен — видимо, кодить новые фичи куда приятнее, чем фиксить баги. К слову, в том же inkscape это далеко не единственный баг, проект очень сильно забагован. Как и GIMP, как и многое другое из OpenSource.
Недавно столкнулся с этим на примере Inkscape. Когда понял, что фильтр feComposite глючит при использовании отрицательных коэффициентов, а при некоторых значениях даже приводит к падению программы, я сразу же полез в исходники.
Баг обнаруживается буквально за 5 минут — в инлайновой функции NR_NORMALIZE_31 (определена в файле src/libnr/nr-pixops.h). Код писал явно какой-то школьник-максималист, т.к. там используется грязный хак с «быстрым делением» — собственно деление заменяется хитрым набором логических операций и сдвигов (вынесено в обёртку FAST_DIV_ROUND). Но вот в чём засада — не для всего интервала входных данных функция вообще работает, как собственно и ожидалось от таких «кульных» фишек.
И что же? Оказывается, данный баг давно уж в багтрекере, все про него знают. До сих пор не могу понять, по какой причине этот баг до сих пор не исправлен — видимо, кодить новые фичи куда приятнее, чем фиксить баги. К слову, в том же inkscape это далеко не единственный баг, проект очень сильно забагован. Как и GIMP, как и многое другое из OpenSource.
Меня больше напрягает когда pull-request'ы месяцами висят.
думал вначале, что тут что-нибудь про игру Portal будет))
but the bummer for me is that I now don't have a way to dump my schema cleanly for development purposes.
Настоящий «the bummer» в том, что приложение не должно вообще никак зависеть от текущего значения автоинкремента (в общем случае — значения PK). И хоть там сейчас 1, хоть 42 — всё должно работать одинаково.
А почему ХОХОХОХО?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Баг в MySQL получил на день рождения тортик