Melkij

Всё так. Что сказали сделать, то СУБД и сделала.

create table as select никак не связано с копированием структуры таблицы. Создаёт новую таблицу, используя в качестве полей результат запроса и затем копирует результат запроса в качестве данных.

Копирует структуру таблицы включая индексы запрос CREATE TABLE newtable LIKE oldtable;
Данные не копирует. Можно скопировать через insert .. select.

Давайте считать:
timestamp - 4 байта
tinyint по 1 байту
int - 4 байта
varchar(255) - где 255 длина в символах. В байтах будет больше. Например, для utf8, потребуется 255*3+2 байта. 767 байт. Для utf8mb4 - 255*4+2
Итого строка индекса занимает 4 + 767 + 1 + 1 + 4 = 777 байт. Немного не хватает, может быть у вас какие-то из полей могут быть NULL?

Да, если вы не знали, в индексе и в памяти (например, при сортировке) varchar всегда развёрнут до максимальной длины.
Если возможные строки у вас фиксированы - используйте enum. 1 или 2 байта места для записи. И уж определённо не 255, если у вас строки в 4-6 символов.

Существующие в таблицах данные не проходят проверку внешним ключом. Т.е. существуют ссылки на отсутствующие магазины.

assert('!empty($fieldNames) and is_array($fieldNames)');
$query = 'set field_name = (' . join(' + ', $fieldNames) . ')/' . count($fieldNames);

Вероятна ошибка проектирования схемы БД. С учётом использования давным-давно удалённых функций mysql_* вероятность ошибки, а не осмысленного выбора резко увеличивается.

Касательно именно mysql/innodb - innodb всегда кластеризован по первичному ключу. Поэтому все вторичные индексы всегда указывают на первичный ключ. Что из этого следует:
select time, md5 from img where md5=?
Потребует просмотра всегда двух индексов. Сначала индекса по md5, потом - первичного ключа.
С первичным ключом по md5 этот запрос сделает один просмотр индекса и для вычитывания time, не входящего в индекс, даже не потребует seek - данные лежат непосредственно рядом с листьями первичного ключа. Т.е. от выкидывания суррогатного ключа этому запросу чистый профит.

Не случайно написал time в запросе, если запросить только select md5 или select md5, id - то это будет index only scan по вторичному ключу и сейчас, без обращения ни к первичному ключу ни к самой таблице.

во-вторых,
int - это 4 байта. varchar32 для cp1251 (почему вообще varchar, а не char(32) или вообще binary(16)?) - 32 байта, timestamp 4 байта. Из-за необходимости ссылаться на куда более объёмный первичный ключ, резко увеличатся в объёме все вторичные индексы. Но вторичный индекс у вас останется только один, да один индекс исчезнет, а уникальный немного похудеет за счёт преобразования в первичный. Не столь огромный оверхед получится, вполне можно пережить. Но может быть не столь интересно, если показана часть таблицы и есть кучка других полей и индексов.
Поиск по time чуток просядет, строки сравнивать всё-таки сложнее пары интов. Но на десятке млн записей, да на mysql значения это играть не будет.

в-третьих, innodb оптимизирован под запись последовательно-возрастающих значений. На записи случайных данных несколько просядет производительность. На сколько именно - надо измерять, не помню.
На небольшой табличке всего-то в пару десятков миллионов строк - это значения иметь не будет.

"нативный текст" - это то, что в поле уже есть до выполнения запроса?

update tablename set img_url = concat('/images/', img_url);

Подключиться и скомандовать
show databases like 'db_name'
Будет строка в ответе - значит есть БД. Пусто - значит нет такой.

Плюс, create database умеет идемпотентное поведение
CREATE DATABASE IF NOT EXISTS db_name
dev.mysql.com/doc/refman/5.7/en/create-database.html

innodb - это MVCC.
Чтобы узнать, сколько строк в таблице - нужно узнать, какие версии строк может видеть эта транзакция. Без вычитывания всех подходящий строк ответ не получить. Разумеется, быстро это работать не будет.
Поэтому данные в information_schema - приблизительная оценка всегда.

Уменьшайте объём данных. Например, если вы растёте по шкале времени, то стройте аггрегаты по времени заранее. Например, по дням и часам. Текущий час s/вычитывать count'ом/инкрементить в каком-нибудь редисе или мемкеше вместе с insert'ами/g,, потом пересчитывать и сохранять к другим аггрегатам.

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

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