You can try restarting the database service or lower the connection limit in your application to 5.

Before restarting — high memory with low traffic is almost always InnoDB's buffer pool doing its job, not a leak. By default it's sized as a chunk of available RAM, not your actual working set, so MySQL claims memory upfront regardless of how quiet your 40 users are.

Quick way to check:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; — if this is close to what you're seeing as "usage," that's your answer.

SHOW STATUS LIKE 'Threads_connected'; — if this is high relative to actual users, something's leaking connections (pool not closing them), which also eats memory per-connection.

If it's the buffer pool: restarting won't help, it'll just refill. Fix is setting innodb_buffer_pool_size explicitly to match your dataset size instead of letting it default off total RAM.

Lowering max_connections to 5 (suggested above) only helps if connection sprawl is the actual cause — worth checking which one it is first before assuming.

first check whether the high memory usage is actually a problem or just MySQL using available RAM for InnoDB’s buffer pool.

'innodb_buffer_pool_size'

and create an index on columns that you frequently use for filtering, joining, or sorting.

Basic example:

"""

CREATE INDEX idx_users_email

ON users(email);

"""

Now a query like:

"""

SELECT *

FROM users

WHERE email = 'test@example.com';

""""

can use that index instead of scanning the entire users table.

Also don't just index every column because it can make INSERT/UPDATE operations more expensive.

and most important! check whether queries are returning more data than necessary. Avoid **SELECT *** where possible, use LIMIT and pagination for large result sets, and only fetch the columns/rows actually needed.