Как «это» может работать?
Я вот задал сам себе, да и вам вопрос. Может я чего-то не понимаю?
Как может «нормально» работать такой запрос в CMS?
Вот EXPLAIN:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const table…
Как вы думаете откуда взят этот запрос? ;)
Кстати а всего запросов ~80
P.S.
Вот еще один маленький
EXPLAIN:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE b_stat_searcher ALL NULL NULL NULL NULL 143 Using where; Using filesort
И так половина запросов. Т.е. «а что такое индексы и зачем они нужны».
UPD:
После критики — бесплатный совет от хабрапользоватлей, компании 1C-Битрикс:
пересмотреть стратегию запросов и индексов.
Здесь архитектуру сильно ломать не надо.
Просто проверить все запросы EXPLAIN-ом и грамотно подобрать индексы — раз.
Два — разделить сложные запросы на мелкие или «union» мелких запросов.
Проверить «рендер» запросов — три.
Честно говоря последняя версия, с точки зрения юзабилити мне уже понравилась. (имхо)
Т.е. в этом направлении идут верным путем. Вот только какими ресурсами все это сделано.
Как может «нормально» работать такой запрос в CMS?
Запрос:
SELECT ID, MESSAGE, MESSAGE_LID, SAVE_STATISTIC, URL_REDIRECT, TEST
FROM b_stop_list
WHERE ACTIVE = 'Y'
AND TEST = 'N'
AND (
SITE_ID = 'ru'
OR SITE_ID IS NULL
OR LENGTH( SITE_ID ) <=0
)
AND (
DATE_START <= NOW( )
OR DATE_START IS NULL
)
AND (
DATE_END >= NOW( )
OR DATE_END IS NULL
)
AND (
(
(
(
MASK_1 &127
) = IP_1
AND (
MASK_2 &0
) = IP_2
AND (
MASK_3 &0
) = IP_3
AND (
MASK_4 &1
) = IP_4
)
OR (
IP_1 IS NULL
AND IP_2 IS NULL
AND IP_3 IS NULL
AND IP_4 IS NULL
)
)
AND (
UPPER( 'Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; ru) Opera 9.51'
) LIKE CONCAT
( '%', UPPER( USER_AGENT ) , '%' )
OR LENGTH( USER_AGENT ) <=0
OR USER_AGENT IS NULL
)
AND ( 65 =0
OR USER_AGENT_IS_NULL <> 'Y' )
AND (
UPPER( 'http://bitrix.ru/search/index.php?show_page_exec_time=Y&
show_include_exec_time=Y&
show_sql_stat=Y&bitrix_include_areas=Y&q=%EF%EE%E8%F1%EA&where=' ) LIKE CONCAT
( '%', UPPER( URL_FROM ) , '%' )
OR LENGTH( URL_FROM ) <=0
)
AND (
UPPER( 'http://bitrix.ru/search/index.php?show_page_exec_time=Y&
show_include_exec_time=Y&show_sql_stat=Y&bitrix_include_areas=Y&q=%EF%EE%E8%F1%EA&where=&PAGEN_1=2' ) LIKE CONCAT
( '%', UPPER( URL_TO ) , '%' )
OR LENGTH( URL_TO ) <=0
OR URL_TO IS NULL
)
)
Вот EXPLAIN:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const table…
Как вы думаете откуда взят этот запрос? ;)
Кстати а всего запросов ~80
P.S.
Вот еще один маленький
SELECT ID, NAME, SAVE_STATISTIC, HIT_KEEP_DAYS, CHECK_ACTIVITY
FROM b_stat_searcher
WHERE ACTIVE = 'Y'
AND LENGTH( USER_AGENT ) >0
AND UPPER( 'Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; ru) Opera 9.51' ) LIKE CONCAT
( '%', UPPER( USER_AGENT ) , '%' )
ORDER BY LENGTH( USER_AGENT ) DESC , ID
EXPLAIN:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE b_stat_searcher ALL NULL NULL NULL NULL 143 Using where; Using filesort
И так половина запросов. Т.е. «а что такое индексы и зачем они нужны».
UPD:
После критики — бесплатный совет от хабрапользоватлей, компании 1C-Битрикс:
пересмотреть стратегию запросов и индексов.
Здесь архитектуру сильно ломать не надо.
Просто проверить все запросы EXPLAIN-ом и грамотно подобрать индексы — раз.
Два — разделить сложные запросы на мелкие или «union» мелких запросов.
Проверить «рендер» запросов — три.
Честно говоря последняя версия, с точки зрения юзабилити мне уже понравилась. (имхо)
Т.е. в этом направлении идут верным путем. Вот только какими ресурсами все это сделано.
комментарии (331)