Hostem Опубликовано 6 Мая 2005 Жалоба Поделиться Опубликовано 6 Мая 2005 Поле member_id типа varchar(32), а не int! Какого? Там только один индекс! (первичный) А запросы делаются вот так:SELECT member_id from ibf_voters WHERE member_id=2461 and tid=990 Т.е. надо еще проиндексировать member_id и tid (лучше групированый индекс)В версии 1.3 тоже самоеА возможно и в 2.0.0!Изменил тип member_id и добавил такой индекс:ALTER TABLE ibf_voters ADD INDEX member_id( member_id, tid ) И вышеуказанный запрос стал быстрее в 7 раз! Можно писать в "Косяки форума"? [1115372984:1115374668]Проверил - такое даже в 2.0.3. (точно такая же структура, с текствым типом для member_id ) Ссылка на комментарий Поделиться на других сайтах Прочее
Song Опубликовано 6 Мая 2005 Жалоба Поделиться Опубликовано 6 Мая 2005 Да уж... < < насчёт смены поля - это безусловно. А вот насчёт индекса - наоборот, не member_id, tid, а tid, member_id. Т.е. вот так:ALTER TABLE ibf_voters MODIFY member_id mediumint(8) unsigned NOT NULL default 0, ADD INDEX (tid, member_id) Ссылка на комментарий Поделиться на других сайтах Прочее
Hostem Опубликовано 7 Мая 2005 Автор Жалоба Поделиться Опубликовано 7 Мая 2005 Еще совсем не проиндексирована таблица ibf_polls (надо проиндекстировать по полю id'а тем). Не используемое текстовое поле rating и total_votes в ibf_topics, misc (строкового типа) в ibf_members, в ibf_categories поле state строкового типа (а хотя оно принимает значения 0, 1 и 2)... Еще в ibf_topics поле state строковое и принимает значения 'open', 'closed', 'link'. Может enum тип нужен?Похожая ситуация в поле poll_state. Ссылка на комментарий Поделиться на других сайтах Прочее
Song Опубликовано 8 Мая 2005 Жалоба Поделиться Опубликовано 8 Мая 2005 Hostem, спасибо ALTER TABLE ibf_polls ADD UNIQUE KEY (tid) ALTER TABLE ibf_topics DROP COLUMN rating, DROP COLUMN total_votesВот с полем типа TEXT они просчитались Это же не VARCHARВисит в таблице и не используется ALTER TABLE ibf_members DROP COLUMN miscПравда, у себя я его не нашёл, видимо давно грохнул. Еще в ibf_topics поле state строковое и принимает значения 'open', 'closed', 'link'. Может enum тип нужен?Мне кажется, это на будущее. Вдруг, ты будешь вводить другие обозначения топиков?Вообще, в ibf_members мне помнится, я удалял немало неиспользованных полей. Ещё есть одно бесполезное поле в ibf_posts:ALTER TABLE ibf_posts DROP COLUMN post_titleС варчарами-то, оказалось, беда Ещё некоторые запросы:ALTER TABLE ibf_admin_sessions MODIFY MEMBER_ID mediumint(8) unsigned NOT NULL default 0 ALTER TABLE ibf_categories MODIFY state TINYINT(1) unsigned NOT NULL default 0 ALTER TABLE ibf_forum_tracker MODIFY member_id mediumint(8) unsigned NOT NULL default 0 ALTER TABLE ibf_forums MODIFY status TINYINT(1) unsigned NOT NULL default 0 ALTER TABLE ibf_members MODIFY hide_email TINYINT(1) unsigned NOT NULL default 0 Запросы по индексам:-- лишний индекс: ALTER TABLE ibf_forums DROP INDEX (id); -- если смайлов много, может помочь: ALTER TABLE ibf_emoticons ADD INDEX (clickable); Не говоря уж о том, что в ibf_posts почти все поля NULL, хотя должны быть NOT NULL default 0.Но это я уже давно исправил, не помню запросы. Ссылка на комментарий Поделиться на других сайтах Прочее
Hostem Опубликовано 17 Мая 2005 Автор Жалоба Поделиться Опубликовано 17 Мая 2005 В ibf_members поле time_offset типа varchar(10). Тут подойдет tinyint.И поле interests типа text, может лучше varchar'ом обойтись ? Ссылка на комментарий Поделиться на других сайтах Прочее
Song Опубликовано 18 Мая 2005 Жалоба Поделиться Опубликовано 18 Мая 2005 1) не подойдет.По-моему time_offset с + записывается.2) А если у тебя интересов больше чем на 255? Ссылка на комментарий Поделиться на других сайтах Прочее
Aleks Опубликовано 24 Мая 2005 Жалоба Поделиться Опубликовано 24 Мая 2005 много сайлов это сколько? или много клибельных или вообще их если много? Ссылка на комментарий Поделиться на других сайтах Прочее
Song Опубликовано 24 Мая 2005 Жалоба Поделиться Опубликовано 24 Мая 2005 просто много + условие что есть соответствие что кликабельных 50 % от некликабельных. Ссылка на комментарий Поделиться на других сайтах Прочее
Aleks Опубликовано 24 Мая 2005 Жалоба Поделиться Опубликовано 24 Мая 2005 мне интересно, как это может выглядеть - 50 % кликабельных от 250 некликабельеных.. Ссылка на комментарий Поделиться на других сайтах Прочее
Song Опубликовано 24 Мая 2005 Жалоба Поделиться Опубликовано 24 Мая 2005 ну 125 значит )Вообщем идея состоит в том, что прок от индекса есть тогда когда мускулу легче взять инфу из него чем проходить всю базу.Если в индексе - 75% из всего объёма таблицы, то ему легче всю таблицу просканировать чем дополнительно обращаться к индексу Ссылка на комментарий Поделиться на других сайтах Прочее
Hostem Опубликовано 25 Мая 2005 Автор Жалоба Поделиться Опубликовано 25 Мая 2005 А 250 str_replace'ов при обработке поста - это ничего страшного? Помоему тут уже не нагрузку на БД надо оптимизировать, а кол-во str_replace (). Ссылка на комментарий Поделиться на других сайтах Прочее
Song Опубликовано 25 Мая 2005 Жалоба Поделиться Опубликовано 25 Мая 2005 Хорошая идея, надо мод сделать. Ссылка на комментарий Поделиться на других сайтах Прочее
Рекомендуемые сообщения