Несколько заметок о MySQL

[@miksoft]

Далее можно получать следующий ID из нужной последовательности с помощью функции
last_insert_id():

UPDATE `sequence` SET `some_other_id` = last_insert_id(`some_other_id` + 1);
SELECT last_insert_id();

Во-первых, функция last_insert_id тут не нужна, можно и сразу с полем работать. В ряде случаев это выйдет даже экономичнее.

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

[@maximw]

А что вы имеете ввиду под «сразу с полем работать»?

Да, в моем примере блокировка записи будет. Но можно делать не несколько столбцов одной записи, а несколько записей одной таблицы или даже несколько таблиц. Суть была именно в получении гарантированной последовательности без повторений.

[@miksoft]

А что вы имеете ввиду под «сразу с полем работать»?

Например, так:

UPDATE `sequence` SET `some_other_id` = `some_other_id`+1;
SELECT `some_other_id` FROM `sequence`;

Или так:

UPDATE `sequence` SET `some_other_id` = `some_other_id`+1;
INSERT INTO `some_other_table` (id, textfield) SELECT `some_other_id`, 'какой-то текст' FROM `sequence`;

Второй случай экономичнее, т.к. требует на один запрос меньше.

[@maximw]

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

Иначе между UPDATE `sequence` и SELECT FROM `sequence` может произойти что угодно. Аналогично и со вторым вариантом.

Я предлагал решение без явного старта транзакции.

[@miksoft]

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

Хм, да, действительно, предполагал одну транзакцию.

[@miksoft]

Да, в моем примере блокировка записи будет.

Тут я, кстати, не совсем прав. Если включен автокоммит (а это по умолчанию) и если дело не происходит в рамках явно начатой транзакции, то блокировка будет довольно короткая, только на время самого UPDATE-а. Т.е. скорее всего, она будет некритична.

[@varanio]

По-моему никто уже в здравом уме не использует Myisam. Это просто ненадежное хранилище данных (без записи в лог). При внезапном выключении электричества в момент записи данных всё бъется, причем не определить, что именно побилось, а что нет.

[@mpakep]

Задачи бывают разные. И если вас опасность потери данных беспокоит меньше скорости записи то myisam отлично подходит для этой работы.

[@varanio]

Запись в таблицу myisam однопоточная. Потому что приходится лочить всю таблицу перед изменением.
Так что innodb гораздо быстрее на запись, если сразу несколько потоков обновляют/вставляют данные.

MyIsam не нужна вообще. Никому.

[@virtusIV]

Фу, как голословно. Нужна мне. В моем проекте разница при использовании MyISAM более чем в 2 раза превышает скорость работы с InnoDB.

[@ValdikSS]

Если у вас insert тормозит, то не пробовали ли вы отключать вызов fsync() на каждую вставку?

[@varanio]

Не представляю, как это может быть. Вы что-то не то делаете с innodb

[@virtusIV]

В проекте необходимо высчитывать тысячи различных COUNT(*). На очень многих InnoDB проигрывает в скорости :(
P.S. Заранее хранить их значения в отдельной таблице не представляется возможным

[@virtusIV]

1. Не статистику
2. Другие инструменты тут не причем. Речь о MyISAM и InnoDB. И «знатоки» со знанием дела, явно, за всех решив, сказали, что MyISAM не нужен никому.

[@varanio]

count(*) на MyIsam выигрывает только в случае count по всей таблице, без каких-либо where. Но count по всей таблице делается относительно редко.
Если прям нужен общетабличный count, то можно использовать innodb, но кешировать где-нибудь или еще лучше обновлять по триггеру или по крону время от времени.

[@lgdmitrys]

может стоит использовать уникальный ID для всей базы данных?
select UUID_SHORT()

[@servekon]

Вредные советы без понимания мат.части.

Автоинкремент стал 5, хотя вставки не было. А что будет с MyISAM:

На самом деле вставка была, потому что запись сначала удаляется, а потом делается insert с новыми значениями. Чтобы это понимать нужно было прочитать документацию:
REPLACE works exactly like INSERT, except that if an old row in the table has the same value as a new row for a PRIMARY KEY or a UNIQUE index, the old row is deleted before the new row is inserted. See Section 13.2.5, “INSERT Syntax”.
Источник.
и
You can use REPLACE instead of INSERT to overwrite old rows. REPLACE is the counterpart to INSERT IGNORE in the treatment of new rows that contain unique key values that duplicate old rows: The new rows are used to replace the old rows rather than being discarded.
Источник.

И если вы указываете primary key с AUTO_INCREMENT зачем при вставке данных в таблицу явно указывать поле id?

Вообще уровень новичка чувствуется по тому, что автор следит за изменением поля AUTO_INCREMENT, созданного для того, чтобы не следить за ним вообще.

[@servekon]

А я не понимаю как такая статья могла набрать 30 плюсов… Я вот в даже в кошмарном сне не могу представить в каких случаях может понадобится такая структура таблицы «sequence», что нет ни одного обязательного параметра и таблицу можно заполнять нулями…

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

Для этих целей можно написать триггер.

[@VolCh]

На какую таблицу? А вообще, для размазывания логики в том числе на СУБД нужны, как правило, веские основания, а не просто единичный кейс.

[@maximw]

Не знаю, насколько страшные вам снятся сны. Однако, разрабочики многих других СУРБД сделали реализацию SEQUENCE. В MySQL этого дела нет, но решение по эмуляции, которое я предложил тут, есть в документации (см. в конце описания функции LAST_INSERT_ID()).

[@maximw]

Ок, каким образом вы получите в приложении id, если не «следить» за ним? Например, если у вас, в приложении одна логика для вставки и изменения с одним запросом INSERT… ON DUPLICATE KEY UPDATE?

PS. С REPLACE понятное дело, неудачный оборот «вставки не было», вставка конечно была после удаления. Просто имелось ввиду, что не было вставки новых данных в таблицу.

[@akamensky]

Оставлять дефолтные настройки на MySQL это очень неправильно. Как минимум нужно выставлять свой fsync и innodb_buffer_pool_size. Так как значения по-умолчанию убивают производительность очень сильно.

Поищите на англ. статьи вроде «MySQL performance tuning» особо порекомендую статьи от Percona.