DarkElf...

к сожалению, вы очень и очень слабо ориентируетесь в теме, не примите за лишний пафос, но это катастрофа! %)))) (флудить, так флудить %))))

ранее вы писали иначе...

Код:

SELECT name, count(msg_id) FROM users, msgs WHERE  SELECT users_id from users WHERE name = '$name'  LIKE msgs.user_id

такого способа использовать like я не видел...

DarkElf_guest , цитата:

thaon   DarkElf , цитата: SELECT count(msg_id) FROM users, msgs WHERE users.id LIKE msgs.user_id AND users.user_name LIKE '$user_name'   thaon , цитата: select user.name, count(msg.id) msgcount from msg, user where msg.author_id=user.id and msg.post_date>'$date_from' group by user.id order by msgcount desc limit 10 Просто попробуйте посмотреть, что именно получается в результате моего запроса=) Правильно, количество сообщений для определенного в запросе пользователя.

в новой редакции - вполне возможно (хотя есть сомнения относительно того что вы опустили group by и что не отругается интерпритатор по поводу синтаксической ошибки). Кроме этого - по поводу качеств такого рода запросов поговорим ниже.

	DarkElf_guest , цитата:
	в Вашем запросе группировка ведется по полю ID таблицы user. Зачем группировать уникальное значение? в базе это поле - primary_key для таблицы user, оно не может повторятся.

Полная ерунда. Группировка ведется не по полю таблицы а по результатам выборки. Результаты без группировки вы видите - напротив каждого идешника сообщения будет идешник пользователя (если точнее - сразу имя, поскольку идешник я опустил, но можете включить). Неуникальный для выборки, хоть и уникальный для таблицы пользователей.

	DarkElf_guest , цитата:
	и потом, объясните, зачем считать ID сообщений и там искать нужного автора, если можно считать ID авторов?

хм... исходя из условий первоначальной задачи. посчитать количество сообщений (msg.id) пользователя за период (для последующего формирования топа). А результатом подсчета id авторов будет количество авторов постивших в этот период... (как ясно из формулировки)

	DarkElf_guest , цитата:
	Вообще, проще подсчитать так: Код: SELECT user.name, count(msg.autor_id) FROM user, msg WHERE msg.post_date>'$date_from' ORDER BY count(msg.autor_id) desc 10 // Запрос не тестировал.

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

результат будет ужасный

	DarkElf_guest , цитата:
	LIKE - это и есть "=" в mysql.. с той лишь разницей, что если использовать "=", то могут не работать операторы типа "%" и "?"

ууууууууууууууу....

Мой Вам, совет. Действительно практический (если хотите еще дам с десяток в личке). Забудте Like как страшный сон. Он работает в строковом контексте строго для сравнения похожих значений (вроде предложенного вами для user_name). Если вы объединяете таблицы в строковом контексте (как в примере выше где like стоит между ключами), то плачьте! вы же не складываете 2 и 2 с применением синтаксических анализаторов маткада? %)

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

thaon

пока DarkElf тут ничего не джоинит.

thaon
Не переживайте Вы так Речь идет про Санкт-Петроград

не "тут", а "там" %)

серьёзно - не джоинте по лайку никогда - это смерть

вы смотрите на строку, которая вдобавок неиндексирована. строка в строковом контексте в одном случае ( = ) и в другом ( like ) ничем не отличается не правда ли?

возмите сделайте какой-нибудь запросик из 2-х а лучше для наглядности 3-х таблиц (тысяч по 200 записей - это особенно жизненно). объединяйте по ключам. ключи - числовые (int). померьте разницу теперь, тогда поймете, что сравнить, скажем, число 323489 с таким же числом и строку "323489" с такой же строкой оказывается совсем не тоже самое. like заставляет сравнивать числа именно как строки... думаю даже менее чем при 200 тысячах записей вы увидите в чем соль... а когда запросы с такими джоинами в вашем проекте начнут гонять 100-200 человек одновременно.... впрочем до этого не дойдёт. просто ляжет железка и всё.

на той же конфигурации, база данных, с таблицей на 7 полей, заполненных случайными числами и 1 - primary_key, количество записей в базе данных: 1 миллион.


Показывает записи 0 - 26 (27 всего, Запрос занял 0.8994...0.9075 сек)
SQL-запрос:
SELECT ID
FROM `test`
WHERE t1 =1234
LIMIT 0 , 30

Показывает записи 0 - 26 (27 всего, Запрос занял 0.8781...0.8811 сек)
SQL-запрос:
SELECT ID
FROM `test`
WHERE t1 LIKE '1234'
LIMIT 0 , 30


Показывает записи 0 - 26 (27 всего, Запрос занял 0.8824...0.8844 сек)
SQL-запрос:

SELECT *
FROM `test`
WHERE `t1` LIKE '1234'
LIMIT 0 , 30

Показывает записи 0 - 26 (27 всего, Запрос занял 0.8791...0.8838 сек)
SQL-запрос:
SELECT *
FROM `test`
WHERE t1 = '1234'
LIMIT 0 , 30

Показывает записи 0 - 29 (425 всего, Запрос занял 0.0652...0.0656 сек)
SQL-запрос:
SELECT ID
FROM `test`
WHERE t1 LIKE '%1234%'
LIMIT 0 , 30


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

thaon

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

может, и запрос мне, нубу, правильный предложите?=)

структура первой таблицы:

таблица 1
id - primary_key auto_increment
t1...t7 - varchar, длина 10, заполнена случайными числами.

таблица 2
id - primary_key auto_increment
t1...t7 - varchar, длина 10, заполнена случайными числами.


в таблице 2, ну пусть тоже миллион записей будет.

структура таблицы два, имена полей t21...t27


неиндексированные? не вопрос, на какие поля индекс создавать?

сейчас таблиц будет три

строки в третей - t31...t37

жду запроса, и того, на какие делать индекс.

а таблицы между собой имеют какое-то взаимоотношение? где внешие ключи?... или чего мы джоиним-то? %)))

впрочем для теста подойдет и одна таблица (какая там с миллионом записей? table_1?) с таким запросом

select tab1.id from table_1 tab1, table_1 tab2, table_1 tab3 where tab1.id=tab2.id and tab2.id=tab3.id

и 2-й запрос

select tab1.id from table_1 tab1, table_1 tab2, table_1 tab3 where tab1.id like tab2.id and tab2.id like tab3.id

ждем результатов

я ж говорю, у них ID - номера порядковые уникальные, все остальное - случайные числа.

не понял вопроса. вы запросы запустите

Ваш SQL-запрос был успешно выполнен (Запрос занял 19.7100 сек)
SQL-запрос:
SELECT test.id, test.t1, test2.t32
FROM test, test2
WHERE test.t2 = test2.t32
LIMIT 0 , 30

MySQL вернула пустой результат (т.е. ноль рядов). (Запрос занял 19.7162 сек)
SQL-запрос:
SELECT test.id, test.t1, test2.t32
FROM test, test2
WHERE test.t2 = test2.t32
LIMIT 0 , 30

Ваш SQL-запрос был успешно выполнен (Запрос занял 19.8816 сек)
SQL-запрос:
SELECT test.id, test.t1, test2.t32
FROM test, test2
WHERE test.t2 LIKE test2.t32
LIMIT 0 , 30

MySQL вернула пустой результат (т.е. ноль рядов). (Запрос занял 19.8669 сек)
SQL-запрос:
SELECT test.id, test.t1, test2.t32
FROM test, test2
WHERE test.t2 LIKE test2.t32
LIMIT 0 , 30


(пришлось уменьшить таблицу до 10 тыс.записей, иначе, звиняйте, вешается БД)


опять таки, средний результат:
" = " - 19,7131
" LIKE " - 19,87425

экономия - 0,82%

Ваш SQL-запрос был успешно выполнен (Запрос занял 0.1116 сек)
SQL-запрос:
SELECT test.id, test.t1, test2.t32
FROM test, test2
WHERE test.t3 = test2.t33
LIMIT 0 , 30

MySQL вернула пустой результат (т.е. ноль рядов). (Запрос занял 0.1124 сек)
SQL-запрос:
SELECT test.id, test.t1, test2.t32
FROM test, test2
WHERE test.t3 = test2.t33
LIMIT 0 , 30

Ваш SQL-запрос был успешно выполнен (Запрос занял 27.3491 сек)
SQL-запрос:
SELECT test.id, test.t1, test2.t32
FROM test, test2
WHERE test.t3 LIKE test2.t33
LIMIT 0 , 30


Возразить нечего, при использовании индексов разница очевидна.

DarkElf Ужасно.... что вы натворили с моим запросом....

возьмите пожалста мой вариант и подставьте вместо table_1 название своей таблицы с миллионом записей

если название этой таблицы test,то запрос:

Код:

select tab1.id from test tab1, test tab2, test tab3 where tab1.id=tab2.id and tab2.id=tab3.id

и 2-й запрос

Код:

select tab1.id from test tab1, test tab2, test tab3 where tab1.id like tab2.id and tab2.id like tab3.id

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

Показывает записи 0 - 29 (250000 всего, Запрос занял 0.0016 сек)
SQL-запрос:
SELECT test.id
FROM test, test2
WHERE test.id = test2.id
LIMIT 0 , 30

с LIKE время установить не удалось, т.к. mysql просто повесился.

с чем вас и поздравляю