Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
Запрос: Код: sql 1. 2. 3. EXPLAIN: idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLEcdrrangecalldate dst dstchanneldst242NULL9878Using where Почему оно не использует Код: sql 1. ? И как сделать запрос более быстрым? Результат 1 строка. Таблица: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2017, 16:44 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
1. какая скорость сейчас? измерьте 3 раза используя SQL_NO_CACHE Типа: select SQL_NO_CACHE * from cdr WHERE cdr.calldate > '2017-10-06'.................... 2. какую скорость вы хотите? 3. Ехплаин говорит что DIS индекс используется. Т.е. ситуация не "невидит индекс" а "невидит индекс который я (почему-то) хочу чтоб mysql использовал" 4. cdr.dst like '0747' можно заменить на cdr.dst = '0747' 5. чтоб разобратся с индексами, надо "профилировать" данные, кардиналити, разброс, конкретные выборки... Для начала выдайте результат такого запроса: select count(1) cnt1, count( cdr.calldate > '2017-10-06') cnt2, count(cdr.dst = '0747') cnt3, count(cdr.dstchannel = 'SIP/0747-00001746') cnt4, from cdr ; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2017, 17:10 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
1. 0,7 секунды. 2. хочу 0,2 хотя бы 3. Ну да но я ж индекс прям по всем полям поиска ему дал, что не так то... 4. Да там и был =, не то написал из-за разных проб запросов, оно не влияет на результат 5. cnt1cnt2cnt3cnt43858473385847338584733858473 Ну в самом деле у меня проблема вот какая, а это я как упрощенный вариант показал :) Запрос Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. EXPLAIN idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1PRIMARYqueue_logrefEvent Time Data1Event97const200Using where1PRIMARYcdrrangecalldate dst dstchanneldst242NULL30976Using where2UNIONcdrrangecalldate dst dstchanneldst242NULL30976Using where2UNIONqueue_logrefEven Time Data1Event97const200NULLUNION RESULT<union1 2>ALLNULLNULLNULLNULLNULL Таблица queue_log не большая и тормознутости не дает, а вот CDR 2гига уже. И вот этот большой запрос выполняется под 54 секунды.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2017, 17:26 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
по поводу кардиналити: TABLE_CATALOGTABLE_SCHEMATABLE_NAMENON_UNIQUEINDEX_SCHEMAINDEX_NAMESEQ_IN_INDEXCOLUMN_NAMECOLLATIONCARDINALITYSUB_PARTPACKEDNULLABLEINDEX_TYPECOMMENTNULLasteriskcdrdbcdr1asteriskcdrdbcalldate1calldateA3821260NULLNULLBTREENULLasteriskcdrdbcdr1asteriskcdrdbdst1dstA127375NULLNULLBTREENULLasteriskcdrdbcdr1asteriskcdrdbaccountcode1accountcodeA17NULLNULLBTREENULLasteriskcdrdbcdr1asteriskcdrdbuniqueid1uniqueidA3821260NULLNULLBTREENULLasteriskcdrdbcdr1asteriskcdrdbdid1didA17NULLNULLBTREENULLasteriskcdrdbcdr1asteriskcdrdbdstchannel1calldateA3821260NULLNULLBTREENULLasteriskcdrdbcdr1asteriskcdrdbdstchannel2dstA3821260NULLNULLBTREENULLasteriskcdrdbcdr1asteriskcdrdbdstchannel3dstchannelA3821260NULLNULLBTREENULLasteriskcdrdbqueue_log1asteriskcdrdbEvent1eventA18NULLNULLYESBTREENULLasteriskcdrdbqueue_log1asteriskcdrdbTime1timeA518934NULLNULLYESBTREENULLasteriskcdrdbqueue_log1asteriskcdrdbData11data1A664NULLNULLYESBTREE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2017, 18:42 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
TimofeySin, ...попробуйте поменять порядок полей в индексе -- если на первом месте поле по которому идет ">" ренже -- ето хуже чем на первом месте поле в БОЛЬШОЙ кардинальностью. лучше всего -- уникальние поле первым (или даже единственым)... ...трудно анализировать унион -- выдайте подробности (екплейн) самого медленого из двух юнионов.... ....если вы уверены в индексе -- посмотрите как ФОРСИРОВАТЬ индекс -- есть хинты типа USE INDEX, FORCE INDEX.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2017, 19:23 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
TimofeySinПочему оно не использует Код: sql 1. И не будет. Какая разница - фуллскан таблицы или индекса? Убери из индекса calldate или поставь его последним - тогда будет использоваться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2017, 19:36 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
Да там если убить второй запрос ничего толком не меняется. Всмысле сам юнион ничего не ест, жрут запросы почти идентичные. idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLEqueue_logrefEvent Time Data1Event97const200Using where1SIMPLEcdrrangecalldate dst dstchanneldst242NULL30976Using where про юз индекс не знал, спасибо. Стало понятно почему sql выбрал этот индекс :), остался ток вопрос, как ускорить это всё.. Меня убивает что "rows" в эксплейне 30976, а в реалии выдает 240. Я как понял у меня получается 200*30976 операций сравнения и из-за этого и тормоза такие... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2017, 19:37 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
TimofeySinМеня убивает что "rows" в эксплейне 30976, а в реалии выдает 240.Есть результат, а есть оценка результата без получения самогО результата. Ошибка на два порядка - вполне возможна, особенно если статистика неактуальна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2017, 19:39 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
TimofeySinДа там если убить второй запрос ничего толком не меняется. Всмысле сам юнион ничего не ест, жрут запросы почти идентичные. 1. из общих соображений , пожалуйста, уточняйте что к чему относится. 2, конкретно: >> жрут запросы почти идентичные два запроса в юнион имеет разную бизнесс логику и разную логику запроса. Скорее всего и оптимизация (если возможна) будет разная. 3. селект 1: "LOG left join CDR" сначало надо оптимизировать филтрацию по ЛОГ. Что за индекс "Event"?. Сколько записей дает: select count(1) from`queue_log` WHERE `queue_log`.`queuename` = 'Programmist_queue' AND (`queue_log`.`event` = 'REMOVEMEMBER') AND (`queue_log`.`data1` <> '') AND (`queue_log`.`time` > '2017-10-06')) 4. Селект-1. Что бы помочь оптимизатору, можно переписать селект указав полную выборку из ЛОГа в явном виде, типа: SELECT RIGHT(`queue_log`.`agent`,4) AS `Агент` ,`queue_log`.`data1` AS `ВходВГруппу` ,`queue_log`.`time` AS `ВыходИзГруппы` , TIME_TO_SEC(TIMEDIFF(`queue_log`.`time`, IF((`queue_log`.`data1` = ''),`queue_log`.`time`,`queue_log`.`data1`))) AS `ВремяВГруппе` ,`cdr`.`uniqueid` AS `ИДРазговора` ,`cdr`.`src` AS `Абонент` , IFNULL(`cdr`.`calldate`,'0000-00-00') AS `ВремяНачала` ,`cdr`.`end` AS `времяОкончания` ,`cdr`.`billsec` AS `ВремяРазговора` , SUBSTR(`cdr`.`dstchannel` ,(LOCATE('/',`cdr`.`dstchannel`) + 1),4) AS `АгентCDR` ,`cdr`.`disposition` AS `Статус` FROM ( select * from`queue_log` WHERE `queue_log`.`queuename` = 'Programmist_queue' AND (`queue_log`.`event` = 'REMOVEMEMBER') AND (`queue_log`.`data1` <> '') AND (`queue_log`.`time` > '2017-10-06')) ) LOG2 LEFT JOIN `cdr` ON (((SUBSTR(`cdr`.`dstchannel`,5,4) = RIGHT( LOG2 .`agent`,4)) AND (IFNULL(`cdr`.`calldate`,'0000-00-00') >= LOG2 .`data1`) AND (IFNULL(`cdr`.`calldate`,'0000-00-00') <= LOG2 .`time`) AND (`cdr`.`dst` LIKE '07%') AND (`cdr`.`calldate` > '2017-10-06')))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 01:21 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
5. Select-1. разбор связки LEFT JOIN `cdr` ON (((SUBSTR(`cdr`.`dstchannel`,5,4) = RIGHT(LOG2.`agent`,4)) dstchannel -- полностью выпадает из рассмотрения для индекса ибо применяется финкция Возможное улучшение: создание нового поля CDR.AGENT и заполнить его значением SUBSTR(`cdr`.`dstchannel`,5,4) при инсерте. И включить (парвильно включить!) CDR.AGENT в индекс AND (IFNULL(`cdr`.`calldate`,'0000-00-00') >= LOG2.`data1`) AND (IFNULL(`cdr`.`calldate`,'0000-00-00') <= LOG2.`time`) ранже >< после IFNULL -- скорее всего индекс не будет рассматроватся Возможное улучшение: заменить NULL на '0001-01-01' на вставке и убрать ИФНУЛЛ из запроса (дабaвка, у вас calldate NOT NULL DEFAULT '000...', зачем IFNULL ????????) AND (`cdr`.`dst` LIKE '07%') может быть рассмотрен в индексе, вопрос в селективности 07% Что дает запрос: select count(1) from CDR where `dst` LIKE '07%' если меньше чем 200К -- можно попробовать индекс НАЧИНАЮШИЙСЯ с DST. AND `cdr`.`calldate` > '2017-10-06' Что дает запрос: select count(1) from CDR where `cdr`.`calldate` > '2017-10-06' у вас запросы всегда за последний день? если нет то можно ли ограничится запросами за ОДИН день? Если "да' на любой вопрос выше, то можно добавить CDR.CallDateDate и хранить DATE,а потом использовать "=" в поиске. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 01:40 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
6. Селект-1. Обратно к ЛОГ -- сейчас посмотрел -- там тоже нехило пол милиона записей. Т.е. нужно отработать ету часть серьезно. Индекс EVENT имеет низкую кардинальность 18. Можно попробовать добать время как ВТОРОЕ поле. Для експеримента, отдельно, можно попробовать время как ПЕРОВ (и единственое) поле в индексе. ( https://dev.mysql.com/doc/refman/5.7/en/range-optimization.html) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 01:51 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
...кстати, без относительно всего -- сделайте OPTIMIZE TABLES ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 01:53 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
7. Selekt-2. опятже, сначала ОТДЕЛЬНО надо рассмотреть запрос по CDR select * from CDR WHERE `cdr`.`dst` LIKE '07%' AND `cdr`.`calldate` > '2017-10-06' AND `cdr`.`dstchannel` <> '' dst и calldate -- рассмотреть тоже самое что и для Селект-1 dstchannel тут не интересно 8. Селект-2 Связка на ЛОГ LEFT JOIN `queue_log` ON (((SUBSTR(`cdr`.`dstchannel`,5,4) = RIGHT(`queue_log`.`agent`,4)) Если есть возможность -- добавьте поле , которое заполняйте при вставке `queue_log`.`agent2` = RIGHT(`queue_log`.`agent`,4) Может получится (или нет, без гарантий) хороший селективный индех AND (IFNULL(`cdr`.`calldate`,'0000-00-00') >= `queue_log`.`data1`) AND (IFNULL(`cdr`.`calldate`,'0000-00-00') <= `queue_log`.`time`) Убрать IFNULL. Дата1 и Тиме могут быть частью индекса (или одиночным индексом) AND (`queue_log`.`queuename` = 'Programmist_queue') select count(1) from log where `queuename` = 'Programmist_queue' ??? AND (`queue_log`.`event` = 'REMOVEMEMBER') select count(1) from log where `event` = 'REMOVEMEMBER' ??? AND (`queue_log`.`data1` <> '') AND (`queue_log`.`time` > '2017-10-06')))) ..вообшето уже была такая обрезка в CDR, зачем повторять? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 02:05 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
...если вовсем скучно будет, то можно будет занятся другими улучпшениями, типа обрезка старых записей, вынесение некоторых полей в смежные таблицы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 02:07 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
TimofeySinЗапрос: select * from cdr WHERE cdr.calldate > '2017-10-06' and cdr.dst like '0747' AND cdr.dstchannel = 'SIP/0747-00001746' Почему оно не использует Код: sql 1. ? И как сделать запрос более быстрым? Результат 1 строка. индекс должен быть для этого запроса INDEX `dstchannel` ( `dstchannel`, `dst`,`calldate` ) r] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 09:26 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
javajdbc, 3) идекс евент: там в 3 посте кардигалити есть по таблицам, у евента 18. 4) переписать с вложенным запросом незя, я хоху вьюху сделать такую, а mysql не разрешает вложенные. 5) Ifnull во втором запросе и правда можно убрать, а в первым нельзя, он из-за соединения появляется. По поводу условия '2017-10-06', просто тогда были введены изменения в таблицы и до этой даты данные по другому заполнялись. Индекс и так применяется только dst. Log быстро выполняется за счет того queuename` = 'Programmist_queue' AND (`queue_log`.`event` = 'REMOVEMEMBER') появилось недавно ( с 6 числа) Короче понял что надо начинать тригеры писать, чтоб красиво все было в таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 12:33 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
TimofeySinIfnull во втором запросе и правда можно убрать, а в первым нельзя, он из-за соединения появляется. IFNULL(calldate...) можно и нужно убрать в связке (ON секция) в обоих запросах. IFNULL нужно оставить в SELECT секции в первом запросе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 16:46 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
TimofeySin3) идекс евент: там в 3 посте кардигалити есть по таблицам, у евента 18. ок, 18 -- мало на 500К , как уже сказано выше, надо поекспериментировать с запросом на ЛОГ отдельно. возможно добавить временые поля в индекс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 16:48 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
TimofeySin4) переписать с вложенным запросом незя, я хоху вьюху сделать такую, а mysql не разрешает вложенные. во-первых -- Это ограничение обходится -- можно сделать вьюху внутри вьюхи во-вторых -- я крайне не рекомендую делать вьюхи в даной ситуации. Типа: select * from view where c = 123 Дело в том что в не самых последних версиях мускл-а отсутсвует понятие "predicate push" -- тоесть раньше в-юха вычислялась поностью (долго!) и потом к ней применялось where. В Оракле уже давно и только совсем недавно MySQL научился затаскивать условия where внутрь вьюшки с возможностью использования индексов. Однако это нестабильно, негарантировано и чем сложнее в-юшка тем больше вероятность возврата на полный перебор без индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 17:01 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
TimofeySinLog быстро выполняется за счет того queuename` = 'Programmist_queue' AND (`queue_log`.`event` = 'REMOVEMEMBER') появилось недавно ( с 6 числа) Через несколько дней-недель наберется больше таких записей и наченется тормоз... Не пренебрегайте опимизацией запросов к ЛОГУ -- в обоих случаях -- и where в первом селекте и связки (ON) во втором -- причем это могут быть разнуе индексы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 17:07 |
|
||
|
Почему не видит индекс. Ну и вообще как ускорить запрос... :)
|
|||
|---|---|---|---|
|
#18+
TimofeySinКороче понял что надо начинать тригеры писать, чтоб красиво все было в таблице. да, дополнительные вычисляемые поля (типа Агент2) будут полезны. Кроме триггеров это можно сделать на инсерте вычислив значения на клиенте или SQL функциями прямо в тексте инсерта. Лично я бы использовал тригеры тут в последнюю очередь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2017, 17:11 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39533134&tid=1830362]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
| others: | 13ms |
| total: | 146ms |

| 0 / 0 |
