он делает инсерт, в результате чего увеличивается автоинкремент

Кончатся, бигинт?

што

у тебя скоростей не хватит столько в секунду писать, чтобы они к твоей смерти кончились

https://habrahabr.ru/post/156489/

on duplicate key update делает либо инсерт, либо апдейт, но не вместе

у тебя скоростей не хватит столько в секунду писать, чтобы они к твоей смерти кончились

уф, про бигинт не я написал, я говорю что int кончится

on duplicate key update делает либо инсерт, либо апдейт, но не вместе

принцип работы такой, увеличивает

прочти выше статью

да и проверил я уже

прочти выше статью

в статье долго и нудно рассказывают то, что я написал выше. в чём проблема-то в итоге? в том, что autoincrement значения теряются при вставке?

дырки в данных будут, бяда(

хех

в статье долго и нудно рассказывают то, что я написал выше. в чём проблема-то в итоге? в том, что autoincrement значения теряются при вставке?

Да не т их наверное

приветствую, помогите разобраться sqlalchemy.exc.IntegrityError: (pymysql.err.IntegrityError) (1215, 'Cannot add foreign key constraint') [SQL: 'ALTER TABLE abbrev_food_group ADD FOREIGN KEY(ndb) REFERENCES abbrev (ndb)'] был разный тип данных abbrev | CREATE TABLE abbrev ( ndb int(11) NOT NULL, abbrev_food_group | CREATE TABLE abbrev_food_group ( ndb int(11) NOT NULL, привет к единному типу, а добавить не может

в одной был тип float, может поэтому?

значения в таблицах проверял?

тот ключ, на который пытаешься сослаться - он уникальный?

mysql> select count(*), ndb from abbrev group by ndb having count(*) > 1; Empty set (0,20 sec)

mysql> select count(*), ndb from abbrev_food_group group by ndb having count(*) > 1; Empty set (0,24 sec)

давай ddl таблиц, индекс видими нужен ключу, в мускуле ключ необязательно должен быть уникальным

https://pastebin.com/h4y26kkJ

добавь на таблицу ndb либо primary key, либо просто индекс

если требуется неуникальность

и в innodb лучше вообще не делать таблицы без первичного ключа

mysql> select count(*), ndb from abbrev group by ndb having count(*) > 1; Empty set (0,20 sec)

Я не про данные, я про ключ. Констрейнт уникальности существует на колонке?

добавь на таблицу ndb либо primary key, либо просто индекс

хм, вот вы заметили, а я не видел что primary нет, в орм просто есть __tablename__ = 'abbrev' ndb = db.Column(db.Integer, primary_key=True) Description = db.Column(db.String(300))

Если в кратце описать, люди в ручную писали скрипты для добавления в бд, а потом захотели прикрепить миграции и вот получилась пачка изменений, которые невозможно принять # ### commands auto generated by Alembic - please adjust! ### #op.create_foreign_key(None, 'abbrev_food_group', 'abbrev', ['ndb'], ['ndb']) #op.drop_index('useridconst_idx', table_name='clients') #op.create_foreign_key(None, 'clients', 'doctors', ['doctor_id'], ['id']) #op.drop_index('useridconstfordoctors_idx', table_name='doctors') op.create_unique_constraint(None, 'recipe', ['title']) op.alter_column('recipe_ingredient', 'ingredient_id', existing_type=mysql.INTEGER(display_width=11), nullable=True) op.alter_column('recipe_ingredient', 'recipe_id', existing_type=mysql.INTEGER(display_width=11), nullable=True) op.drop_index('name_UNIQUE', table_name='roles') op.alter_column('users_roles', 'role_id', existing_type=mysql.INTEGER(display_width=11), nullable=True) op.drop_index('fk_users_roles_1_idx', table_name='users_roles') op.drop_index('fk_users_roles_2_idx', table_name='users_roles') op.drop_constraint('fk_users_roles_1', 'users_roles', type_='foreignkey') op.drop_constraint('fk_users_roles_2', 'users_roles', type_='foreignkey')

как лучше сделать? создать чистую бд через орм и потом накатить данные (может дамп не накатится) или попытаться все таки все это исправить?

сверить скрипты миграции со схемой данных в базе и исправить

` CREATE TABLE abbrev_food_group ( ndb int(11) NOT NULL, group_id int(11) DEFAULT NULL, PRIMARY KEY (ndb), KEY group_id (group_id), CONSTRAINT abbrev_food_group_ibfk_1 FOREIGN KEY (group_id) REFERENCES food_group (group_id), CONSTRAINT abbrev_food_group_ibfk_2 FOREIGN KEY (group_id) REFERENCES food_group (group_id), CONSTRAINT abbrev_food_group_ibfk_3 FOREIGN KEY (group_id) REFERENCES food_group (group_id), CONSTRAINT abbrev_food_group_ibfk_4 FOREIGN KEY (group_id) REFERENCES food_group (group_id) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=DYNAMIC ` вот это вообще жесть какая-то

как лучше сделать? создать чистую бд через орм и потом накатить данные (может дамп не накатится) или попытаться все таки все это исправить?

я в своем кейсе миграциями воссоздавал структуру, потом, когда убедился в идентичности, перелил данные

Всем привет, может кто помочь с типом данных SET?

Интересует скорость работы. Основня идея - использовать для хранения флагов доступа пользователей. Целесообразно ли это? Будут ли проблемы при больших объемах записей? Индексирует ли mysql столбцы с этим типом?

Внутреннее представление у него числовое, индексироваться должен

Если флагов больше 64 можно свою битовую маску намутить

Предствление то понятно числовое это по сути byte, только вот byte как число тоже индексируется, а если делать выборку по битовой маске, то индексация не работает. В документации про интексацию не нашал ничего толком...

Флагов меньше 64, поэтому выбор и пал на set

если ты собираешься именно выбирать по правам доступа, то лучше завести интовую колонку и выбирать по инту

вставить одним запросом

о да, это даст несколько микросекунд выигрыша

Доку про PDO прочитать. И не вставлять в первичный ключ непонятно что.

спасибо

приветствую1

есть форум — сменил хостинг, установил движок, подключил старую базу, при добавлении расширения (flagrow) получаю эту ошибку

помогите разобраться с ошибкой General error: 1005 Can't create table 'eikon145.#sql-83f_5c20' (errno: 150)

SHOW ENGINE INNODB STATUS; показывает ------------------------ LATEST FOREIGN KEY ERROR ------------------------ 170707 19:55:50 Error in foreign key constraint of table `eikon145`.`flagrow_file_downloads`: Alter table `eikon145`.`flagrow_file_downloads` with foreign key constraint failed. Referenced table `eikon145`.`flagrow_files` not found in the data dictionary near ' foreign key (`file_id`) references `flagrow_files` (`id`) on delete cascade'.

SET FOREIGN_KEY_CHECKS = 0; не помогает =(

он случайно не пытается создать ключ раньше создания таблицы?

он случайно не пытается создать ключ раньше создания таблицы?

c другой бд работает

SHOW ENGINE INNODB STATUS; показывает ------------------------ LATEST FOREIGN KEY ERROR ------------------------ 170707 19:55:50 Error in foreign key constraint of table `eikon145`.`flagrow_file_downloads`: Alter table `eikon145`.`flagrow_file_downloads` with foreign key constraint failed. Referenced table `eikon145`.`flagrow_files` not found in the data dictionary near ' foreign key (`file_id`) references `flagrow_files` (`id`) on delete cascade'.

ну оно вроде ясно показывает, что к моменту создания foreign key таблица eikon145.flagrow_files не существует. с этим и нужно разбираться. возможно на другой бд эта таблица уже есть к моменту установки расширения. скорее всего, ошибка в скрипте установки

Всем прив. на стороне MySQL хочу сделать арифметику, прим. такого вида: Если поле A == 1, тогда поле B * на поле C, и сохранить в поле D в кокую сторону копать? дайте наводку? процедура мне нужна да?

Всем прив. на стороне MySQL хочу сделать арифметику, прим. такого вида: Если поле A == 1, тогда поле B * на поле C, и сохранить в поле D в кокую сторону копать? дайте наводку? процедура мне нужна да?

судя по описанию достаточно будет UPDATE + CASE: https://dev.mysql.com/doc/refman/5.7/en/control-flow-functions.html#operator_case

кАкую

а вичисление как считать?

Коллеги, нужна помощь коллективного разума. Перетащили с большого сервера на несколько мелких облачных разные проекты. Один из проектов раз в 5-7 минут по крону в базу mysql обновляет (а также создаёт новые и удаляет старые) десятки тысяч записей. Так получилось, что ресурсов облачного компа ему не хватило, и в какой-то момент база покрашилась. Потом она завелась, и перешла в режим автоматического repair. Всё бы ничего, но место там хдд ограничено, и база сама по себе обычно занимает 3-4 гига. Тем не менее, repair уже занимает больше 14 часов, а свободное место на диске 2 гига из 20.

Не стал бы спрашивать, если бы не изучил предварительно гугл

Пока склоняюсь к мистической версии

iotop показывает загрузку в 98-99% процесса mysqld, с ~2.5-3Mb/s mytop показывает Query Repair table

Так а распухла то из-за чего база?

из-за repair

сейчас только он запущен. а файл растёт ?

я вообще с таким впервые сталкиваюсь

напишешь, чем все в итоге закончится?) а то интересно)

Коллеги, нужна помощь коллективного разума. Перетащили с большого сервера на несколько мелких облачных разные проекты. Один из проектов раз в 5-7 минут по крону в базу mysql обновляет (а также создаёт новые и удаляет старые) десятки тысяч записей. Так получилось, что ресурсов облачного компа ему не хватило, и в какой-то момент база покрашилась. Потом она завелась, и перешла в режим автоматического repair. Всё бы ничего, но место там хдд ограничено, и база сама по себе обычно занимает 3-4 гига. Тем не менее, repair уже занимает больше 14 часов, а свободное место на диске 2 гига из 20.

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

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

Я приблизительно так и догадывался, но места там не хватит, а базу надо восстановить. Есть ли возможность это восстановить на другой машине?

да, можно скопировать весь datadir на другую машину и там восстанавливать

и вот я бы ещё от myisam в перспективе отказался. зачем её использовать в 2017 году — не понимаю

и вот я бы ещё от myisam в перспективе отказался. зачем её использовать в 2017 году — не понимаю

а это вообще не ко мне вопрос. я бы отказался от mysql если честно. но разработчики и клиенты - люди странные. любят очень странные вещи. а мне, как принципиальному стороннику чистого кода и правильной архитектуры некоторые вещи в корне не понятны.

но да, попробуем всё это как-то вот на другой машине видимо запустить :-/

ну, переход от myisam к innodb — это простая вещь, которую пользователи-то скорее и не заметят. зато админ заметит в таких вот случаях

ну, переход от myisam к innodb — это простая вещь, которую пользователи-то скорее и не заметят. зато админ заметит в таких вот случаях

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

я же говорю, вопрос не ко мне. к разработчику. им нужно чтобы был MyISAM