Керування файлами cookie, які використовуються для реклами, таких як персоналізація реклами, ремаркетинг і аналіз ефективності реклами.
|
dabeedj
01.06.2016 18:19
0
|
Доброго дня
Пропоную змінити параметер у mysql.ini Замість стандартного значення прописати innodb_autoinc_lock_mode = 0 На даний момент при спробі INSERTу дубляжу унікального ключа за допомогою INSERT IGNORE вставка не відбувається (як і має бути), але спрацьовує auto_increment Таким чином, якщо, для прикладу, поточний primiry key auto_increment = 1 і зробити 10 вставок з дублями, кількість рядків не збільшиться, а auto_increment буде = 11 Наскіьки мені відомо, на нормально роботузвичайних запитів воно не вплине Хотів би почути вашу думку |
|
rudenko
02.06.2016 01:59
1
|
Режим consecutive был создан для того, чтоб дать возможность одновременно выполнять несколько простых INSERT в таблицу без необходимости блокировать другие INSERT запросы. Этого нет в traditional, который был до версии 5.1 - там любой INSERT запрос блокирует другой INSERT. Да, минусом в этом случае является увеличение значения auto increment при MIXED INSERT и INSERT ON DUPLICATE KEY UPDATE
|
|
dabeedj
02.06.2016 02:04
0
|
І що, в даному випадку, білше зло?:)
Для мене consecutive. Можливо є якесь рішення, як обійти це і не завалити ресурси сервака, про яке я не знаю?:) |
|
rudenko
02.06.2016 02:08
1
|
Можливо є якесь рішення, як обійти це і не завалити ресурси сервака, про яке я не знаю© dabeedj Возможно перевод этой таблицы на MyISAM решит проблему? Если транзакций нет, то вполне возможно это будет выход из ситуации? |
|
dabeedj
02.06.2016 02:11
0
|
Якби не були потрібні зовнішні ключі, то я б так і зробив
|
|
rudenko
02.06.2016 03:04
0
|
А на что влияет рост значения id в таблице? почему не получается просто проигнорировать этот факт?
|
|
dabeedj
02.06.2016 03:26
0
|
Як в одному анекдот - "нєакуратнєнько виходіт":)
Таких "прольотів" може бути тисячі за раз і букавальне за пару днів можна добратись до 7-8-значних id, при тому, що реально записів буде декілька сотень |
|
vivasoft
02.06.2016 11:00
2
|
Таких "прольотів" може бути тисячі за раз і букавальне за пару днів можна добратись до 7-8-значних id, при тому, що реально записів буде декілька сотень © dabeedj Оберіть коли навантаження найменше та по крону запускайте в цей час скрипт що буде перевстановлювати ID - якщо у вас UPDATE для ключів CASCADE тоді ключи оновлюяться автоматично - профіт! Або перейдіть на UUID тоді проблема відстрочиться на ...... багато там щось ~ 10^42 варіантів + UUID генерується по часу якщо я правельно пам'ятаю :) І доречі з огляду на ACID consecutive все ж добро ;) Update ~10^38 точніше 2^128 ) трошки менше але це все рівно більше ніж BIGINT в якому 2^64 |
|
dabeedj
02.06.2016 21:30
0
|
Хороша ідея, загалом:) Але я з тих "бувших", які мали 48кБ RAM на початках і я терпіти не можу таку "розточітєльность":)))
|
|
vivasoft
03.06.2016 11:12
0
|
Хороша ідея, загалом:) Але я з тих "бувших", які мали 48кБ RAM© dabeedj Не повірите але не ви один :) Проте час іде і треба еволюціонувати ;) P.S. Добре добре в мене не 48КБ було вже, а в мегабайтах. Але 8МБ це було мега круто і пакування данних через бітові поля в Сях було нормою:) |
|
dabeedj
03.06.2016 15:56
0
|
Я взагалі на Сях намагався максимум, що можу, на ассемблері ембедити:) Ібо ібо:)
|
Тема закрита.