Melkij

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

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

Со стороны СУБД:
Postgresql: pg_stat_statements
https://www.postgresql.org/docs/current/static/pgs...
Mysql: slow query log
dev.mysql.com/doc/refman/5.7/en/slow-query-log.html
Для других не в курсе, ну раз даже у mysql есть хоть что-то, то и у других точно что-нибудь будет.

Со стороны PHP - xdebug + kcachegrind точно скажет, где теряете время для конкретного запроса и как туда попали. Для мониторинга боевой системы в целом - посмотрите в сторону pinba.
Из самого кода проекта - непосредственно библиотеки доступа к субд профилированием не занимаются. Поэтому нужно смотреть конкретный проект, есть ли там место, куда можно воткнуть профилирование запросов.

Касательно именно 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 оптимизирован под запись последовательно-возрастающих значений. На записи случайных данных несколько просядет производительность. На сколько именно - надо измерять, не помню.
На небольшой табличке всего-то в пару десятков миллионов строк - это значения иметь не будет.

ansible/salt/chef/puppet. Особенно если задача не одноразовая.

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

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

Ожидал получить в выборке не более одной строки с каждым ref_id

GROUP BY ref_id, id

С чего бы это вы ожидали увидеть только один ref_id, если явно сказали затем группировать по id?
С учётом названия и того, что postgresql в принципе согласился запрос выполнить - id является первичным ключом. А группировка по первичному ключу ожидаемо результат не изменит.

select  distinct on (ref_id)  ref_id,  id,  created_at from tablename  order by ref_id, created_at desc;

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

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