Максим Федоров

SELECT category FROM table_category WHERE id in (SELECT id_category FROM table_users WHERE id = 2)

UPDATE product
LEFT JOIN (SELECT id_products, name_product FROM newProduct) as np ON np.id_product = product.id_product
SET product.name_product = np.name_product

как-то так

INSERT INTO {tablename} (date, num) VALUES ('2016-07-06') ON DUPLICATE KEY UPDATE num = num + 1

Если исходить из логики что категория активна когда хоть один товар в ней активный, тогда Ваш запрос переформировать без использования count, например так:

UPDATE ps_category SET active = '0' WHERE level = 3 AND id NOT IN (
	SELECT DISTINCT(id_category) FROM ps_category_product IN 
		(SELECT id_product FROM ps_product WHERE active = '1')
)

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

1. У Вас за принятие заказа отвечает экшен TakeOrder а ссылка "принять" ведет на Index, сейчас так:

<?= Html::a('Принять', ['orders/index','value' => ($orders->id)], ['class'=>'btn btn-primary']) ;?>

а должно быть так

<?= Html::a('Принять', ['orders/take-order','value' => ($orders->id)], ['class'=>'btn btn-primary']) ;?>

2. Вы не верно обрабатываете параметр value из GET
сейчас:
$get = $request->get(value);
должно быть:
$get = $request->get('value');

P.S. гет параметры можно получать не обращаясь к объекту request, для этого достаточно объявить его в самом методе экшене, например так:
public function actionTakeOrder($value) {}

SELECT cat1.id, cat1.cat_name, cat1.cat_url, cat1.parent, cat2.name as parent_name  
FROM `categories` AS cat1 
LEFT JOIN `categories` AS cat2 ON cat2.id = cat1.patent
WHERE cat1.`cat_url` = <значение>

SELECT `id`, `date`, `status` FROM `table`
WHERE uid IN (1,2,3,4,5) AND (
(reg=1 AND date_last < NOW() - INTERVAL 1 DAY) OR (reg=2 AND date_last < NOW() - INTERVAL 2 DAY)
OR (reg=3 AND date_last < NOW() - INTERVAL 3 DAY))

не знаю что такое reg но если это кол-во дней тогда можно написать так:

SELECT `id`, `date`, `status` FROM `table` WHERE uid IN (1,2,3,4,5) AND date_last < NOW() - INTERVAL reg DAY

привести на строне mysql?

SELECT * FROM offers WHERE `name` = CONVERT(123, char)

хотя если не ошибаюсь то MySQL при запросе
select * from table where uid=123
не выдаст ошибку, а найдет записи. Правда если у Вас записи будут вида "123", "123abcd", "456" то он вернет две записи и "123" и "123abcd",

UPDATE wp_postmeta SET wp_value = 'значение'

Если правильно понял задачу

$result = mysql_query("SELECT id FROM account WHERE login='$login' AND mail='$email' AND activation='1' AND login IN (SELECT login FROM char WHERE name='$name')",$db);

так а чем не устраивает текущий вариант? Архитектурно это правильный подход. Если не устраивает скорость, можно опуститься на уровень БД и реализовать там триггер, но стоит ли...

У каждой записи Вы можете хранить информацию о ее дате/времени добавления/изменения (в UTC естественно). Так же Вы можете где-нибудь фиксировать дату/время посещения пользователем списка статей (тоже естественно в UTC). В таком случае при повторном посещении сайта можно просто сделать соответствующую выборку по дате.
Ну а где хранить дату посещения - это уже зависит от специфики Вашего сайта, можно в куках, можно где-нибудь в базе.

< select name="polling"> //выпадающее меню, которое забивается массивом
<?php while($item = $sql->fetch()):?>
<option><?=$item['str_code'];?></option>
<?php endwhile;?>
< /select>

Делать в цикл запросы к базе - очень плохо, т.к. нагрузки повышаются из пустого места, лучше:
если необходимо выбрать только города (без регионов):
SELECT * FROM cities
если необходимо выбрать только города, относящиеся к определенным регионам:

SELECT *
FROM cities
WHERE region_id IN (1, 2, 3)

если необходимо выбрать информацию и по городам и по регионам:

SELECT cities.*, regions.* FROM cities
LEFT JOIN regions ON regions.id = cities.region_id

ну и не стоит забыть что информация о городах/регионах обновляется очень редко, поэтому стоит закешировать эту информацию

Сложно ответить на вопрос не имея никаких данных.
Максимум что можно порекомендовать сейчас это ознакомится с ruseller.com/lessons.php?id=692

лучше хранить только ссылку на фотографию - это более гибко и оптимальнее по производительности. Приведу простой пример: допустим нужно вывести информацию о 30 пользователях списком с фотографиями, если использовать ссылки вот что мы получим:
1. У нас будет возвращать из базы минимальный объем данных (блоб поля сильно увеличивают вес записи)
2. Мы сможем при необходимости удобно сортировать, выбирать данные по URL, в отличии от BLOB
3. В случае веб-ресурса - мы сможем кешировать картинки, blob-поле полноценно этого не позволит зделать
4. Опять таки в случае веб-ресурса, мы можем разместить эти картинки на 100500 серваках, что бы распределить нагрузку, (а blob этого не позволит сделать)