AlikDex

https://dev.mysql.com/doc/refman/5.7/en/insert-on-...

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

SELECT DATE(FROM_UNIXTIME(`created_at`)) AS `dt`, COUNT(`id`) AS `cnt`
FROM `account_analytics`
WHERE `created_at` > UNIX_TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 6 DAY))
GROUP BY DATE(FROM_UNIXTIME(`created_at`));

Не проверял, не знаю работает или нет, но думаю ход мысли понятен.
Либо может GROUP BY `dt` сработает, чтоб не считать снова.
Для аккаунта тож самое будет, тока с указанием ида аккаунта во WHERE,

И для именно этого случая я бы делал колонку created_at не timestamp, а полноценной datetime и юзал мускульные функции без преобразований. Это проще намного, хоть и немного затранее по памяти.

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

SELECT `brand_id`, `brand_name`
FROM `brands`
WHERE `brand_id` IN (1,3,4,7);

и выводишь их на странице как-то так:

$brand_id = $product['brand_id'];
if (isset($brand[$brand_id])) { // $brand - массив брендов [id][title] из второго запроса
    echo htmlspecialchars($brand[$brand_id]['brand_name']);
}

Если брендов не много(пару сотен), можно их все дернуть одним запросом и закешировать в нужном виде.

Насколько я понял нужна выборка по месяцу? Как-то так.

SELECT @dt:=EXTRACT(YEAR_MONTH FROM '2016-12-01'); -- Дополнить вашу дату до полного формата
SELECT id, reg_num, reg_date, Theme, List_doc, List_add, Contractor, type_send, Send_date 
FROM registry
WHERE EXTRACT(YEAR_MONTH FROM reg_date) = @dt AND EXISTS(SELECT `letterId` FROM `recipients` WHERE letterId = registry.id LIMIT 1)
ORDER BY reg_num ASC

Поскольку с реципиента вы ничего не выбираете, значит можно проверить просто его существование. Тогда отпадает необходимость в группировке.
и отдельный индекс по reg_num
Также проверить индекс на reg_date Чот судя по експлейну его нет =)

не будет браться из кеша, т.к. запрос другой. Мускул кеширует по строке запроса, т.е. она должна быть идентичной абсолютно. Но также принимаются во внимание некоторые функции. Например запросы с функцией NOW() не кешируются вообще.

если коротко, то одним запросом выбрать все явно не прочитанные. Т.е. выбираем только те, которые присутствуют во второй таблице через RIGTH JOIN ... ON A.Key=B.Key. А другим запросом используя юнион олл, и выбираем все явно прочитанные, через конструкцию RIGTH JOIN ... WHERE A.Key IS NULL, таким образом исключая дубли и два запроса останутся быстрыми

1) Проверьте селективность запроса (гугл в помощь).
Вероятнее всего будет лучше сделать (т.к. компаний скорее всего меньше чем чеков):

SELECT * FROM `warehouses_changes` WHERE (`company`=1) AND (`bill`=0)  ORDER BY `date` DESC LIMIT 20;

2)Удалите текущий индекс, и для этого запроса сделайте:

CREATE INDEX warehouses_changes_date_bill_company ON warehouses_changes (company, bill, date);

И у вас запрос будет занимать меньше половины секунды. Возможно даже тысячные доли секунды.

Подсказка: Индекс следует делать именно в том порядке, в котором делаете выборку данных. Т.е. первым параметром у вас стоят компании - следовательно в индексе должно стоять первым колонка company, потом чек и сортировка `date`.

while ($row = mysql_fetch_array($result)) {
   $arr[$row['user_id']][] = array( $row['name'] =>  $row['value']);
}

Второй вариант:

while ($row = mysql_fetch_array($result)) {
    foreach ($row as $key=>$value)
        $arr[$row['user_id']][] = array($key =>  $value);
}

SELECT * 
FROM counts AS c 
LEFT JOIN operation AS o ON (c.count_id=(
   SELECT operation_count_id 
   FROM operation 
   ORDER by date
   LIMIT 1) o
)

В случае, если ид = всегда последняя дата (т.е. порядок никогда не нарушается) можно сделать так:

SELECT * 
FROM counts AS c 
LEFT JOIN operation AS o ON (c.count_id=(
   SELECT MAX(operation_count_id) 
   FROM operation) o
)

upd: скобочку неправильно поставил.

памятуя прошлый вопрос данного пользователя, скажу следующее:
Да, для каждой статьи нужна своя таблица с лайками :D
Всех благ =)

используйте PDO

3 дня тестов привели к такому. Смотрите внизу. Схема ровно такая же как у вас.
Как грамотно связать посты и категории (товар и категории, если угодно)?
Запросы, что предложили товарищи в теме тут будут очень медленные при большом количестве книг.

На некотором этапе может статься так, что проще будет сделать 2 запроса на пост, чем вот такое городить.