Форум пользователей MySQL

Уточняю. (вы наверное вдоволь посмеялись прос 187 метров/час). Запииси будут быстро становиться лишними. и будут довольно быстро удаляться. То есть смысл будут иметь последние 1000 записей, например. Остальные удалять. Просто меня что сбивало с толку. id - мой первичный ключ хотя бы по той причине что на нём должен быть инкримент( если id не PK то автоматический инкримент создать я немогу.). В общем меня смущает ну например то что id больше заданного значения оно найдёт бысто( это же пк) но потом ему нада будет сделать n сравнений с записями от заданного id до максимально существующего. То есть n может быть 10 или 100 или 300. На некладно ли это ?.  Вобще существует ли возможность это как то оптимизировать или это иденственное что вобще можно сделать .
P.S. : что бы не было всяких домыслов и удивлений , я всего навсего пишу веб-чат.

Думаю, что запрос он выполняет так - сначала проверяет rid=1, а затем id>1. Попробуйте создать ключ в другом порядке KEY(rid,id), посмотрите будет ли использоваться. И посмотрите SHOW INDEX FROM table1\G

Подумайте над использованием ENGINE=MEMORY, в таком случае все будет храниться в памяти (но при перезагрузки сервера сохраняться не будет). Вы можете вести архив дополнительно в таблице MyISAM, а SELECT делать из MEMORY таблицы

paulus написал:

300 пользователей онлайн не могут генерить 100 инсертов в секунду...

Не уверен, что есть смысл использовать индекс вообще на таблице в 1000
записей в памяти. Обращение по индексу будет в любом случае медленнее
полного поска по таблице кроме случая вытаскивания 1-2 строк по ключу.
В случае вебчата Вы никогда не будете вытаскивать строки по ключу.

Если захотите делать ключик, учтите, что по-умолчанию в MEMORY-таблицах
ключ создается HASH, а не BTREE, что не позволит Вам делать сравнение
с использованием ключа. Для создания ключика BTREE надо это указать явно.

Спасибо. Всё учту. Хочу обьяснить своё сметение и желательно развейте его.

Запрос SELECT * FROM table1 where (rid = число_какоето_ни_суть_какое); к таблице без первичного ключа (таблица в памяти) будет быстрее запроса

SELECT * FROM table1 where(id > число and rid = число_какоето_ни_суть_какое) к таблице у которой будет первичный ключ с инкриментом ?

Все зависит от распределения значения ключа по таблице.

Пусть, например, у Вас есть таблица на 1000 записей, в которой
есть ключ на поле А, при этом каждая строчка в таблице уникальна.
Тогда выборка с WHERE A=VALUE будет использовать ключ наиболее
эффективно - достанет 1 строчку по ключу.

Рассмотрим противоположный пример: у Вас в таблице 500 записей
со значением 1, а 500 записей со значением 2. Тогда выборка WHERE
A=2 будет работать быстрее без использования индекса, т.к. это
приведет к меньшему количеству перемещений по диску (последовательное
чтение всегда быстрее).

Именно поэтому индекс не работает на поиске id>1.

question написал:

Вопрос из области любопыства : при ришении задачи как я пытаюсь решить (веб-чат) , при нагрузке ну допусти 100-300 пользователей онлайн - могут ли себя оправдать файлы ?

Можете использовать MEMORY таблицу - 300-500 человек в чате mysql свободно выдерживает. При большем количестве пользователей, разумно использовать в качестве хранилища сообщений memcached. При количестве пользователей >1000 уже начнет "загибаться" Apache (оверхед на переключения контента задач) и надо писать чат как http демон с неблокируемой обработкой сети (сискол poll/select/etc).