I've been playing on a large MP server which stresses aspects of the game in relation to, I believe, the Entities table in the database. This table appears to be a row/column implementation of an object model which allows Entities to contain many types of objects that share common properties. Although I don't have access to the server db it's clear from the entity id values (>2.5M) that the cardinality of the table makes it a potential performance/memory hog. There are significant problems with porting an OO model into a relational db (read: "why did the Microsoft entity framework fail to gain traction in real-world production systems?") that have to do with how the resulting db physically organizes the data and performs indexing. Since this table is probably a 1-to-1 with something in the program data structures it may be difficult to refactor the model to tease out the tables implied by the etype id values in order to create a 3rd normal form solution. Another option (or stopgap) would be conditional indexing using the WHERE clause on etype. This allows the resulting index to act as a surrogate table for the restricted subset of rows ... suggestion: If you know you have specific queries that are causing problems then creating, on a case-by-case basis, indexes using WHERE (etype=n) may improve lookup time and reduce locking.
