Hey there! We've found the following might help you get unblocked faster:

• 🧵 asd

If you find the answer from one of these, please let us know by solving the thread!

I'm not very experienced with MySQL, but shouldn't you do:

SHOW GLOBAL  VARIABLES LIKE 'wait_timeout';

I think this is about scoping, session vs global. PostgreSQL has the same concept. You're changing the global variable, but when you do SHOW 'wait_timeout' , you're looking at your session variable still.

And for something that survives restarts, you probably want SET PERSIST?
See: https://dev.mysql.com/doc/refman/8.4/en/persisted-system-variables.html

## SOLVED - The issue was SESSION vs GLOBAL variable scoping

  Thanks to everyone who helped! The problem has been resolved. Here's what happened for anyone

  encountering similar issues:

  ### The Problem

  I was using SET GLOBAL to modify parameters but checking with SHOW VARIABLES, which shows

  SESSION values by default, not GLOBAL values. This made it appear that the parameters weren't being

  changed.

  ### What I was doing wrong:

  ```sql

  SET GLOBAL wait_timeout = 14400;        -- Setting GLOBAL variable

  SHOW VARIABLES LIKE 'wait_timeout';     -- But checking SESSION variable (wrong!)

  -- Result: Still showed 28800, thought it failed

The correct approach:

  SET GLOBAL wait_timeout = 14400;        -- Setting GLOBAL variable  

  SHOW GLOBAL VARIABLES LIKE 'wait_timeout';  -- Check GLOBAL variable (correct!)

  -- Result: Shows 14400, success!

Key Learning:

  - SHOW VARIABLES = Shows SESSION values (current connection)

  - SHOW GLOBAL VARIABLES = Shows GLOBAL values (affects new connections)

  - SET GLOBAL changes don't always sync to current session

Verification Script:

  -- Check both SESSION and GLOBAL to understand the difference

  SELECT 'wait_timeout' as param,

         @@global.wait_timeout as global_value,

         @@session.wait_timeout as session_value,

         CASE WHEN @@global.wait_timeout = @@session.wait_timeout

              THEN 'Synced'

              ELSE 'Different - new connections will use GLOBAL'

         END as status;

Result:

  Railway MySQL doesn't actually restrict these parameters! All the following work perfectly:

  - max_connections

  - wait_timeout

  - tmp_table_size

  - max_heap_table_size

  - long_query_time

  - innodb_io_capacity

  The confusion was purely due to checking SESSION values instead of GLOBAL values.

  Thanks again to @[username] for pointing out the SESSION vs GLOBAL distinction - that was the key

  insight that solved everything!

  Hope this helps anyone else who encounters similar "parameter won't change" issues. Always remember

  to check GLOBAL variables when using SET GLOBAL!