SET1

Неправильный формат. Лишние запятые. Переда закрывающей скобкой не должно быть запятых.

1. Выборку по таблице tbl_publication можно вынести в подзапрос. Тогда её можно сразу ограничить 12 записями и делать JOIN по небольшому набору. Заодно можно избавиться от группировки, тем более, что в строгом SQL она неправильная.
2. Учитывая, что используется LEFT JOIN с условием tbl_publications_media.media_type = 3, условие

(tbl_publications_media.media_type IS NULL OR tbl_publications_media.media_type = 3)

будет истинным всегда, от него можно избавиться.

SELECT `p`.`id`, `p`.`name`, `p`.`content`, `p`.`create_time`,
       `p`.`type`, `p`.`section_id`, `m`.`media_url`
  FROM (
    SELECT `id`, `name`, `content`, `create_time`, `type`, `section_id`
      FROM `tbl_publication`
    WHERE `article` = 0 AND `status` = 1 AND `type` = 0
    ORDER BY `p`.`id` DESC
    LIMIT 12
  ) AS `p`
  LEFT JOIN `tbl_publications_media` AS `m`
    ON `m`.`publication_id` = `p`.`id`
      AND `m`.`media_type` = 3

P.S. Про группировку:
Представьте, что с одной строкой из tbl_publications связались две разные строки из tbl_publications_media. Какая из них должна попасть в группу и почему?

RewriteCond %{REQUEST_FILENAME} !-f
#если это не файл
RewriteCond %{REQUEST_FILENAME} !-l
#  и если это не линка
RewriteCond %{REQUEST_FILENAME} !-d
# и это не директория
RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$
# и это не нужный нам файл, от цикла
RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]
# то перенапраить все это лядство на него ;)

Логика понятна ?

Поправка к ответу @bqio

const re = /({.*?})/g; // не жадный
let result;
while ((result = re.exec(str)) !== null) {
  console.log(JSON.parse(result[1]));
}

Вы делаете JOIN, а затем проверяете столбец media_type на определенное значение (т.е. этот столбец не может быть пустым), поэтому естественно будут возвращаться только те публикации, для которых есть записи в таблице tbl_publications_media. Нужно этот столбец дополнительно проверить на NULL:

SELECT 
	tbl_publication.id, tbl_publication.name, tbl_publications_media.media_url 
FROM tbl_publication 
LEFT JOIN tbl_publications_media ON tbl_publication.id = tbl_publications_media.publication_id 
WHERE article = 1 AND status = 1 AND (media_type IS NULL OR media_type = 3) 
ORDER BY id DESC LIMIT 9

Из вопроса делаем вывод что а) данных не много б) они уникальны для пользователя в) запрос простой.
200 000 * 15 = 3 000 000 000 запросов в день, учтем что подразумевается скорее всего рабочий день, пусть 8 часов, и нагрузка распределена примерно равномерно. 3М/8/60/60 = 104 запроса в секунду, пусть в пике загрузки это будет 300-400 запросов.
Думаю пока вам хватит даже без масштабирования ресурсов, в дальнейшем при необходимости можно ввести кеширование, правда я не уверен что оно даст большой прирост, так как:
1) Данные должны быть горячие, то есть кеш на такие данные должен быть короткий, а одинаковые запросы скорее всего сильно разнесены по времени, по этому кеш будет вечно протухшим.
2) Данные на "узкие" запросы вообще плохо кешируются, так как содержат не массив выборки, а 1 строку, то есть получается много мелких данных вместо 20-30 списков на много строк.

Вам нужны интеграторы:
payture.com
cloudpayments.ru

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

UPD: Ещё вариант (open-source): reversegeocode
Ещё один (open-source) gisgraphy (демка)