Follow the current source for your installed revision
Use Overextended’s current OxMySQL documentation and release source rather than assuming an old fork or archive has the same behavior. Keep the installed version, database engine version and consuming resources in your installation record.
The reviewed setup guide places the connection string before resource startup and oxmysql near the top of the resource list. It uses set for mysql_connection_string and imports @oxmysql/lib/MySQL.lua before other server scripts in a Lua consumer. Keep credentials in your private server configuration, not client files.
This guide does not supply database credentials or a complete server template. Match the database and schema requirements of your actual framework and packages before planning installation or migration work.
Import the library before your server-side consumer
The excerpt below belongs in the consuming resource’s manifest alongside its other required declarations. It is not a client import or a substitute for installing the dependency. Preserve your resource’s existing manifest structure.
server_script '@oxmysql/lib/MySQL.lua'
server_script 'server.lua'Use a table-free read check to isolate connectivity
OxMySQL documents MySQL.scalar.await for a single value and parameter binding through a separate values table. The original example below asks the database to return a literal through that API. It does not access player tables, alter a schema or write gameplay records.
Run this only from a controlled server-side staging resource after the dependency is ready. A result of 1 establishes this small request completed; it does not prove that your resource’s tables, permissions or save workflow are correct. Magnate has checked the API shape against the documentation, not executed the snippet on a FiveM database.
local probe = MySQL.scalar.await('SELECT ? AS probe', { 1 })
print('OxMySQL read probe returned expected value:', probe == 1)Separate connection, query and gameplay failures
Use the proposed matrix below to locate the first failing layer. Preserve the exact error privately and share only the redacted details needed for support. Do not change a schema to repair an authentication failure.
| Layer | Check | What success alone does not prove |
|---|---|---|
| Resource startup | Dependency and import load without the relevant error | A database request can complete |
| Connection | A controlled read request completes | Gameplay tables exist |
| Schema | The owning resource’s expected tables and fields match | Its save logic runs |
| Query result | Consumer handles the documented return shape | State survives reconnect |
| Gameplay persistence | A controlled state change returns after reconnect | Every historical record migrated correctly |
Check result shape before rewriting a query
The scalar reference returns the first column of one row. The query reference returns matching rows and columns for a select. Choose the API and consumer logic for the result you need instead of treating a table of rows as one scalar value.
For a missing record, distinguish no matching row from a connection error and from a field read at the wrong nesting level. Use one synthetic staging record and retain the expected result. Do not concatenate untrusted values into SQL when the API supports bound values.
If an update changes an API or return representation, rehearse the consuming feature against the new version. A resource starting cleanly is weaker evidence than its actual read and save workflow passing.
Investigate slow-query warnings with context
The setup documentation notes that slow-query timing may be affected by server hitches and that startup warnings are not necessarily a database problem. It also supports resource-scoped debug output. A warning is a lead for investigation, not a complete diagnosis.
Record when the warning occurs, its originating resource and whether it repeats under a controlled action. Compare the relevant query and workload before changing global thresholds. Avoid suppressing the symptom and calling that a performance improvement.
Debug output may include query values. Use synthetic data on staging and keep logs private until redacted. Do not post complete configuration strings or player records in public support channels.
Validate persistence and upgrades against the owning resource
Before a planned update, retain a recoverable copy and rehearse the actual migration instructions in staging. Compare existing records as well as newly created records. A fresh installation passing a test does not establish preservation of historical data.
For a vehicle, inventory or housing issue, trace the state from gameplay action through the owning resource’s save operation to its later retrieval. Avoid inventing a universal table name or running SQL copied from an unrelated framework.
Use the server.cfg guide for active configuration and the inventory or housing guides for feature-specific acceptance checks. This article has not connected to your database, changed any saved records or established GTA VI compatibility.
Questions, answered.
Does installing OxMySQL create every framework table?
No. Follow each consuming resource’s own schema and migration instructions. Connectivity and resource schema are different requirements.
Does this read probe change player data?
No. It selects a bound literal without reading or writing player tables.
Does a slow-query warning prove the database is the cause of lag?
Not by itself. The reviewed setup documentation notes timing and server-hitch caveats; investigate the originating resource and reproducible workload.
Sources & editorial notes
Source review: November 7, 2026. Platform announcements can change. This guide separates published facts from Magnate’s original analysis and preparation advice.
- Overextended — OxMySQL setup Resource order, server-side import and diagnostics; reviewed November 7, 2026.
- Overextended — OxMySQL scalar Scalar await API and bound value examples.
- Overextended — OxMySQL query Query result shape differs from a scalar result.
Published by an independent editorial brand. Read our editorial standards.
