If loading one character takes dozens of separate queries, tens of thousands of simultaneous logins turn into millions of queries.
Why Character loading queries items, skills, and quests one by one → Effect Simultaneous logins right after maintenance make the query count explode → On screen Infinite loading at login, and even saves for players already in the game get held up
Primary owner Game team (Server development) · Also Infra team (DB infrastructure)
Game team action items
Fetch in batched queries, use a login queue and caching, check how many queries ORM lazy loading generates.
Infra team action items
Pull a ranking of the most frequently called queries and share it, monitor query and connection counts during the login window right after maintenance.
On the graph
Surge after opening · DB queries per second, login count
Where to look
Overlay the login count right after maintenance with the DB’s queries per second (growth of Questions in MySQL) and compute queries per login. Pull the most frequently called queries from COUNT_STAR in MySQL events_statements_summary_by_digest or calls in PostgreSQL pg_stat_statements
Confirmed if
Dozens of queries per login, and the top queries are short queries of the same shape that look up by a single character ID. If queries per login went up after a patch, that patch is the starting point
Ruled out if
Few queries per login but each one is slow: cold cache (db-cold-cache) or indexes (db-no-index)
Check with
Infra tools (no game code needed)
Learn more
Lazy loading in an ORM (a library that builds DB queries for you) generates queries like these without developers even noticing. On a dev server with only a few characters it goes unnoticed, and it first shows up with simultaneous logins on live servers.
Sources
Efficient Querying.NET ORM lazy loading creates the N+1 problem, sending one more query per item and badly hurting performance; recommends loading in one batch (eager loading)