Как сделать структуру данных только для одного пользоват

Здравствуйте, подскажите как реализовать структуру данных когда только один пользователь использует только свои данные.
Например есть список дел id, datetime, text.
Почти каждый раз datetime будет изменяться и выборка будет происходить по нему.
Самый простой вариант сделать одну таблицу на 4 колонки: id, user_id, datetime, text при этом создать индекс по user_id и datetime. Но раз datetime почти при каждой выборки будет меняться значит и индекс пересчитается. Подозреваю такая реализация будет медленной.

Подскажите в какую сторону смотреть и можно ли сделать лучше.
Пользователей будет примерно 10,000 и для каждого со временем 1000-2000 записей.

upd:
нашел секционирование, может кто работал с mysql partition

 

Менять будет пользователь почти каждый раз как прочитает одну строку своих данных. Индекс после каждого изменения пересчитываться, по этому решил что решение в лоб будет медленным.
На счёт индекса, думаю что user_id поможет снизить время поиска, чтобы не затрагивать других пользователей, ихние данные ему не когда не понадобятся.

 

Вот есть база:

Код (Text):

1.  
2. CREATE TABLE IF NOT EXISTS `listtest` (
3.   `id` int(11) NOT NULL,
4.   `user_id` int(11) NOT NULL,
5.   `dt` datetime NOT NULL,
6.   `utext` text NOT NULL,
7.   KEY `uid` (`user_id`,`dt`)
8. ) ENGINE=InnoDB DEFAULT CHARSET=utf8

Самые ходовые запросы

Код (Text):

1.  
2. SELECT * FROM `listtest` WHERE `user_id` = '1' AND `dt` > NOW() LIMIT 1;
3. UPDATE  `listtest` SET  `dt` = NOW()   WHERE  `id` = '1' LIMIT 1;

Эти два запроса идут друг за другом от каждого пользователя в интервале 1-30 минут.
Тут я вижу узкое место: пересчёт индекса при каждом обновлении.

Все данные нужны и пометить "закрыта" нет смысла, просто список сортируется по дате.
Думаю тут подходит очередь сообщений, но для начала хотелось бы сделать на mysql.

По этому и спрашиваю, можно ли сделать как-то лучше.

 

Да выборка идёт по одной, но пользователей много и хотел что-то придумать, чтобы они не мешали друг другу.
Новая запись попадает по ситуации так как dt NOW() обычно в начало списка.

 

Они в конец очереди переходят. Всего при 20,000 записей на update уходит 0,01 сек и это всего в один поток.

 

Да старые нужны, они почти по кругу используются.
Убрал индекс по (user_id, dt) и стало в ~2-3 раза быстрее для update

 

Да, один пользователь смотрит свои данные по одной записи, потом их изменяет (время, на пару дней вперёд) и так дальше.

 

Это видимо недопонимание.
Я думал что выложу схему и запросы и этого будет достаточно.

Выбираю самую последнию потому что такой запрос SELECT * FROM `listtest` WHERE `user_id` = '1' AND `dt` > NOW() LIMIT 1;
нужна одна запись и самая последняя.

Похоже я допустил ошибку логическую, до других может добраться, вместо NOW() будет подставлена другая дата.

В теории узкое место было при UPDATE `listtest` SET `dt` = NOW() WHERE `id` = '1' LIMIT 1;
был индекс по user_id и dt я его убрал и update стал быстрее работать.
При всего 20,000 записей update занимает ~0,005 сек.

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

На счёт денег, я компенсирую ответами в других темах