Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
полный перебор таблицы в запросе к view с подзапросами и индексным полем
|
|||
|---|---|---|---|
|
#18+
добрый день. более понятного краткого названия для темы пока не придумал. суть вопроса: как заставить mysql использовать индекс при выборке данных из view c вложенными подзапросами? Код: sql 1. подробности: есть view Код: sql 1. 2. 3. 4. 5. 6. у Главной_Таблицы есть поле ID (primary key). запрос Код: sql 1. не хочет использовать индекс и выполняет полный перебор Главной_Таблицы, на что тратится 3 секунды времени. select_typetablepartitionstypepossible_keyskeyDERIVEDГТ(null)ALLPRIMARY IDX_GT_01(null) если я убираю из view все вложенные подзапросы, то сразу всё становится хорошо select_typetablepartitionstypepossible_keyskeySIMPLEГТ(null)constPRIMARY IDX_GT_01PRIMARY и время выполнения запроса падает до сотых долей секунды. возвращаю назад хотя бы один подзапрос - всё опять рушится. причем дело не в самих вложенных подзапросах, а в их наличии, потому что исходный запрос из view, с прописанным идентификатором сразу в условии WHERE, выполняется за те же сотые доли секунды несмотря на все те же подзапросы. если необходимо - приведу полные тексты ddl, но предполагаю, что решение где-то на поверхности (я же не первый такой), хотя найти его (форум, гугл) пока не удалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2017, 09:55 |
|
||
|
полный перебор таблицы в запросе к view с подзапросами и индексным полем
|
|||
|---|---|---|---|
|
#18+
Darkripple, https://dev.mysql.com/doc/refman/5.7/en/derived-table-optimization.html It is possible to disable merging by using in the subquery any constructs that prevent merging, although these are not as explicit in their effect on materialization. Constructs that prevent merging are the same for derived tables and view references: Aggregate functions (SUM(), MIN(), MAX(), COUNT(), and so forth) DISTINCT GROUP BY HAVING LIMIT UNION or UNION ALL Subqueries in the select list Assignments to user variables Refererences only to literal values (in this case, there is no underlying table) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2017, 21:57 |
|
||
|
полный перебор таблицы в запросе к view с подзапросами и индексным полем
|
|||
|---|---|---|---|
|
#18+
miksoft, Я видел эти ограничения, но вот строка про подзапросы как-то проскочила мимо меня.. видимо остановился на LIMIT-ах, которые у меня тоже были сначала. еще возможно добавил сомнений комментарий к теме про обработку представлений https://dev.mysql.com/doc/refman/5.7/en/view-algorithms.html так что я поверил, что такое возможно... печально. ладно, буду обходить ограничение по другому. Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 13:57 |
|
||
|
полный перебор таблицы в запросе к view с подзапросами и индексным полем
|
|||
|---|---|---|---|
|
#18+
Darkripple https://dev.mysql.com/doc/refman/5.7/en/view-algorithms.html Эту ссылку я тоже хотел дать, но там изрядную часть страницы вытащили (по сравнению с документацией по предыдущим версиям) туда, на что я дал ссылку. Darkrippleладно, буду обходить ограничение по другому.В MySQL вообще VIEW весьма корявые. Лучше бы совсем от них отказаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 22:44 |
|
||
|
полный перебор таблицы в запросе к view с подзапросами и индексным полем
|
|||
|---|---|---|---|
|
#18+
miksoftВ MySQL вообще VIEW весьма корявые. Лучше бы совсем от них отказаться. не в обиду MySQL - после Oracle натыкаюсь на многие вещи, которые на мой взгляд "недореализованы", или логику которых я "не принимаю". пример - разный подход к неявному преобразованию строки в число в отдельных запросах и в хранимых процедурах. или из недавнего: Код: sql 1. 2. первый выдаёт результат, второй - нет. или вот тоже Код: sql 1. 2. как это объяснить? зачем он NULL во втором случае превращает в слово "null" ??? возвращаясь к view-хе - как бы криво ни была реализована работа с ними, альтернативы ей, как заранее подготовленному запросу, с возможностью "компактного" использования в разных местах/средах и единой точкой изменения - пока не нашёл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 07:41 |
|
||
|
|

start [/forum/topic.php?fid=47&fpage=72&tid=1830592]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
2ms |
| others: | 14ms |
| total: | 149ms |

| 0 / 0 |
