|
|
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
есть запрос ниже прикрепил картинку с запросом и експлайном как можно оптимизировать этот запрос? http://img155.imageshack.us/img155/4548/query1xz.jpg ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2005, 15:01:15 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
вот структура таблиц TABLE `mos_content` ( `id` int(11) unsigned NOT NULL auto_increment, `title` text NOT NULL, `title_alias` text NOT NULL, `introtext` mediumtext NOT NULL, `fulltext` text NOT NULL, `state` tinyint(3) NOT NULL default '0', `sectionid` int(11) unsigned NOT NULL default '0', `mask` int(11) unsigned NOT NULL default '0', `catid` int(11) unsigned NOT NULL default '0', `created` datetime NOT NULL default '0000-00-00 00:00:00', `created_by` int(11) unsigned NOT NULL default '0', `created_by_alias` varchar(100) NOT NULL default '', `modified` datetime NOT NULL default '0000-00-00 00:00:00', `modified_by` int(11) unsigned NOT NULL default '0', `checked_out` int(11) unsigned NOT NULL default '0', `checked_out_time` datetime NOT NULL default '0000-00-00 00:00:00', `publish_up` datetime NOT NULL default '0000-00-00 00:00:00', `publish_down` datetime NOT NULL default '0000-00-00 00:00:00', `images` text NOT NULL, `urls` text NOT NULL, `forum_id` int(11) NOT NULL default '0', `thread_id` int(11) NOT NULL default '0', `attribs` text NOT NULL, `version` int(11) unsigned NOT NULL default '1', `parentid` int(11) unsigned NOT NULL default '0', `ordering` float unsigned NOT NULL default '0', `metakey` text NOT NULL, `metadesc` text NOT NULL, `access` int(11) unsigned NOT NULL default '0', `hits` int(11) unsigned NOT NULL default '0', PRIMARY KEY (`id`), KEY `idx_section` (`sectionid`), KEY `idx_access` (`access`), KEY `idx_checkout` (`checked_out`), KEY `idx_state` (`state`), KEY `idx_catid` (`catid`), KEY `idx_mask` (`mask`), KEY `idx_created` (`created`), KEY `publish_up` (`publish_up`), KEY `publish_down` (`publish_down`), FULLTEXT KEY `fulltext` (`fulltext`) ) TABLE `mos_content_frontpage` ( `content_id` int(11) NOT NULL default '0', `ordering` int(11) unsigned NOT NULL default '0', `last_order` int(11) NOT NULL default '0', PRIMARY KEY (`content_id`)) TABLE `mos_users` ( `id` int(11) NOT NULL auto_increment, `name` varchar(50) NOT NULL default '', `username` varchar(25) NOT NULL default '', `email` varchar(100) NOT NULL default '', `password` varchar(100) NOT NULL default '', `usertype` varchar(25) NOT NULL default '', `block` tinyint(4) NOT NULL default '0', `sendEmail` tinyint(4) default '0', `gid` tinyint(3) unsigned NOT NULL default '1', `registerDate` datetime NOT NULL default '0000-00-00 00:00:00', `lastvisitDate` datetime NOT NULL default '0000-00-00 00:00:00', PRIMARY KEY (`id`), KEY `usertype` (`usertype`), KEY `idx_name` (`name`) ) TABLE `ibf_topics` ( `tid` int(10) NOT NULL auto_increment, `title` varchar(250) NOT NULL default '', `description` varchar(70) default NULL, `state` varchar(8) default NULL, `posts` int(10) default NULL, `starter_id` mediumint(8) NOT NULL default '0', `start_date` int(10) default NULL, `last_poster_id` mediumint(8) NOT NULL default '0', `last_post` int(10) default NULL, `icon_id` tinyint(2) default NULL, `starter_name` varchar(32) default NULL, `last_poster_name` varchar(32) default NULL, `poll_state` varchar(8) default NULL, `last_vote` int(10) default NULL, `views` int(10) default NULL, `forum_id` smallint(5) NOT NULL default '0', `approved` tinyint(1) default NULL, `author_mode` tinyint(1) default NULL, `pinned` tinyint(1) default NULL, `moved_to` varchar(64) default NULL, `rating` text, `total_votes` int(5) NOT NULL default '0', `topic_hasattach` smallint(5) NOT NULL default '0', `topic_firstpost` int(10) NOT NULL default '0', `topic_queuedposts` int(10) NOT NULL default '0', PRIMARY KEY (`tid`), KEY `last_post` (`last_post`), KEY `forum_id` (`forum_id`,`approved`,`pinned`), KEY `topic_firstpost` (`topic_firstpost`), FULLTEXT KEY `title` (`title`) ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2005, 16:43:31 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Hello, empo! Попробуй добавить индекс по полю ordering таблицы mos_content_frontpage И снова сделай explain. -- Anton Yuzhaninov, AVY11-RIPE, citrin#citrin.ru Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2005, 17:11:44 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
насколько я понял - все таблицы, участвующие в твоем запросе, кроме "а" - "сводные" к mos_content (т.е. "а")... если это так, то - попробуй заменить inner join на left join, чтобы "а" попала в список explain-a первой (она и будет первой в склейке), тогда и выборка должна будет использовать index idx_state... p.s. еще можешь поиграть с составным index-ом на state,publish_up,publish_down - попробуй его в том порядке, котором я дал... p.s.s. если не сложно - покажи результат explian-a после того как сделаешь все то что я посоветовал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2005, 17:35:25 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
сделал но все равно выборка всех строк в темп таблицу осталась впринципе как я понимаю нагрузка идет именно изза того что есть сравнение publish_up и publish_down для 1700 строк вот как сделать так чтобы вытаскивались только те строки которые ограничиваются лимитом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2005, 17:38:20 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
заглянувшийнасколько я понял - все таблицы, участвующие в твоем запросе, кроме "а" - "сводные" к mos_content (т.е. "а")... если это так, то - попробуй заменить inner join на left join, чтобы "а" попала в список explain-a первой (она и будет первой в склейке), тогда и выборка должна будет использовать index idx_state... при замене на left join происходить потеря очередности которая задается в f таблице... сделать общий индекс для трех параметров?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2005, 17:42:03 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
я наверное неправильно понял ваш первоначальный вопрос :-) поэтому возникает встечный вопрос - какое количество возращается в результате выполнения запроса? 1. если примерно 1776 - то сам запрос выполняется почти оптимально и необходимо оптимизировать ордеринг... 2. иначе - движок SQL некоректно выбирает порядок склейки... по списку полей в выборке и по условиям выборки я решил что ваш вопрос относится ко 2-му пункту и еще один вопросик - в каком отношении находятся таблицы mos_content и mos_content_frontpage (1:1 или 1:ко многим или др.)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2005, 18:55:02 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
резултать выполнения 15 строк как и указано лимитом но склеивает он не 15 строк а все 1700 плюс потом запускает сортировку по дате что скорее всего и приводит к увеличению нагрузки отношение между таблицами 1:1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2005, 19:16:18 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
извинясь - под количеством строк я имел ввиду без limit-a :-) сценарий выполнения запроса с ордером по двум столбцам из разных таблиц соответственно при склейке сопровождается записью результата во времменую таблицу для общей сотрировки, по-моему этого не избежать... (единственный способ - ограничение выборки одной из них) но как вы - сказали, если таблицы 'a' и 'f' в отношеннии 1:1, то возможно ли их объеденить в одну? если да - то можно подобрать составной index для where и order... если нет - то единственное что у меня получилось - это ограничение по таблице "а" на поле state explain select a.*, u.name as author, u.usertype, y.posts as replycount, y.views From mos_content as a use key(idx_state) inner join mos_content_frontpage as f on f.content_id = a.id left join ibf_topics as y on y.tid = a.thread_id left join mos_users as u on u.id = a.created_by where a.state='1' and ( publish_up = '0000-00-00 00:00:00' or publish_up <= Now()) and (publish_down = '0000-00-00 00:00:00' or publish_down >= Now()) order by f.ordering, a.ordering ASC, a.catid, a.sectionid limit 0,15; возможно idx_state можно скомбинировать с publish_up и publish_down и добиться для type таблицы "а" - range, что еще сократит перебор (у меня не получилось - всегда использовал unix-timestamp :-) ), а можно вместо него использовать publish_up или publish_down (простотри что из них наиболее оптимально) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2005, 20:41:09 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
большое человеческое спасибо "заглянувший" по той причине что натолкнул к решению этой проблемы а решилась она просто создал тройной индекс по полям state,publish_up,publish_down после этого убрал лишний ордер бай тоесть сокротил до f.ordering тем самым убрав создание темп таблицы. скорость выполнения запроса выросла в 3-4 раза и сейчас находится на устраиваемом уровне ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:35:14 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=33289517&tid=1853629]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
361ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 202ms |
| total: | 668ms |

| 0 / 0 |
