Оптимизировать SQL-запросы
Я столкнулся с интересной проблемой в очень простом случае.
У меня есть таблица сообщений и пользователей в базе данных MySQL. Сообщения могут нравиться пользователям.
Итак, есть отдельная таблица, называемая лайками, в которой есть столбцы: user_id, post_id.
Когда пользователь нажимает кнопку Like в приложении, выполняется запрос к скрипту php. Скрипт проверяет, есть ли в таблице строка, в которой post_id и user_id соответствуют информации из запроса. Пользователь не может поставить больше одного лайка к сообщению, и если я нажму лайк на уже понравившейся публикации, предыдущее лайк исчезнет
Сейчас использую 2 запроса: 1) проверьте, что лайк существует в таблице 2) Если записи нет - добавляю, а если есть - удаляю.
Теперь я вижу, что в моей таблице есть двойные лайки для одного и того же сообщения от одного и того же пользователя. Кажется, что два запроса от одного пользователя могут быть выполнены практически мгновенно.
Как его оптимизировать - чтобы нельзя было добавить два лайка к одному посту от пользователя? Я думаю, что вместо этого мне нужно выполнить один запрос, но что это должно быть?
Я думаю, вам нужно синхронизировать вызов со своим PHP-скриптом
посмотрите ТАБЛИЦЫ БЛОКИРОВКИ - чтобы избежать одновременных обновлений. ЗАБЛОКИРУЙТЕ таблицу перед SELECT и UPDATE - после завершения; РАЗБЛОКИРОВАТЬ ТАБЛИЦЫ
Ответы 3
просто используйте флаг (столбец со значением 0 или 1) и обновите значение, не удаляя всю строку.
ваши шаги должны быть следующими:
- проверьте наличие строки.
- если существует, обновите столбец (например, - 1, в отличие от - 0)
Это оно.
в шаблонах проверьте на 0 или 1 для непохожего и похожего
Не нужно ничего «проверять».
проверка предназначена для отображения значка типа / отличия в шаблоне внешнего интерфейса
Очевидно, что ваша часть вставки / обновления запускается несколько раз. Вы должны выяснить, почему это происходит, а затем, если возможно, предотвратить это.
Из-за нескольких вызовов СУБД несколько раз запрашивает, существует ли запись. На все звонки ответ отрицательный. Затем запускаются несколько вставок, и вы получаете дубликаты. Итак, со стороны SQL есть две ошибки:
- Почему можно даже вставить несколько записей для одного и того же сообщения и пользователя? Чтобы это было невозможно, необходимо предоставить первичный или уникальный ключ.
Считаю это обязательным для вашей датамодели.
- Последовательность действий неправильная. Возможным решением может быть сначала вставка (один будет успешным, другие не удастся - вышеупомянутый ключ, конечно же, предоставляется!), А в случае неудачи будет выпущено обновление. Однако MySQL может сделать это даже за один шаг:
с ON DUPLICATE KEY:
insert into likes (post_id, user_id, like_date)
values (@post_id, @user_id, current_date)
on duplicate key update like_date = current_date;
Используйте InnoDB, затем
START TRANSACTION;
SELECT ... FOR UPDATE;
if it does not exist
INSERT ...;
else
DELETE ...
COMMIT;
Используя семантику транзакций, вы избегаете проблем, связанных с наступлением нескольких подключений друг на друга. Думаю, я даже избежал тупика.
вам нужно разместить образцы запросов, если вам нужен лучший ответ. Это поможет пользователям лучше понять вашу проблему.