ПOМОГИТЕ профи, оптимизация MySQL, есть ли выход???

Существует сайт на котором есть
-чаты
-гостевая
и т.д.
Во всех этих модулях используется база данных MySQL
Везде запросы одинарные т.е. сверка с одной - двумя таблицами, и все работает быстро

Но есть еще один модуль который производит сверку сразу по нескольким таблицам.
Кода под рукой нет новыглядит это примерно так

выбираю данные из таблицы 1

если есть найденные то

ище данный по таблице 2 в интервале заданного времени времени

т.е. в одном запрове идет проверка сразу по нескольким таблицам

причем у таблиц нет индексов

ну например

таблица 1
url,ip,agent,datetime

таблица 2
url,ip,agent,datetime

в данном случе будет примерно такой запрос

SELECT * FROM таблица 1 WHERE таблица 1.url = таблица 2.url AND и т.д.

а вот например друго запрос

SELECT * FROM таблица 1 WHERE url = (SELECT url FROM таблица 2 WHERE таблица 1.ip = таблица 2.ip AND таблица 1.agent = таблица 2.agent AND datetime > сегодняшняя дата - 5 дней)

или например вот так

SELECT * FROM таблица 1 WHERE url = (SELECT url FROM таблица 2 WHERE таблица 1.ip = таблица 2.ip AND таблица 1.agent = таблица 2.agent AND datetime > сегодняшняя дата - 5 дней) AND datetime > сегодняшняя дата - 5 дней AND url <> моей ссылки

короче таких запросов там очень много
в итоге при загрузки страницы сайта сайт виснет на 3 мин!!!
и никто не может получить к нему доступ пока работа с базой данных не будет закончена

т.е. если все это перевести в циклы то каждое значение из таблицы 1 сверяется со всеми значениями с таблицой 2 и т.д.
а значений в таблице несколько тысяч!!!
т.е. это цикл в цикле

вопрос таков как мне подсчитать время выполнения каждого запроса

чтото типа такого

SELECT * FROM таблица 1 WHERE таблица 1.url = таблица 2.url AND и т.д.
---вывожу сколько времени шел запрос

SELECT * FROM таблица 1 WHERE url = (SELECT url FROM таблица 2 WHERE таблица 1.ip = таблица 2.ip AND таблица 1.agent = таблица 2.agent AND datetime > сегодняшняя дата - 5 дней)
---вывожу сколько времени шел запрос

и еще для чего нужны индексы? и как они могут тут чемто помочь?

как такие запросы оптимизировать?

этот модуль такой сложный чтобы предотвратить накрутку
но грузилово слишком сильное
и модуль работает в автоматическм режиме распределяя трафик
в итоге на сайт иногда просто не попасть
это ппц, а выхода из этой ситуации не вижу т.к. не упростить никак

на хостинге мне сказали что покупка более мощьного сервера ни к чему не приведет и дали понять что все CMS работают быстро на любых хостингах
и отправили оптимизировать

0

Насчет ключей могу сказать. Ключи ускоряют поиск по таблице. Ставятся на ту колонку, по которой будет производиться поиск. Как правило, это колонка с уникальными ID.

Для примера. Ты попросишь у меня книгу "Сборник стихов А.С.Пушкина", я тебя приведу в свою комнату и укажу на огромную кучу книг, лежащих в углу. Насколько быстро ты найдешь книгу, можно только догадываться. А если ты придешь за книгой в библиотеку, то там они упорядочены по какому-либо свойству (имени автора, названию). Чтобы найти любую книгу в библиотеке среди тысяч экземпляров, тебе понадобится не больше минуты.

Но, думаю, если у тебя запросы обрабатываются по 3 минуты, индексы вряд ли сильно помогут. Нужно переделать, оптимизировать сами запросы, подумать о более удобной структуре БД.

0

Сообщение от kiki WHERE url = (SELECT url FROM

Используйте JOIN'ы правильно - будет намного быстрее. А если еще и индексов насоздавать, то еще быстрее станет.

1

Сообщение от Vovan-VE Используйте JOIN'ы правильно - будет намного быстрее. А если еще и индексов насоздавать, то еще быстрее станет. SQL 1 2 3 4 SELECT `t1`.* FROM `table1` AS `t1`     INNER JOIN `table2` AS `t2` ON `t1`.`url` = `t2`.`url` AND `t1`.`ip` = `t2`.`ip` AND `t1`.`agent` = `t2`.`agent` WHERE `t2`.`datetime` > SUBDATE(NOW(), INTERVAL 5 DAY)

Спасибо большое, вот только я разобрал все запросы и нашел вшивый, вот он

выполняется этот запрос аж 40 сек
таблица userlist содержит 400 записей
таблица visitors содержит более 100 000 записей

КАК МОЖНО ИСПРАВТЬ?
как переделать в JOIN???

0

Сообщение от kiki выполняется этот запрос аж 40 сек КАК МОЖНО ИСПРАВТЬ? как переделать в JOIN?

Могу ошибиться, но, надеюсь, будет работать.
Надо создать индексы для:
`userlist`.`url`
`userlist`.`status`
`visitors`.`where`
`visitors`.`datetime`

1

Vovan-VE

Я извиняюсь если достал своими вопросами, но если можно напишите пожалуйста подробно что делает этот запрос.
Как я понял он каким то образом объединяет таблицы, не могу понять только что такое LEFT JOIN

и еще я почитал литературу и в ней сказано что индексы замедляют запросы типа UPDATE, это правда?

Надо создать индексы для: `userlist`.`url` `userlist`.`status` `visitors`.`where` `visitors`.`datetime`

для чего нужны эти индексы?
и какого они типа?

"прошу прощения но я нуб "

0

Сообщение от kiki Как я понял он каким то образом объединяет таблицы, не могу понять только что такое LEFT JOIN

Всего-навсего используется UPDATE для нескольких таблиц.

Обычный JOIN (от же INNER JOIN)

`a` JOIN `b` ON условие_объединения

объединяет каждую запись из таблицы `a` с каждой записью из таблицы `b`, если записи удовлетворяют условию_объединения (если оно указано). (Если условие_объединения отсутствует, то итого получается m*n записей - каждая с каждой).

А вот LEFT JOIN действует немного иначе

`a` LEFT JOIN `b` ON условие_объединения

в целом суть та же (изначально каждая с каждой), но если вдруг оказалось, что записи из таблицы `a` не нашлось ни одной записи из таблицы `b`, которая довлетворяет условию_объединения, то генерируется дополнительная запись с NULL у всех полей из `b`. Т.е. из `a` в любой случае будут извлечены все записи.

Сообщение от kiki и еще я почитал литературу и в ней сказано что индексы замедляют запросы типа UPDATE, это правда?

Да, это естественное поведение. Индексы замедляют INSERT и UPDATE и ускоряют SELECT (если ими пользоваться, и пользоваться правильно). Так устроен этот мир - если где-то выигрываем, значит где-то должны проигрывать.

Сообщение от kiki для чего нужны эти индексы? и какого они типа?

Нужны для ускорения SELECT'а. В данном случае Вам нужны, скорее всего, обычные INDEX. Если данные в каком-то одном поле (или в нескольких полях вместе) уникальны и точно не должны повторяться в таблице, то лучше это поле (эти поля вместе) сделать уникальным индексом (UNIQUE INDEX).

1