Melkij

Давным-давно, в далёкой галактике...
Хм, нет, в этой галактике. И не так уж давно, 199х, начало 200х годов процессоры поставлялись вообще без крышки, кулер устанавливался напрямую на кристалл CPU. Но бывало кристалл при неаккуратном воздействии повреждался. К тому же, в эти года был огромный прогресс производительности CPU, но и весьма заметный рост потребления энергии, что вело к увеличению массы кулера и повышению риска повредить кристалл.
В итоге (не помню, кто первый), начали кристалл прикрывать теплораспределительной (и заодно защитной) крышкой. Одновременно с этим эту крышку начали снимать для разгона. Т.к. лишний посредник, немного ухудшает теплопроводность. К тому же, бывали случаи не совсем брака, кривая (выпуклая или вогнутая) крышка, кулер прижимался неплотно, что ухудшало охлаждение. Бывало, что неравномерно была припаяна сама крышка (а в те времена использовался именно припой) и ядро грелось сильнее, чем одноклассники. Иногда крышку снимали и вообще не ставили обратно. Иногда снимали, меняли термоинтерфейс и ставили крышку обратно. Штука рискованная (припой держится весьма прочно, повредить кристалл просто), давала всего несколько градусов выигрыша, поэтому не слишком популярная.

Несколько лет назад интел офигел от отсутствия конкуренции и больше не использует припой между крышкой и кристаллом. Сначала в дешёвых CPU, начиная с Ivy Bridge LGA1155 (да, если вы не знали позицию интела: 6700K - это дешёвый процессор. Не дешёвый - это $1000 и выше). Сейчас уже и в младших представителях линейки энтузиастов (LGA 2011-3) используется термопаста вместо припоя. На счёт серверных xeon не уверен, но скорей всего там пока держится припой.

Почему использует? Термопаста банально дешевле припоя, и значительно дешевле жидкого металла. На одного человека, выразившего недовольство новой политикой - есть армия тех, кто ничего не заметил. Первыми просто пренебрегли.

Saboteur,

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

Покажите конкурента. AMD Zen - надеемся, ждём. Текущая линейка не конкурент для производительного сегмента.
А пока нет конкурента - можно снижать затраты на производство. Всё закономерно.

select date(`created_at`) as create_date, sum(if(type = 'new', 1,0)) as new_count, sum(if(type = remove, 1,0)) as rm_count
from actions 
where user_id = 1 and created_at > DATE_SUB(CURRENT_DATE, INTERVAL 7 DAY)
group by create_date

Ну а если надо часто такую аггрегацию делать - сделайте таблицу с предварительно агрегированными по дням данными.

php > var_dump(password_verify(null, '$2y$05$WjKwE1MiWPyPFghASGGcdupFqfcUHchkb2y/rwTiCWe40iIbqyxKq'));
bool(true)
php > var_dump(password_verify('', '$2y$05$WjKwE1MiWPyPFghASGGcdupFqfcUHchkb2y/rwTiCWe40iIbqyxKq'));
bool(true)

Проверяйте, от чего именно вы получаете хеш. И когда вы его получаете. Где-то там сам пароль потерян и осталась пустая строка.

Разбирать вручную из file_get_contents('php://input');
Возможно, ещё пригодится parse_str, которой PHP сам разбирает query string в $_GET и application/x-www-form-urlencoded в $_POST.

Зависит от версии PHP.
Первые 3 примера допустимы в PHP 5.6 и выше. php.net/manual/en/migration56.new-features.php

Вызов метода и обращение к другим свойствам - на данный момент непосредственно в коде объявления недопустимы.

Триггер не нужен, mysql умеет самостоятельно такое делать. ON UPDATE CURRENT_TIMESTAMP в объявлении колонки.
https://dev.mysql.com/doc/refman/5.7/en/timestamp-...

Нет, не ускорит. Нужен функциональный индекс именно по length(field).

mysql 5.7.6 позволяет создать вычисляемые поля: https://dev.mysql.com/doc/refman/5.7/en/create-tab...
Это может быть STORED значение - т.е. будет занимать место как обычное поле, но вычисляться автоматически при добавлении/изменении строки. Может индексироваться всё с той же 5.7.6. И может быть virtual - такое поле вычисляется при обращении, не хранится на диске, но может индексироваться только с версии 5.7.8.

Если ваша версия старая и не умеет генерируемые колонки - то в вашем распоряжении всё ещё остаются старые методы для имитации функционального индекса: создаёте ещё одно числовое поле, куда сохраняете длину текста. Индексируете как обычно. За актуальностью данных могут следить пара триггеров на before insert и before update.

Изменение схемы в MySQL на лету - это своя особая песня.

MySQL 5.6+: https://dev.mysql.com/doc/refman/5.6/en/innodb-onl...
Или делать что-то странное, как в старые тяжёлые времена. Людьми, связавшимися с mysql, были изобретены разные методы. От извращений с созданием новых таблиц и триггеров до statement-репликации и alter table на слейве, затем объявление этого слейва новым мастером.

select `date` + interval minute_start minute from tablename;