The suggestions you receive will be based on the data you provide from your system.
(After analysis of your GLOBAL STATUS and GLOBAL VARIABLES data from your system. Your specific server's analysis results will likely be ONLY similar).
Suggestions for your my.cnf OR my.ini [mysqld] section
or your AWS Aurora Parameters group
or your AWS RDS Parameters group
or your Azure portal, SETTINGS, Server parameters
or your Google Cloud Database flags
time saving tip for you, place at the END of [mysqld] section to replace old requests.
Last one processed, will be used for the instance.
Leave old values by leading the LINE with # and space character followed by ccyymmdd hh:mm - for example # 20181211 11:45 and you will have a history of all changes, in chronological order.
To avoid long term confusion (and lose your chronological history), you may wish to retain only the LAST used variable to avoid multiple lines with the same named variable in your my.cfg or my.ini.
Your my.cnf likely includes 4 lines that should be removed preferably (or disabled with leading # and space character, they are A) sort_buffer_size B) read_buffer_size C) read_rnd_buffer_size D) join_buffer_size - these are all per connection RAM requirements and may be driving your RAM footprint much higher than necessary.
Let the DEFAULTS work for you to improve response time with room to breathe in RAM.
Consider adjusting the following in your my.cnf OR my.ini [mysqld] section, please
key_buffer_size=512M # from 1G because 200M is used now
innodb_buffer_pool_size=4G # lesser of =< 65% RAM OR
(Data in Innodb tables * 1.4 ) reported by MySQLTuner
max_connections=100 # from 500, until more than 8 are used
thread_cache_size=100 # from 192 MySQL see v 8 refman
that recommends CAP of 100 to avoid OOM crash
query_cache_limit remove to allow default of 1M rather than 32M
query_cache_min_res_unit=512 # from 4K to store more RESULTS in QC
table_open_cache=10000 # from 2000 to support ~ 28,000 tbls opened
No more than one SUGGESTION per day to be applied, monitor.
Many of these variables may be DYNAMICALLY modified (with SET GLOBAL variable_name=xxxx;) and will be in effect AFTER the NEXT User Login for the sessions they run.
Updating your active my.cnf OR my.ini [mysqld] section will be applicable AFTER services shutdown/restart of your instance for this server.
Refer to your user manual for details.
Our 4 business day clock STARTS when you have emailed your links
as requested at the end of "Data We Need".
If we can not read/use your data, we will attempt to reach you via
your email address with specifics on TEXT data requirements and the
4 business day START date/time will be reset when new links are provided
and we can read/use your data.