ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Оптимизация таблицы личных сообщений
5 сообщений из 5, страница 1 из 1
Оптимизация таблицы личных сообщений
    #33458250
Нариман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нариман
Участник
Оптимизация таблицы сообщений

Подскажите какие существуют способы оптимизации больших таблиц ?

Есть таблица:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
CREATE TABLE z_message (
  login_id varchar( 32 ) NOT NULL default '',   // От кого сообщение
  login_to varchar( 32 ) NOT NULL default '',  // Кому сообщение
  viewed char( 1 ) NOT NULL default 'N',       // Было ли оно просмотренно
  message text NOT NULL,                       //  Само сообщение
  addTime datetime default '0000-00-00 00:00:00', // Дата добавления
  KEY getMessage (login_to, login_id)                   // Ключ от кого, кому
);

Стандартные действия при открытии окна сообщений
устанавливается флаг, что сообщения были прочитаны:
Код: plaintext
UPDATE z_message SET viewed='Y' WHERE login_to AND login_id;

открывается запрос всех сообщений в обе стороны
Код: plaintext
SELECT * FROM z_message WHERE (login_to AND login_id) OR (login_id AND login_to)

Ну и конечно же есть добавление сообщений.
В таблице ~200 000 записей, выборка очень тормозит.

Каким образом можно ускорить выборку из таблицы ?

Я вижу как один из путей решения сделать внешнюю таблицу
отношений логинов ID \ LOGIN_ID \ LOGIN_TO и запрашивать запросом через нее ID тем самым уменьшив эту таблицу. (Вопрос выйграю ли я, ведь index делает то же самое) ?

На какие еще ухищрения можно пойти ?

Подскажите плиз...
...
Рейтинг: 0 / 0
26.12.2005, 19:06:15
| Ответить | Цитировать | Написать  
Оптимизация таблицы личных сообщений
    #33458330
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Нариман
Код: plaintext
1.
2.
login_id varchar( 32 ) NOT NULL default '',   // От кого сообщение
login_to varchar( 32 ) NOT NULL default '',  // Кому сообщение

Первое, что бросается в глаза - строковые идентификаторы.
Сделай таблицу соответствия строковых и числовых идентификаторов (таблицу логинов) и из других таблиц указывай только ссылку на числовой идентификатор.
Оно будет более правильно идеологически и работать будет быстрее.

Код: plaintext
SELECT * FROM z_message WHERE (login_to AND login_id) OR (login_id AND login_to)

непонятен фрагмент login_to AND login_id

Второе - индексы в данном случае должны быть отдельно по полю login_to и по полю login_id.

Если сделать таблицу для логинов, то запрос будет выглядеть как
Код: plaintext
SELECT * FROM z_message WHERE login_to=my_login  OR login_id=my_login
Возможно, быстрее будет работать
Код: plaintext
1.
2.
SELECT * FROM z_message WHERE login_to=my_login  
UNION ALL
SELECT * FROM z_message WHERE login_id=my_login
...
Рейтинг: 0 / 0
26.12.2005, 20:13:56
| Ответить | Цитировать | Написать  
Оптимизация таблицы личных сообщений
    #33458343
Нариман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нариман
Участник
авторСделай таблицу соответствия строковых и числовых идентификаторов (таблицу логинов) и из других таблиц указывай только ссылку на числовой идентификатор.
Оно будет более правильно идеологически и работать будет быстрее.
Таблица логинов есть там я храню login varchar 32, в качестве primary key, как логин на сайт, вопрос в том если я создам id int auto_increment это ведь будет избыточным ключем по теории баз данных ведь так ?

заставлять запоминать пользователей 9 значную цифру в качестве логина то-же непорядочно :(

плюс к этому усложняются запросы допустим сейчас я выбираю 200 сообщений, там уже содержатся текстовые поля от кого и кому и сразу же выкидаваю в браузер. Иначе мне придется за каждым login_id лазить в users table или join то-же не мелкую таблицу :(

авторнепонятен фрагмент login_to AND login_id
сорри я так упростил себе написание кода

вот реальный пример
Код: plaintext
SELECT * FROM z_message WHERE (login_id='admin' AND login_to='user') OR (login_to='admin' AND login_id='user')

авторВторое - индексы в данном случае должны быть отдельно по полю login_to и по полю login_id.
это я уже прояснил для себя обычно используется либо login_to либо login_to AND login_id

авторВозможно, быстрее будет работать
Код: plaintext
1.
2.
SELECT * FROM z_message WHERE login_to=my_login  
UNION ALL
SELECT * FROM z_message WHERE login_id=my_login


База на хостинге 3.23 помоему там UNION еще не поддерживалось, плюс к этому сортировка должна быть единая...
...
Рейтинг: 0 / 0
26.12.2005, 20:34:30
| Ответить | Цитировать | Написать  
Оптимизация таблицы личных сообщений
    #33458373
Фотография 4m@t!c
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4m@t!c
Участник
>вопрос в том если я создам id int auto_increment
>это ведь будет избыточным ключем по теории баз данных ведь так
Нет. Это будет поле, которое однозначно идентифицирует пользователя. а логин - это часть учетной информации, в любом случае сделайте UNIQUE для логина + добавьте auto_increment-ное поле в качестве ключа, потому что поле длиной в 4 байта обработается быстрее, чем поле в 32 байта.

>заставлять запоминать пользователей 9 значную цифру
>в качестве логина то-же непорядочно :(
Ну, так и не заставляйте. при аутентификации вы определите ID пользователя - этим ID и манипулируйте. Для пользователя все будет прозрачно, он даже и не будет знать, что у него есть номер.

>Иначе мне придется за каждым login_id лазить в users table или
>join то-же не мелкую таблицу :(
Глупость.

ИМХО, разделить таблицу z_message на две. Одна хранит тексты, другая - информацию о мессаге. Связь по ID мессаги. Да, да и опять JOIN. Он работает гараздо быстрее, чем вы себе представляете.

----------------------------------------
Артисты не приехали, приехали цыгане
...
Рейтинг: 0 / 0
26.12.2005, 21:03:34
| Ответить | Цитировать | Написать  
Оптимизация таблицы личных сообщений
    #33458453
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DocAl
Участник
Советую последовать вышеприведённым рекомендациям, и если, всё же, проблемы с производительностью остануться, привести итоговую структуру таблиц, характерные запросы, и EXPLAIN для них.
...
Рейтинг: 0 / 0
27.12.2005, 01:35:09
| Ответить | Цитировать | Написать  
5 сообщений из 5, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Оптимизация таблицы личных сообщений
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=47&fpage=638&tid=1853244]:
 0ms
get settings:
 7ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 38ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 52ms
get tp. blocked users:
 2ms
others: 188ms
total:  322ms
созд. / загр.: 322ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]