Феникс, почему? Я, конечно, давно уже с БД не связывался, но суть в том, что на БД приходит запрос и согласно этому запросу БД отрабатывает. Чем меньше информации требуется в запросе - тем быстрее.
Это не всегда так. Если у тебя 2 коротких записи, но одну из них ты будешь отфильтровывать через кучу сложных условий, выборка без условий может сработать и быстрее. К тому же, в нашем случае это не бд, а симуляция, все данные хранятся в оперативной памяти, что только усугубляет разницу (выборка много быстрее происходит и не является самым узким местом).
При реализации того, что ты предлагаешь:
1) Надо хранить опции клиента на каждой ноде, и или передавать их при смене сессии, или перезапрашивать у клиента на каждый пропрыг (тот же "паразитный", или служебный траффик)
2) При отсылке состояний о объектах в гриде проводить дополнительную проверку для каждого объекта для каждого клиента, чтобы отсылать клиенту только то, что нужно, и делать это каждую секунду. Сейчас эта проверка не проводится вообще - отсылается все, что находится в гриде не в клоке (и в случае с клокой, кстати, корабли не показываются гангмейтам по этой же причине имха, чтобы не плодить проверки).
Я последние 3 месяца работаю (вернее, работал, последние пару недель забиваю) над проектом на питоне, в котором данные хранятся в памяти, зато в рабочем режиме из них получаются миллионы объектов, и каждая переменная, жрущая память, или каждая дополнительная проверка в частоиспользуемых методах приводит к заметным потерям производительности. Да, одна операция вместо 2 микросекунд будет жрать 2.1, но когда прогоняешь бенчмарк с нормальным рантаймом на 37 секунд на моей машине, и видишь, что получилось 39, или даже 41 - понимаешь, что лучше такого дела избегать.