Таблица выглядит так:

CREATE TABLE IF NOT EXISTS `map` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`userID` int(11) NOT NULL,
`objectID` int(11) NOT NULL,
`positionX` int(11) NOT NULL,
`positionY` int(11) NOT NULL,
PRIMARY KEY (`ID`),
KEY `userID` (`userID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1057669 ;

Количество записей - 1057668
Данные 53.6 МБ
Индекс 14.5 МБ
Всего 68.1 МБ

Выполнение запроса вида "UPDATE map SET positionX=12 WHERE ID=777" на базе с нулевой нагрузкой происходит за 0.06-0.08 сек. Можно ли как-нибудь сократить это время, или это объективный предел (в смысле, оптимизировать тут просто нечего)?

В будущем планируется, что в таблице будет 40-50 млн. записей. Будут ли какие проблемы со скоростью апдейта? Индекс, по идее, вырастет примерно в 50 раз, т.е., составит 750Мб. Подозреваю, если по какой-то причине он не поместится в память (это не единственная таблица в БД), время апдейта увеличится существенно? Что можно предпринять заранее?

Ну, как сказать...

...
PRIMARY KEY (`ID`),
...

В апдейте:
UPDATE map SET positionX=12 WHERE ID=777

AkinaА каким боком тут ваш этот индекс? Используемый индекс (который PRIMARY KEY (`ID`) ) - он вообще кластерный и места на диске не занимает

Да, так и оказалось. Удалил второй индекс и действительно ноль.

Так какое резюме? 50 млн - чепуховый объем и мне даже не париться на этот счет?
Текущий размер таблицы на диске 53.6Мб, в 50 раз больше - примерно 2.5Гб.

Это просто пример запроса. Любое число от 1 до миллиона, результат тот же.

Cygapb-007Возможно, я и не прав, но (ПМСМ) поле ID в таблице MAP не может быть получено ниоткуда, кроме самой этой таблицы. Тогда каким образом в программе можно узнать, что нам требуется именно строка с id=777?

Сервер обрабатывает пакеты действий, присланные клиентом. Сначала действия накатываются на модели, если все действия валидны, измнения модели отражаются в базе. К моменту сохранения изменений модели в базе все первичные ключи всех записей, которые нужно проапдейтить, известны. Просто потому что они есть в модели.

Cygapb-007Но на вопрос, откуда в модели возник номер 777 — вы так и не ответили :)


Сейчас модель считывается из БД перед обработкой пакета запросов.

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

Cygapb-007Где-то в интерфейсе осущестляется связка по user_id и object_id с данными этой таблицы, вносятся изменения в какую-то строку, и в сервер посылается запрос на изменение по id этой строки (вместо изменения по user_id и object_id). Не совсем логично - ну да пусть его, это ваш проект.

На самом деле, идея не моя, но суть пакетной обработки действий через модель заключается как раз в том, что сокращается количество апдейтов бд, поскольку не пишутся промежуточные варианты. Например, пользователь userID передвигал объект objectID в перемешку с другими действиями 10 раз. Если каждому его действию будет соответствовать один запрос, то это будет 10 апдейтов. А при прогонке через модель - только один. То же самое, например, при покупке разных предметов на склад. При стандартной схеме у нас на каждую операцию один апдейт баланса в таблице пользователя и один инсерт/апдейт в таблице склада. При пакетной обработке 10 запросов на покупку разных предметов на слад у нас только один апдейт баланса в таблице пользователя и гарантированно не больше инсертов/апдейтов в таблице склада (позиции с одним itemID будут объединены в один инсерт/апдейт). А, например, в случае, когда предмет покупается на склад, а потом идет в производство, то при пакетной обработке таблица склада вообще не трогается, а при стандартном подходе - сначала будет запись прихода в таблицу склада, потом запись списания.

Короче, не все так очевидно, как кажется на первый взгляд.