|
|
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
product 50,606 записей product_to_category 151,818 записей Код: sql 1. 2. 3. 4. 5. 6. 7. explain Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2014, 19:20:26 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
сразу - зачем лефт джоин? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2014, 19:25:31 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
alex564657498765453, привычка ( с inner не лучше время ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2014, 19:53:26 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
авторSELECT p.product_id FROM product p ORDER BY p.sort_order LIMIT 30 индекс на p.sort_order ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2014, 21:13:08 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
ScareCrow, есть уже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2014, 00:14:02 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
Извиняюсь за вторжение, вопрос назрел, а тут как раз протестить можно... Если p2c.category_id = 59 перенести из where в join быстродействие как то изменится? А то часто сталкивался с подобным, и не задумывался, а тут натолкнули на мысль.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2014, 00:29:50 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
SharuPoNemnogu, Код: sql 1. 2. 3. 4. 5. 6. 7. 8. но запрос вернул все id из product ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2014, 00:44:31 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
авторно запрос вернул все id из product так потому что left join наверно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2014, 01:36:28 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
SharuPoNemnogu, туплю, извините Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2014, 03:29:45 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
можно ли что-то сделать в этом случае? 0.1-0.2 очень много. на самом деле итоговый запрос гораздо сложнее, я разбил на части что бы понять что делать. или это время максимум, что можно выжать из таких таблиц? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2014, 21:18:14 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
pavlickJOIN product_to_category p2c ON p2c.product_id = p.product_id AND p2c.category_id =59 Индекс на product_to_category(product_id,category_id) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2014, 22:15:46 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
Cygapb-007pavlickJOIN product_to_category p2c ON p2c.product_id = p.product_id AND p2c.category_id =59 Индекс на product_to_category(product_id,category_id) ? ну тогда скорее наоборот category_to_product(category_id,product_id) так как изначальный запрос начинается с поиска по категории. Тогда будет первый селект по индексу только, что убыстрит (особено если индекс поместится в РАМ) Как вариант реального убыстрения -- денормализовать слегка и засунуть сорт_ордер в таблицу продукт_категория Еще вариант -- попробовать логически улучшить общий запрос (который нам не показали) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2014, 06:34:28 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
javajdbc, индекс product_to_category(product_id,category_id) был, добавил category_to_product(category_id,product_id), но скорость не изменилась денормализовать, засунув сорт_ордер в таблицу продукт_категория я не могу потому как order by может быть не только по sor_order, но ещё по куче полей из product/product_description Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2014, 14:31:33 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
pavlickm, ОК, елси вам нужен имено такой запрос , то можно покапаться в следуюших направлениях: 1. любой СКЛ сопровождайте ЕХПЛАИН-ом и скоростью (желательно среднее трех прогонов) 2. для чистоты експеримента используйте SQL_NO_CACHE SELECT SQL_NO_CACHE p.product_id ......... 3. попробуйте добится полной работы индекса (category_id,product_id). Для этого уберите ВСЕ индексы с таблицы и пересоздайте (category_id,product_id) После этого запрос select product_id from product_to_category where category_id = 59 должен поиметь запись в ЕХПЛАИН "Using index" и не иметь "using filesort" "using temporary". 4. Уберите все LEFT. в данном случае это без разницы по результату но серьезный отрицательный ефект на скорость 5. возможно поиграться со связками -- таблицы можно подсоединять по продукт_ид ис разных таблиц --- но это следуюшуй этап. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2014, 15:32:40 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
javajdbc, индекс один оставил Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Код: sql 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2014, 16:40:48 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
сам запрос без order by sort_order очень быстрый Код: sql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2014, 16:44:59 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
ScareCrowавторSELECT p.product_id FROM product p ORDER BY p.sort_order LIMIT 30 индекс на p.sort_order ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2014, 17:59:49 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
pavlickmScareCrow, есть уже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 02:31:34 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
pavlickmjavajdbc, индекс один оставил Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Код: sql 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. 5. что-то не работает у вас -- по идее п2ц запрос не должен давать файлсорт/темпорари. покажите ресультаты: 1) SHOW CREATE TABLE prodyct_to_category; 2) скорость и ЕКСПЛЕЙН: select SQL_NO_CACHE product_id from product_to_category where category_id = 59 3) что бы два раза не вставать SHOW CREATE TABLE prodyct_to_shop; 4) скорость и ЕКСПЛЕЙН: select SQL_NO_CACHE product_id from product_to_shop where shop_id = 0 5) не заморачивайтесь раньше времени с ORDER BY / LIMIT. На большом запросе все равно это самые последние операции. Не надо их использовать во время промежуточной оптимизации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 02:57:13 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
авторне заморачивайтесь раньше времени с ORDER BY / LIMIT. На большом запросе все равно это самые последние операции. Не надо их использовать во время промежуточной оптимизации. плохая фраза. очень. как раз Order by и limit в первую определяют как будет выполнятся запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 02:59:14 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
ScareCrowавторне заморачивайтесь раньше времени с ORDER BY / LIMIT. На большом запросе все равно это самые последние операции. Не надо их использовать во время промежуточной оптимизации. плохая фраза. очень. как раз Order by и limit в первую определяют как будет выполнятся запрос. согласно 16165541 , в большом запросе сортировка/лимит идет после всех жоинтов и всех филтров. т.е., напромер, поиск (и его оптимизация) записей в product_to_category по category_id врядли связан с конечной сортировкой. Или вы что-то другое хотели сказать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 03:08:32 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
javajdbcScareCrowпропущено... плохая фраза. очень. как раз Order by и limit в первую определяют как будет выполнятся запрос. согласно 16165541 , в большом запросе сортировка/лимит идет после всех жоинтов и всех филтров. т.е., напромер, поиск (и его оптимизация) записей в product_to_category по category_id врядли связан с конечной сортировкой. Или вы что-то другое хотели сказать? попробуйте запрос из большой таблицы с limit и без. покажите результаты. покажите план. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 13:47:19 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
ScareCrowjavajdbcпропущено... согласно 16165541 , в большом запросе сортировка/лимит идет после всех жоинтов и всех филтров. т.е., напромер, поиск (и его оптимизация) записей в product_to_category по category_id врядли связан с конечной сортировкой. Или вы что-то другое хотели сказать? попробуйте запрос из большой таблицы с limit и без. покажите результаты. покажите план. в огороде бузина а в Киеве -- сами знаете... В оригинале было про "промежуточную" оптимизацию. (В частности первоначальная выборка продукт_ид из п2ц таблицы) автор5) не заморачивайтесь раньше времени с ORDER BY / LIMIT. На большом запросе все равно это самые последние операции. Не надо их использовать во время промежуточной оптимизации. То, что вы говорить, 100% верно, но нужно на последуюших стадиях оптимизации запроса -- в тот момент когда мыскл будет делать сорт/лимит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 16:29:58 |
|
||
|
подскажите как ускорить запрос
|
|||
|---|---|---|---|
|
#18+
авторТо, что вы говорить, 100% верно, но нужно на последуюших стадиях оптимизации запроса -- в тот момент когда мыскл будет делать сорт/лимит. эпично. теперь подумайте что такое план запроса, когда он строится? и как на это влияет ORDER BY + LIMIT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 16:40:19 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38670688&tid=1834650]: |
0ms |
get settings: |
13ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
84ms |
get tp. blocked users: |
1ms |
| others: | 236ms |
| total: | 417ms |

| 0 / 0 |
