powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / можно ли с оптимизировать этот запрос?
8 сообщений из 58, страница 3 из 3
можно ли с оптимизировать этот запрос?
    #38687324
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tanglirmiksoft> Не может <...>
tanglir> <...>с чего бы вдруг? <...>
alexnews> нда согласен, не подумал

ЯНП... вроде бы клоны - это фишка ПТ и Арии51? И кто из нас чей клон? :)
...
Рейтинг: 0 / 0
можно ли с оптимизировать этот запрос?
    #38687351
Фотография alexnews
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tangliralexnews,

а если джойн после лефтджойна поставить? а то у вас сначала идёт джойн с s, а только потом она "объявляется"

спасибо сам как-то ступил

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
mysql> select count(TemplateID   > 0)  from daily_stats     left join zf_strategies on zf_strategies.userver_id = daily_stats.LineItemID 
    ->  JOIN zf_campaigns on zf_campaigns.id = zf_strategies.campaign_id  where day BETWEEN '2014-06-01' AND '2014-06-30'    and zf_campaigns.demand_type = 'exchange';
+-------------------------+
| count(TemplateID   > 0) |
+-------------------------+
|                 9449925 |
+-------------------------+
1 row in set (3 min 15.49 sec)



это похоже и есть затык
...
Рейтинг: 0 / 0
можно ли с оптимизировать этот запрос?
    #38687353
Фотография alexnews
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksofttanglirmiksoft> Не может <...>
tanglir> <...>с чего бы вдруг? <...>
alexnews> нда согласен, не подумал

ЯНП... вроде бы клоны - это фишка ПТ и Арии51? И кто из нас чей клон? :)
наверное я )
...
Рейтинг: 0 / 0
можно ли с оптимизировать этот запрос?
    #38687396
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexnewstangliralexnews,

а если джойн после лефтджойна поставить? а то у вас сначала идёт джойн с s, а только потом она "объявляется"

спасибо сам как-то ступил

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
mysql> select count(TemplateID   > 0)  from daily_stats     left join zf_strategies on zf_strategies.userver_id = daily_stats.LineItemID 
    ->  JOIN zf_campaigns on zf_campaigns.id = zf_strategies.campaign_id  where day BETWEEN '2014-06-01' AND '2014-06-30'    and zf_campaigns.demand_type = 'exchange';
+-------------------------+
| count(TemplateID   > 0) |
+-------------------------+
|                 9449925 |
+-------------------------+
1 row in set (3 min 15.49 sec)



это похоже и есть затык


пока не понятно , по какомоту из планов подсоединение
стратегий идет по индексу, по идее не должно ТАК
тормозить.

Идем дальше --

0. после каждого SELECT вставьте SQL_NO_CACHE
в тело запроса.

1. получите и выдайте ЕХПЛЕЙН на все 4 запроса.

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

Если память не забита но диск стучит -- есть шанс
ускорится увеличения каких-нибудь буферов.

3. А вообше -- какие требования? это
одиночный запрос или таких запросов по
5 каждую секунду?

4. Слышали ли вы слово "преагрегация" ?
...
Рейтинг: 0 / 0
можно ли с оптимизировать этот запрос?
    #38688536
Фотография alexnews
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
сегодня получил доступ к серверу и ужаснулся, как оказалось у них в конфиге вообще конь не валялся после моих исправлений данные с сервера:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
mysql> select count(TemplateID > 0)  from daily_stats;
+-----------------------+
| count(TemplateID > 0) |
+-----------------------+
|              10391655 |
+-----------------------+
1 row in set (0.00 sec)

mysql> EXPLAIN select count(TemplateID > 0)  from daily_stats;
+----+-------------+-------+------+---------------+------+---------+------+------+------------------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra                        |
+----+-------------+-------+------+---------------+------+---------+------+------+------------------------------+
|  1 | SIMPLE      | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL | Select tables optimized away |
+----+-------------+-------+------+---------------+------+---------+------+------+------------------------------+
1 row in set (0.00 sec)



Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
mysql> select count(TemplateID > 0)  from daily_stats where day BETWEEN '2014-06-01' AND '2014-06-30';
+-----------------------+
| count(TemplateID > 0) |
+-----------------------+
|               9316793 |
+-----------------------+
1 row in set (2.76 sec)

mysql> EXPLAIN select count(TemplateID > 0)  from daily_stats where day BETWEEN '2014-06-01' AND '2014-06-30';
+----+-------------+-------------+------+--------------------+------+---------+------+----------+-------------+
| id | select_type | table       | type | possible_keys      | key  | key_len | ref  | rows     | Extra       |
+----+-------------+-------------+------+--------------------+------+---------+------+----------+-------------+
|  1 | SIMPLE      | daily_stats | ALL  | un_daily_stats,Day | NULL | NULL    | NULL | 10391655 | Using where |
+----+-------------+-------------+------+--------------------+------+---------+------+----------+-------------+
1 row in set (0.00 sec)




Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
mysql> select count(TemplateID > 0)  from `daily_stats` `d`  left join `zf_strategies` `s` on `s`.`userver_id` = `d`.`LineItemID` where day BETWEEN '2014-06-01' AND '2014-06-30';
+-----------------------+
| count(TemplateID > 0) |
+-----------------------+
|               9316793 |
+-----------------------+
1 row in set (20.87 sec)

mysql> EXPLAIN select count(TemplateID > 0)  from `daily_stats` `d`  left join `zf_strategies` `s` on `s`.`userver_id` = `d`.`LineItemID` where day BETWEEN '2014-06-01' AND '2014-06-30';
+----+-------------+-------+------+---------------------------+---------------------------+---------+------------------+----------+-------------+
| id | select_type | table | type | possible_keys             | key                       | key_len | ref              | rows     | Extra       |
+----+-------------+-------+------+---------------------------+---------------------------+---------+------------------+----------+-------------+
|  1 | SIMPLE      | d     | ALL  | un_daily_stats,Day        | NULL                      | NULL    | NULL             | 10391655 | Using where |
|  1 | SIMPLE      | s     | ref  | idx_strategies_userver_id | idx_strategies_userver_id | 4       | lfx.d.LineItemID |        1 | Using index |
+----+-------------+-------+------+---------------------------+---------------------------+---------+------------------+----------+-------------+
2 rows in set (0.00 sec)






Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
mysql> select count(TemplateID   > 0)  from daily_stats     left join zf_strategies on zf_strategies.userver_id = daily_stats.LineItemID  JOIN zf_campaigns on zf_campaigns.id = zf_strategies.campaign_id  where day BETWEEN '2014-06-01' AND '2014-06-30'    and zf_campaigns.demand_type = 'exchange';
+-------------------------+
| count(TemplateID   > 0) |
+-------------------------+
|                 9122191 |
+-------------------------+
1 row in set (28.33 sec)

mysql> EXPLAIN select count(TemplateID   > 0)  from daily_stats     left join zf_strategies on zf_strategies.userver_id = daily_stats.LineItemID  JOIN zf_campaigns on zf_campaigns.id = zf_strategies.campaign_id  where day BETWEEN '2014-06-01' AND '2014-06-30'    and zf_campaigns.demand_type = 'exchange';
+----+-------------+---------------+--------+-----------------------------------------------------+------------+---------+-------------------------------+-------+-------------+
| id | select_type | table         | type   | possible_keys                                       | key        | key_len | ref                           | rows  | Extra       |
+----+-------------+---------------+--------+-----------------------------------------------------+------------+---------+-------------------------------+-------+-------------+
|  1 | SIMPLE      | zf_strategies | ALL    | idx_strategies_userver_id,fk_strategies_campaign_id | NULL       | NULL    | NULL                          | 21305 |             |
|  1 | SIMPLE      | zf_campaigns  | eq_ref | PRIMARY                                             | PRIMARY    | 96      | lfx.zf_strategies.campaign_id |     1 | Using where |
|  1 | SIMPLE      | daily_stats   | ref    | un_daily_stats,Day,LineItemID                       | LineItemID | 4       | lfx.zf_strategies.userver_id  |   116 | Using where |
+----+-------------+---------------+--------+-----------------------------------------------------+------------+---------+-------------------------------+-------+-------------+
3 rows in set (0.00 sec)



добавил NO_SQL_CACHE, время не изменилось. Извиняюсь за тупой вопрос а что SQL кэширует запросы? И есть вероятность когда данные изменились нарваться на закэшированные данные?





javajdbc
Идем дальше --

0. после каждого SELECT вставьте SQL_NO_CACHE
в тело запроса.


сделал но изменений по скорости не заметил или это для другого делалось?


javajdbc1. получите и выдайте ЕХПЛЕЙН на все 4 запроса.

выше вывел

javajdbc
2. поставьте любой "реального-времени" монитор
памяти и обрашений к диску.
Внимательно проследите, нет ли резкого увелкичения
обрашения к диску во время последнего запроса
при максимальном забитии памяти.
Один из вариантов тормозов -- запрос вывалился
из памяти на диск -- просто по размеру выборки.

Если память не забита но диск стучит -- есть шанс
ускорится увеличения каких-нибудь буферов.


можно мне подсказать что лучше всего использовать под CentOS 6.5?

javajdbc
3. А вообше -- какие требования? это
одиночный запрос или таких запросов по
5 каждую секунду?


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


javajdbc4. Слышали ли вы слово "преагрегация" ?
до вас не слышал, но почитал вас в соседней ветке - крутая идея посоветую программерам сделать. Спасибо.
...
Рейтинг: 0 / 0
можно ли с оптимизировать этот запрос?
    #38688539
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OK, по запросам вроде бы все как было, кроме последнего --
скорость вроде улучшилась с 3 минут до 20 секунд.
Разко изменился ЕХПЛЕЙН --- теперь на первом месте zf_strategies
с 21К записей а даили_статс на последнем месте.

(люди добрые, скажите а бывает таблица которая первая и слева от лефт жоина
оказатся последней в Експлейне? или сервер у ТС чудит? или
копи-пасте плохо работает ? а был ли LEFT ?)


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
mysql> EXPLAIN select count(TemplateID   > 0)  from daily_stats     left join zf_strategies on zf_strategies.userver_id = daily_stats.LineItemID  JOIN zf_campaigns on zf_campaigns.id = zf_strategies.campaign_id  where day BETWEEN '2014-06-01' AND '2014-06-30'    and zf_campaigns.demand_type = 'exchange';
+----+-------------+---------------+--------+-----------------------------------------------------+------------+---------+-------------------------------+-------+-------------+
| id | select_type | table         | type   | possible_keys                                       | key        | key_len | ref                           | rows  | Extra       |
+----+-------------+---------------+--------+-----------------------------------------------------+------------+---------+-------------------------------+-------+-------------+
|  1 | SIMPLE      | zf_strategies | ALL    | idx_strategies_userver_id,fk_strategies_campaign_id | NULL       | NULL    | NULL                          | 21305 |             |
|  1 | SIMPLE      | zf_campaigns  | eq_ref | PRIMARY                                             | PRIMARY    | 96      | lfx.zf_strategies.campaign_id |     1 | Using where |
|  1 | SIMPLE      | daily_stats   | ref    | un_daily_stats,Day,LineItemID                       | LineItemID | 4       | lfx.zf_strategies.userver_id  |   116 | Using where |
+----+-------------+---------------+--------+-----------------------------------------------------+------------+---------+-------------------------------+-------+-------------+
3 rows in set (0.00 sec)



В любом случае это показывает что переспектива есть
лишние LEFT конкретно мешают. Одна из версий --
был перебот 20К записей на 100 записей -- 2 млн,
что меньше чем 9 МЛН прямого перебора и запрос
не вывалился из памяти.
...
Рейтинг: 0 / 0
можно ли с оптимизировать этот запрос?
    #38688540
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> добавил NO_SQL_CACHE, время не изменилось.

Это обеспечивает валидность тестов против кеширования

>> Извиняюсь за тупой вопрос а что SQL кэширует запросы?

Да.

>> И есть вероятность когда данные изменились нарваться на закэшированные данные?

Нет.

>> ........ поставьте любой "реального-времени" монитор
>> можно мне подсказать что лучше всего использовать под CentOS 6.5?

> yum install htop
> htop
> yum install iotop
> iotop -o
> yum install sysstat
> iostat 3

ну или спросить местного сисадмина.

если охота в настройках покапатся, то:

> wget http://mysqltuner.com/mysqltuner.pl
> chmod +x mysqltuner.pl
> ./mysqltuner.pl

(осторожно, настройками можно поламать сервер!)
...
Рейтинг: 0 / 0
можно ли с оптимизировать этот запрос?
    #38688541
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> [скрипт] ....одиночный но работал на сервере 9 часов, сейчас не знаю сколько будет так как изменения сделал недавно а скрипт запуститься через несколько часов да и то я не узнаю так как выходные а я новенький и не знаю даже откуда их скрипт отчета запускается

посмотрите , включен ли slow-query-log,
скорее всего ваш запрос туда попадет и вы сможете
полюбоватся какая была скорость даже через несколько дней.

>>>>4. Слышали ли вы слово "преагрегация" ?
>> до вас не слышал, но почитал вас в соседней ветке - крутая идея посоветую программерам сделать. Спасибо.

Всегда пожалуйста!
...
Рейтинг: 0 / 0
8 сообщений из 58, страница 3 из 3
Форумы / MySQL [игнор отключен] [закрыт для гостей] / можно ли с оптимизировать этот запрос?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]