Melkij

Триггер не нужен, 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;

Нафига было делать XML экспорт? Судя по тегам - читать это может только сам phpmyadmin. Поставьте на виртуалку lamp, импортируйте этот дамп, экспортируйте в нормальный sql - импортируйте на целевой машине нормальным способом.
Или поставьте на виртуалку lamp, настройте проброс портов до целевой машины (например, силами SSH) и импортируйте через phpmyadmin.

DATE(orders.created_at) >= :start

Никогда не использовать условия такого плана. Это прямой запрет использования индекса по created_at, довольно вероятно селективного для этих запросов.

SELECT orders.delivery, SUM(orders.delivery) AS summ
          FROM orders
          JOIN baskets ON  orders.basket_id=baskets.id
          WHERE baskets.purchase_status = 3 AND orders.deleted_at IS NULL 
              AND orders.created_at >= :start AND orders.created_at <= (:finish + interval 1 day)
          GROUP BY orders.delivery

И разобрать несколько строк ответа на приложении.

SELECT SUM(if(orders.delivery = "kazpost", orders.delivery,0)) AS kazpost,
SUM(if(orders.delivery = "courier", orders.delivery,0)) AS courier,
SUM(if(orders.delivery = "pickup", orders.delivery,0)) AS pickup
          FROM orders
          JOIN baskets ON  orders.basket_id=baskets.id
          WHERE baskets.purchase_status = 3 AND orders.deleted_at IS NULL 
              AND orders.created_at >= :start AND orders.created_at <= (:finish + interval 1 day)

В одну строку.

Затем смотреть explain

Сутки так по-английски и пишутся:

DELETE FROM Users WHERE regdate < (NOW() - interval 1 day) AND confirmed = 0;

https://dev.mysql.com/doc/refman/5.7/en/account-na...
dev.mysql.com/doc/refman/5.7/en/user-names.html
Никак не повлияет. Допустимое имя. Иначе вы бы и не создали такого пользователя.

Если нужна таблица - должна быть таблица.

Postgresql предоставляет шикарную возможность разделить базу данных на схемы. Есть пачка таблиц, описывающая какую-нибудь сущность? Перенесите их в отдельную схему и пусть не мешаются в public. Таблицы аггрегации? Выкиньте их в отдельную схему.
Замечательно помогает, если становится многовато таблиц (несколько десятков разве много?).
Правда, если вы любитель всякого орм, ваша библиотека может не уметь схемы.

Вторичные индексы InnoDB, как известно, ссылаются на значение первичного ключа, а физически на дисках данные лежат рядом с первичным ключом и отсортированы по по этому самому первичному ключу. Значит, если в индексе написано, что вам нужны id 9, 6, 50, 8 и 7, выгоднее их читать с диска не в таком порядке, а пересортировать и прочитать двумя запросами: 6-9 и 50. Так получаем 2 запроса случайного чтения вместо 5. Это весьма полезно для HDD с медленной механикой, но ещё и приносит свои, хоть и более скромные, дивиденды для SSD - они хоть и на порядки быстрее HDD в случайном чтении, но и им тоже удобнее последовательное, а не случайное чтение.

Вот MRR этим как раз и занимается. Сначала получает список необходимых ключей от индекса, сортирует этот список и запрашивает у диска не по одной записи в случайных местах, а более крупными последовательными блоками.
Замечу, что MRR вступает в дело, если надо много чего прочитать с диска. Т.е. холодное чтение, данных для этой выборки по большей части нет в памяти. Разумеется, это далеко не быстрая штука.

И ещё момент: у вас в запросе нет order by, но есть limit - это значит, что вам всё равно, какие именно строки выбрать. Mysql в таком случае будет возвращать любые подходящие строки в любом порядке на своё усмотрение.