Saboteur: да, действительно потерялось окончание при копировании. Но смысл не меняется. Конкурента нет, экономически выгоднее как раз термопаста. Поэтому стоит термопаста, а не припой.
FOR UPDATE лишь захватит эксклюзивную блокировку, что является одной из пессимистичных стратегий разрешения упомянутого race condition. Когда два пользователя параллельно сделали select valid_key = t и оба прошли проверку на приложении. Затем снимают флаг valid_key тоже оба, но второй ничего реально уже не меняет, флаг снят другим потоком. select for update заставит второго пользователя подождать транзакцию первого на этапе select и получить более ожидаемый "токен уже использован", вместо разрешения доступа.
Артём Андреев: если user_valid был f, то необходимость изменения никак из вашего вопроса и не вытекает. Поле должно менять значение всегда? С t на f, затем с f на t и так по кругу при каждом обращении? Тогда только два запроса.
Если только в одну сторону - то это не изменяет мой комментарий:
Если нужны остальные поля таблицы - нет, в mysql невозможно. Отдельный select требуется.
Если не нужны и надо только узнать, была ли такая строка до апдейта - да, это возможно одним запросом. select не нужен, достаточно одного update.
Вам нужны остальные поля из user_code?
Если да, нужны, и при том на mysql - то только вторым запросом. И внимание на существующий race condition.
Если нет, и вам нужно только узнать, существовал ли такой user_key с valid_key = t до обновления, то выполняете запрос, указанный Александр Золотых . Затем смотрите в affected_rows. Если 0 - значит такой строки не было, если 1 - значит была и она успешно изменена.
На am2 - да, один из топовых. И выпущен 10 лет назад. И не максимум того, на что способна ваша материнская плата, которая умеет и AM2+. В списке поддерживаемых CPU есть phenom x4 и даже phenom II x4 (но только beta версии биоса).
Почему видеокарта будет ждать? Потому что так устроено взаимодействие. Первая буква CPU - центральный. Видеокарта сама делать ничего не будет, пока её об этом не попросит процессор. Если процессор не успевает считать свою работу, то видеокарта будет простаивать даже в максимально тяжёлых режимах графики. Вот история десятилетней давности: https://www.overclockers.ru/lab/23700/ATI_Radeon_X...
AMD 6000+ примерно эквивалентен E6300 в номинале, может даже немного быстрее. Посмотрите, какая разница от более быстрого CPU с той же самой видеокартой.
Работает и устраивает - замечательно. И вот как раз чтобы вы не тратили напрасно деньги и высказываю сомнение, даст ли смена видеокарты что-то существенное. Я не знаю, умеет ли фотошоп использовать не профессиональную видеокарту (к тому же, старую, никакого OpenCL) - если умеет и использует, то профит будет за счёт этого. Надо смотреть утилизацию CPU в фотошопе и играх.
Никак. join выполняется сильно раньше select.
Можно сделать view и читать её, можно сделать from (select ...) as tablealias left join ..., можно продублировать построение даты в условие объединения.
Варианты (сортировка по оценочной трудоёмкости, от самого лёгкого):
- стукнуть того человека, который догадался делать дамп непредназначенным для того способом, да ещё в xml. Больно, многократно, по рукам. Заставить сделать нормальный дамп.
- снимать остальные ограничения на время работы бекенда. Редактирования одного лишь php.ini - это для консоли. А в вебе ещё веб-сервера (и хорошо если только один), fpm, помнится, тоже умеет отстреливать запросы по таймауту. Ещё бывают лимиты ожидания у самого HTTP-клиента.
- влезть в исходники этого phpmyadmin и адаптировать импорт для запуска из консоли. В принципе, это может проще предыдущего пункта.
- раскурить этот кусок хрени и написать предварительный консольный обработчик, который порежет файл на консистентные куски поменьше, которые скормить в phpmyadmin.
- раскурить исходник phpmyadmin или этот xml и написать консольный импорт.
ComodoHacker: вот не помню точно, как именно innodb реализует index only scan для mvcc. Но кажется, что никак и вычитывать версию строки надо именно из данных. Соответственно, никакой индекс при этом как-то помочь не может - всё равно надо вычитывать.
Да, согласен, если count надо делать 1 раз по праздникам - это будет дешевле. Но если на одно написание комментария будет сотня просмотров списка статей - счётчик непосредственно в статьях более чем оправдан.
semki096: нет, вы спросили как раз про форк. Идею вы открываете сразу и безусловно при старте проекта, хоть с закрытым исходником хоть с открытым. Нельзя украсть опубликованную идею.
Лицензия, запрещающая форки - не знаю такой из распространённых. Скорей всего это будет кастомная лицензия.
Когда не укладываетесь в желаемую производительность - вот тогда и денормализовывать. Какую-то аггрегацию нередко оправдано добавлять сразу, как появилась необходимость её выводить на веб-морде, например, статистику чего-нибудь для графиков. Меняется только хвост, а начало статично. При том, таблиц аггрегации может быть и несколько. Это может быть и материализованное представление, когда наконец сделают инкрементное обновление - но тоже своего рода таблица. Теоретически, это денормализация, вот только для исходных данных нормальная форма остаётся как есть. Добавляется только предварительно рассчитываемый аггрегат.
