How to audit your MU Online server's economy with SQL

A MU Online server's economy is a living organism: Zen enters through monster drops and leaves through fees and upgrades; rare items are printed by bosses and destroyed in refinement failures. When that flow is healthy, the server thrives. When a duplication bug (dupe), a drop exploit or a compromised account injects artificial value, the economy inflates, prices spike and honest players abandon the server. Auditing the economy with SQL is the most direct and reliable way to see what is happening beneath the game — without depending on reports or luck. This tutorial shows, at an advanced level, how to write queries to detect duplicated items, inflated Zen and anomalous accounts, and how to turn that into periodic reports.

The principle that guides every economic audit is conservation: in a healthy economy, what exists should be explained by what was generated minus what was destroyed. When a value appears with no origin — Zen no one farmed, a rare item in a quantity larger than what has ever dropped — you have a symptom. The queries below exist to find those unexplainable values quickly.

Prerequisites

• Read access to the server's database (SQL Server, MySQL or whichever DBMS your emulator uses).
• A query tool: SQL Server Management Studio, HeidiSQL, DBeaver or similar.
• Ideally, a replica or a restored backup to run heavy queries without impacting production.
• Knowledge of your emulator's schema: the names of the account, character, inventory and warehouse tables.
• Permission to create objects (views, snapshot tables) if you want to automate reports.

> Warning: all the table and column names below (AccountCharacter, Character, warehouse, Money, Serial) are examples from the Season 6 line and derivatives. The real schema varies by emulator. Always check the mapping before running any command, especially those that modify data.

If you are still building the database infrastructure from scratch, the guide on how to create a MU Online server covers the base DBMS installation before you reach the auditing part.

Golden rule: never audit with UPDATE or DELETE

Auditing is a read activity. Every query in this tutorial is a SELECT. You investigate, export evidence and only act afterward — and even the action should prefer freezing/isolating over deleting. Running DELETE or UPDATE during an investigation destroys the very trail you are trying to reconstruct. If you need to fix something, do it in a separate, documented step, and always with a backup taken immediately before.

Step 1: map the Zen in circulation

The first indicator of economic health is the Zen distribution. Start by measuring the total and the concentration. If a few accounts hold most of the server's Zen, or if the total grows faster than the player base, something is wrong.

-- Total Zen on the server (characters + warehouse)
-- Example column names: Money on the character, Money in the warehouse
SELECT
    (SELECT SUM(CAST(Money AS BIGINT)) FROM Character)  AS zen_characters,
    (SELECT SUM(CAST(Money AS BIGINT)) FROM warehouse)  AS zen_warehouses;

Next, see who concentrates the Zen. A long, smooth tail is normal; an abrupt step (an account with orders of magnitude more than the runner-up) is suspicious.

-- Top 20 characters by Zen
SELECT TOP 20
    Name,
    AccountID,
    Money AS zen,
    cLevel AS level,
    ResetCount AS resets
FROM Character
ORDER BY CAST(Money AS BIGINT) DESC;

> Interpretation: compare the top with the effort. A character with sky-high Zen but low level and resets didn't farm it — they received it, bought it from a dupe or exploited a bug. The mismatch between wealth and progression is one of the most reliable signs of an anomaly.

Step 2: detect inflated Zen over time

An absolute number says little without history. The robust way to detect inflation is to compare snapshots. Create a snapshot table and feed it periodically (ideally through a scheduled job).

-- Economic history table (create once)
CREATE TABLE EconomySnapshot (
    snapshot_date   DATETIME       NOT NULL DEFAULT GETDATE(),
    total_zen       BIGINT         NOT NULL,
    total_accounts  INT            NOT NULL,
    active_accounts INT            NOT NULL
);

-- Periodic insertion (run via a daily job)
INSERT INTO EconomySnapshot (total_zen, total_accounts, active_accounts)
SELECT
    (SELECT SUM(CAST(Money AS BIGINT)) FROM Character),
    (SELECT COUNT(*) FROM MEMB_INFO),
    (SELECT COUNT(*) FROM MEMB_INFO WHERE ConnectStat = 1);

With accumulated snapshots, compute the variation. What matters is not the total Zen, but the Zen per active account: if it rises consistently, there is more money chasing the same items — inflation.

-- Zen per active account over time (detects inflation)
SELECT
    snapshot_date,
    total_zen,
    active_accounts,
    total_zen / NULLIF(active_accounts, 0) AS zen_per_active_account
FROM EconomySnapshot
ORDER BY snapshot_date DESC;

An abrupt jump in zen_per_active_account between two consecutive days, without an official bonus event, is the classic sign of a Zen dupe or a drop exploit. Prioritize investigating the time window in which the jump occurred.

Step 3: detect duplicated items

Dupe detection depends on how the emulator stores items. There are two scenarios:

Scenario A — the emulator has a unique serial per item. This is the ideal case. A serial repeated in different places is direct proof of duplication.

-- Items with the same serial appearing more than once (direct dupe)
-- Assumes a normalized item table with a Serial column
SELECT Serial, COUNT(*) AS occurrences
FROM ItemInstance
GROUP BY Serial
HAVING COUNT(*) > 1
ORDER BY occurrences DESC;

Scenario B — items are blobs in the inventory/warehouse (no serial). This is the most common case in classic emulators: the inventory is a binary/hexadecimal field. Here you don't detect by serial, but by excess volume and patterns. The idea is to compare how many copies of a rare item exist against how many could plausibly have dropped.

-- Count of a specific rare item in every player's warehouse
-- Searches the item's hex signature inside the warehouse blob (example)
SELECT COUNT(*) AS total_found
FROM warehouse
WHERE Items LIKE '%<ITEM_HEX_SIGNATURE>%';

If a level 3 wing that only drops from a weekly boss, dropped perhaps 10 times in the server's history, shows up in 60 warehouses, you have duplication — regardless of whether there is a serial. The volume doesn't add up with the issuance. Record the hex signature of each rare item in your own catalog to make this check fast and repeatable.

Step 4: hunt anomalous accounts

Problem accounts usually stand out in at least one dimension off the curve. Cross-reference account age, wealth, playtime and progression.

-- New accounts with disproportionate wealth (possible dupe recipient)
SELECT
    m.memb___id     AS account,
    m.RegDate       AS created_at,
    c.Name          AS character,
    c.Money         AS zen,
    c.ResetCount    AS resets
FROM MEMB_INFO m
JOIN AccountCharacter a ON a.Id = m.memb___id
JOIN Character c        ON c.AccountID = m.memb___id
WHERE m.RegDate > DATEADD(DAY, -7, GETDATE())   -- account less than 7 days old
  AND CAST(c.Money AS BIGINT) > 1000000000       -- example threshold: 1 billion
ORDER BY CAST(c.Money AS BIGINT) DESC;

Another useful pattern: several accounts with the same IP or created in the same short window, concentrating rare items — typical of a dupe ring or mule accounts.

-- Multiple accounts sharing the same registration IP (example)
SELECT IP AS registration_ip, COUNT(*) AS account_count
FROM MEMB_INFO
GROUP BY IP
HAVING COUNT(*) > 5
ORDER BY account_count DESC;

> Watch out for false positives: LAN houses, families and carrier-grade NAT legitimately share an IP. A repeated IP is a clue, not a conviction. Always corroborate with another signal (wealth, rare items, timing) before acting.

Table of indicators and thresholds

Use the table below as a mental dashboard. The thresholds are examples and should be calibrated to your server's size.

Step 5: turn auditing into a periodic report

Auditing once protects no one; the value is in the repetition. Consolidate the main queries into a view and schedule the snapshot collection. That way, each day generates a history line you can compare.

-- Daily economic summary view (quick read)
CREATE VIEW vw_EconomicSummary AS
SELECT
    CAST(GETDATE() AS DATE)                                   AS ref_date,
    (SELECT SUM(CAST(Money AS BIGINT)) FROM Character)        AS total_zen,
    (SELECT COUNT(*) FROM MEMB_INFO)                          AS accounts,
    (SELECT MAX(CAST(Money AS BIGINT)) FROM Character)        AS highest_individual_zen;

Schedule the daily snapshot insertion via a DBMS job (SQL Server Agent, a MySQL event or an external task — varies by emulator and OS). With the history in hand, a simple chart of zen_per_active_account over the weeks reveals trends that no one-off inspection would show.

Common errors and fixes

Audit checklist

• Backup or replica available to run heavy queries safely
• Emulator's real schema mapped (account, character, warehouse tables)
• All investigation queries are read-only (SELECT)
• Economy snapshot being collected daily and stored
• Catalog of rare items' hex signatures created and kept updated
• Top Zen and rare volume reviewed and compared with expected issuance
• Anomalous accounts identified and frozen before any punishment
• Evidence (balances, items, logs, IPs) exported and documented
• Deep manual review scheduled weekly
• Extra audit planned after big events and updates

Frequently asked questions