статистику сам )) загрузка данных с харда все равно идет целыми строками, если большинство запросов не требуют текста, то выгоднее отделить его. Но это как раз теория, и зависит от физического размещения данных в таблицах. В dbase формате текстовые поля (memo) и так отделены в отдельный файл. А как на практике на современных компах - хз.
Какой миф? более того, оно читается приличными блоками еще на уровне железа харда и системы, а не БД.
Вот давайте всё-же отделим мифы от "не мифов" и разберёмся всё-же что есть миф а что нет, потому что я без понятия как работает MySQL (а сырцы ковырять я пол жизни на это убью, там их много)
Davil, размер зависит от размера HDD, на самом деле. Я у одного товарища видел и 16384 байт на ноуте с 40Гб винтом )) Чем больше — тем эффективнее считываются данные, чем меньше — больше выигрыш в месте на HDD.
холивар стартед.. програмисты пхп в теме про мускул обсуждают обсуждают скорость работы алгоритмов кэширования дисковых операций на уровне OS. Забыли ещё про кэш на уровне контроллера винчестера....
mmaavv, я в холиварах не участвую, я их только разжигаю, отхожу в сторонку, а потом громко ругаюсь ))))
Про настройки мускула хотябы поспорили - кто какие использует и как это влияет на производительность.
Горбунов Олег зависить то зависит, но выбирать можно =) mmaavv А на урове HDD кэш программируется изготовителем и перепрошивать его не советую =) Ну это надо в теме аниме обсуждать...
Не знаю куда ткнуть, пусть сюда. [sql]SELECT count( ts.ts_id ) AS sum, ts.ts_avtor_id FROM task ts, task ts0 WHERE ts.ts_cl_id = ts0.ts_cl_id AND ts0.ts_cat_id =9 $where GROUP BY ts.ts_avtor_id[/sql] при увеличении размеров базы время выполнения возрастает нелинейно, при том что число ts_avtor_id остается примерно таким же.
armadillo Нелинейно это как? Быстрее, чем линейно (экспоненциально) или медленнее (логарифмически)? И можно этот же запрос выразить словами? До меня не доходит смысл (особенно условие ts.ts_cl_id = ts0.ts_cl_id, учитывая, что ts и ts0 - одна и та же таблица)
Быстрее. Квадратично скорее всего. Ожидаемо, но неприятно. найти задачи по клиентам, по которым была задача с ts_cat_id=9 подсчитать их для каждого ts_avtor_id ))
armadillo А как запрос реагирует на ситуацию, когда у одного клиента дважды была такая задача? Логически рассуждая, склейка для него должна производиться дважды и результаты поплывут... попробуй запрос [sql]SELECT COUNT(*) AS sum, ts_avtor_id FROM task WHERE ts_cl_id IN (SELECT DISTINCT ts_cl_id FROM task WHERE ts_cat_id=9) GROUP BY ts_avtor_id[/sql]
Dagdamor такого быть не должно. МНОГО дольше. mysql 4.1 Возможно потому, что не всегда нужны ВСЕ клиенты с cat_id=9 (там еще $where) кстати distinct тут не нужен. dark-demon Тогда уж тремя.
Сейчас самый быстрый вариант на больших объемах. Вроде скорость возрастает линейно. Но непонятно и пока нет уверенности. [sql]select SQL_NO_CACHE count( tt1.ts_id ) AS sumka, tt.ts_avtor_id from (select ts_id,ts_avtor_id,ts_cl_id from ".$tbl." where ".$where." tt, (select ts_id,ts_cl_id,ts_avtor_id from ".$tbl." where ts_cat_id =9) tt1 where tt.ts_cl_id=tt1.ts_cl_id group by tt.ts_avtor_id[/sql]
нет, так он почему-то все варианты перебирает, включая без cat_id=9 поправка - это я что-то напутал с тестовой базой. запрос видимо верный.
[sql]select id from t1 , (select tlike_id from tlike where tlike_id between 1 and 1000 union select tlike_id from tlike where tlike_id between 1000 and 1500) a0 where t1_tlike_id=tlike_id union select id from t1, (select t2_id from t2, (select tlike_id from tlike where tlike_id between 1 and 1000 union select tlike_id from tlike where tlike_id between 1000 and 1500) a0 where t2_tlike_id=tlike_id) a1 where t1_t2_id=t2_id[/sql] как заставить его кешировать запрос с tlike?