есть две таблицы (mysql)...
 
viewer_checked ( 2,714 записей )
 
id | int auto_increment
surname | text
name | text
patronymic | text
organization | text
post | text
phone | text
email | text
activate | int
who | int
client | int
date_active | int
branch | int
 

 
subscription (13,326 записей)
 
id | int auto_increment
type | int
email | text
date | int
activate | int
date_active | int
 

написал запрос:

 
дк вот... на локальном компьютере phpmyadmin не может справиться с запросом... слабенький... а на серве выполняется, но за 30 секунд...
правда данная муть проходит раз в ночь... кроном... но есть ли какая нибудь возможность как то ускорить данный скрипт?? (((

ты не написал назначение таблиц и что хочешь получить на выходе.

ну тут короч идет в первой таблице идут зарегистрированные клиенты
во второй email тех кто подписан на рассылку но не зарегистрирован ( причем есть 5 видов подписок, следовательно во второй таблице email может 5 раз повторяться (меняется type в зависимости от рассылки) )
 
выбираю все уникальные записи с первой таблицы и объединяю с уникальными записями второй с исключением повторов первой таблицы...
 
эта вся муть для расслыки... поэтому еще учитывается поле date_active - дата активности данного email.. когда он проверился... то происходит изменение даты активности... т.к. на хостинге разрешена отправка только 1000 писем в сутки... после 900 отправки писем происходит прерывание скрипта, в следующий день продолжается с того места, на котором был прерван скрипт...

очень хуевая тема юзать SELECT во WHERE больше так не делай

что за activate = '1'  не рассказал. наверное флаг что почта высылалась. если так, то достаточно условия на дату.
не делай для строковых полей тип text. это blob поле и работает медленно по сравнению с varchar
 
главные тормоза конечно от not in select, хотя каждый distinct добавляет свои 5коп и бессмысленный order by в промежуточных запросах тоже
 

в целом говно то еще.

бд в третью нормальную форму приведи, и запросы упростятся и сущности дублироваться перестанут (DISTINCT не нужен будет) и таблицы места меньше станут занимать на диске/в памяти

раньше запрос был выполнен за 35.4826 сек.
 
после того, как я убрал три лишнии сортировки запрос был выполнен за 40.7410 сек. :(

 

очень хуевая тема юзать SELECT во WHERE

я это понимаю... но как быть, у заказчика все время какие-то новые непонятные идеи... после которых и приходится идти на всякие извраты...
 

что за activate = '1'  не рассказал. наверное флаг что почта высылалась. если так, то достаточно условия на дату...

activate = '1' это активированные пользователи... так что не достаточно условия на дату...
 

не делай для строковых полей тип text. это blob поле и работает медленно по сравнению с varchar

после перевода text в varchar второй запрос выполнился за 33.1043 сек.,
 
а первый за 38.3414 сек.
 

 

бд в третью нормальную форму приведи, и запросы упростятся и сущности дублироваться перестанут (DISTINCT не нужен будет) и таблицы места меньше станут занимать на диске/в памяти

видимо так и сделаю...

Чуток подчистил запрос. Глянь такой возвращает теже результаты или другие получились? :)
 
тяжело без даных проверять, но судя по логике должно вернуть тоже.
 

Чтобы работало быстро - надо с индексами поиграться. Данных тут немного, так что он в принцип за 0.5 максимум должен выполняться при должных условиях зы: Для начала поле email в обоих таблицах должно быть индексируемым.
 
Предположительные индексы -
 
для Subscription
1. activate, email, date_active
2. email, id, activate, date_active
 
для viewer_checked
1. activate, email, date_active
 
Хотя по факту возможно хватит и первого индекса на оба случая, но не думаю)
 
Но без данных живых это только догадки :)

EXPLAIN тебе в помощь

Ivan

EXPLAIN тебе в помощь

Да, КЭП! :-)
 
он всем поможет)

Ivan

EXPLAIN тебе в помощь

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

AlexB

люди вместо того, чтобы просто взять и посмотреть план

может ещё мануал почитать, лол

всем: не поймет он результатов explain
 
топикстартеру: у тебя несколько видов подписок для незарегистрированных, а для пользователей получается нет разбивки. что-то тут не так. логика хромает.
1) полноценные пользователи должны аналогично попадать в таблицу "подписка" и получишь один простой запрос
2) чтобы выборка уникальных email была быстрой, сделай его символьным и индексируй его.
будет работать доли секунды
 
30 или 40 сек: я думаю реально у тебя разброс +- 50% по времени, так что такие наблюдения ниочем. наведи порядок кардинально
 

artoodetoo

2) чтобы выборка уникальных email была быстрой, сделай его символьным и индексируй его.

char(50)  будет более чем достаточно :-)

varchar медленнее?