ThunderCat

`dialog_id` int(16) NOT NULL, - 16 отображаемых знаков - тут вроде не должно быть так, там может быть максимум (11) при int, и емнип в любом случае размер отводимой памяти будет 4 байта. Если вы планируете хранить более 4 миллиардов записей используйте bigint.

если вы мечтаете что из запроса магическим образом вернется готовый массив в таком виде, то никак. Запросы выдают одномерные массивы.

Можно выбрать так:

SELECT id, `product`.title, `product`.typeID, `type`.title, 
type`.typeID  type_typeID, type`.title  type_ttitle
FROM `product` 
LEFT JOIN `type` 
on `product`.typeID=`type`.typeID 
where `product`.typeID=1

после чего уже в коде по _ разбить в нужный формат.

Я бы не стал заморачиваться с поиском лучшего решения на пустом месте, если бы лучшая бд существовала, остальные бы умерли в неизвестности. В вашем случае я бы использовал MySQL, как минимум на начальном этапе, и вот почему:
1) Это бесплатно
2) Мускуль - хороший добротный середнячек своего класса, то есть он умеет почти все и при этом сильно не проседает по производительности.
3) На него ОГРОМНОЕ количество доков и юзеркейсов, а так же туториалов и советов по оптимизации в конкретную задачу.
4) При смене бд(если таковая понадобится) вам, скорее всего, придется только поменять драйвер бд(при условии грамотной архитектуры) и аккуратно перенести дамп базы.
5) Про MSSQL - до недавнего времени в ней не было нативной поддержки UTF-8, вместо нее была(и есть еще вроде) своя UCS, которая мультибайт, но какой-то свой(как всегда у мс), в свое время в угоду "скорости" ставили сервак с мсскулем, в итоге практически никакого прироста не получили, зато получили гемор с переводом кодировок.
6) Если проект реально нуждается в разрывном бд на пределе современных возможностей - смотрите в сторону инмемори бд, например тарантул или что-то носкюельное, типа редис и иже с ним.

Like не работает

в каком смысле не работает? У вас не работает или выключена(как?) возможность использования?

1) * parent_id
2) нестед сидс проще реализовать на клиенте

Так а вопрос то в чем?
1)Не хватает ресурсов - покупаем мощности сервера,
2) не хватает данных - запрашиваем чаще,
3) опять не хватает мощности - см. п. 1.

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

function put_ten() {
  global $link;
  $query = "SELECT `item`.`id`, `item`.`name`, `item`.`cat1`, 
                `item`.`cat2`, `item`.`cat3`, `item`.`cat4`, 
                `item`.`price`, `img`.`source`, `param`.`name` pname, `param`.`value` pvalue
          FROM `item` 
          JOIN `img` 
          ON `item`.`id` = `img`.`item_id` 
          JOIN `param` 
          ON `item`.`id` = `param`.`item_id` 
          WHERE `item`.`inserted` = 0 
          LIMIT 1000";
// дальше 1 циклом нормально пройтись
}

UPD: Без индексов было... БЕЗ ИНДЕКСОВ, КАРЛ!!! Как так то?

Я выбираю из выпадающего списка вывод данных по-популярности, по-жанрам, по-годам, и по-странам.

Как и написали в коментах - ORDER BY `поле_сортировки`

Но до сортировки должны выводиться всё данные.

можете просто не указывать метод сортировки, но тогда у вас будет все кучей, никакого внятного порядка вывода не будет. И бтв - сортировка не повлияет на вывод всех/не всех данных, для этого есть другие операторы - LIMIT, WHERE и т.д.

Если не трудно напишите пример кода)

не трудно, но:
во первых это запрещено правилами ресурса(можно было и почитать условия при подаче вопроса),
во вторых конкретно ваша реализация не будет подходить под чей либо чужой код, никто кроме вас не знает ни структуры хранения данных в вашей бд, ни кода который все это обрабатывает.

$sql_img = $db->super_query("SELECT * FROM imgtop limit 2", true);
print_r($sql_img);
exit;

что показывает?

Выводит так массив
Array ( [0] => Array ( [id] => 1 [name] => slider_1.jpg ) [1] => Array ( [id] => 2 [name] => slider_2.jpg ) )

sandbox.onlinephpfunctions.com/code/9f43dc6039aa53...
результат:

<li  style="background-image: url(/img/slider_1.jpg);" class="overlay"></li> <li  style="background-image: url(/img/slider_2.jpg);" class="overlay"></li>

кто -то пиз... трындит, и скорее всего не интерпретатор )

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

Плюс - скорость и все плюшки кейвалуе.

Минус - кейвалуе и все похерится в случае факапа с выключением/перезагрузкой сервера сервера.

для начала - учите синтаксис и PSR, который не просто так придуман.

foreach($sql_img as $q) //здесь должна быть открывающая { 
  $img .= '<li  style="background-image: url({theme}/img/'.$sql_img['name'].');" class="overlay"></li> ';
// тут у вас цикл закончился и вернулся к новой итерации, это равноценно закрывающей }
// а так же нахрена вам $q если вы обращаетесь к $sql_img? и нахрена тогда вообще цикл? 
$tpl->set('{img}', $img); // тут вы получили элемент массива $sql_img['name'] в каждой строчке. соответственно будет одна картинка.

php.net/manual/ru/function.password-hash.php

мне нужно сделать для друга сайт, который бы мог вести только он один имея доступ к добавления картинок и текста

wordperss?

1) Оверхед при хранении в базе64 порядка 30%. то есть + 30% к траффику, а учитывая п. 2 - еще больше.
2) Кеш браузера не работает с базе64 картинками(и замечательно работает с картинками в файлах).
3) Файлы храните в файлах.
4) Жметесь на количество файлов и место - граватар.

https://github.com/fadlee/bigdump

Пособие по преодолению проблем "ничего не работает":
1) Разбить задачу на шаги(сначала на крупные, потом на более мелкие если необходимо)
в вашем случае есть 1) запрос, который "должен"(нет) выбирать несколько строк. Идем в консоль или в пхпмайадмин и прописываем там запрос напрямую. Если запрос возвращает 1 запись - идем учить синтаксис SQL.
2) Если проблема не в запросе - есть вардамп для результата вывода из функции, которая работает с бд, возможно вы используете не то что надо - идем читать про ваш адаптер бд и функции из него.
3) Получаем объект - как и что происходит тут - загадка, проверяйте что вы скармливаете на входе, смотрите где теряются данные по ходу алгоритма, что получаете на выходе.
Хинт: var_dump(), print_r();