it depends on how you've configured and how you currently use mysql.
i would start with the documentation:
What Is New in MySQL 5.6 [dev.mysql.com]
Changes in MySQL 5.6 [dev.mysql.com]
What Is New in MySQL 5.7 [dev.mysql.com]
Changes in MySQL 5.7 [dev.mysql.com]
What Is New in MySQL 8.0 [dev.mysql.com]
Changes in MySQL 8.0 [dev.mysql.com]

The only problem i had with upgrading from 5.5 to 5.7 was the calculation of the auto increment fields. If you have queries like "insert into .. on duplicate key update...", you get holes in your auto increment fields. More info here [dev.mysql.com...]

Thanks, @phranque, I tried reading through those before posting but it's a TON of data! And most of it seems kind of irrelevant, so it's easy to overlook something.

The main things I see that could potentially affect a normal user are:

1. 8.0 uses STRICT by default. I honestly have no idea if all of my code is written "strictly", so it's a gamble to move everything over only to discover errors.

2. GROUP BY... ASC / DESC (without using ORDER BY), ENCODE, DECODE, and ENCRYPT are removed. I don't think I use those anywhere, so I think I'd be OK.

3. @bhukkel, it's my understanding that AUTOINCREMENT is only affected if you use InnoDB, FLOATs and DECIMALs, right? Not if you use MyISAM, or if you use INT for the type?

Any suggestions on how hard it would be to revert backwards from 8.0 to 5.7 if I try it and it's a huge mistake?

Hello,

I do not have an answer about it, because I am using MariaDB and had no issue switching.

I've only briefly read about MariaDB, and I understand that it's consistently faster on pretty much every type of query. And it's a direct drop-in, so no modification of PHP scripts is necessary? I could be very easily convinced to use it, I just need to figure out how to set it up and everything. I may give it a shot, and if I get lost then I'll make a different thread on that one...

Any suggestions on how hard it would be to revert backwards from 8.0 to 5.7 if I try it and it's a huge mistake?

Then again, if it's not a huge mistake, just some minor stuff, wouldn't the latest and greatest be the best of all outcomes?

This falls into the "you'll never know until you try it" category. If your code is as lean as it appears to be, it might be worth the effort. Only you can decide that.

In theory, yes! But like I discovered that all of my sites using MySQL would just die if I updated them to PHP 7.x without changing them to MySQLi, I wanted to avoid that mistake again.

I updated my new server to MariaDB 10.3.27 (the reviews sound awesome), and NOW it says that downgrading is "unsupported" :-O

Please note that downgrades to previous versions are unsupported. After you upgrade your system to a newer version, it may be impossible to switch back.
Also note that since MariaDB is installed, moving to MySQL 8 is considered a downgrade, and therefore not supported.

So now I just have to hope that it's relatively seamless...

The problem is, when you rely on an old version of a software or OS, at some point this software will stop being supported and updated, and this can lead to bigger problems, on a long term.

I'm usually more of a fan of, "if it ain't broke, don't fix it". Especially when it comes to updating client's sites that aren't willing (or able) to pay me to rewrite scripts for them to match the more recent criteria. Like having to modify 100+ websites that I wrote to use MySQL instead of MySQLi, but now I have to do it to update to PHP 7.4 :-(

Security updates are one thing, but removing functions when they could have simply written functions in the new release to allow for them? That's just frustrating. So I typically push off these updates until I have time to kill to deal with the fallout, or until I just have no other choice in the matter.

I just discovered a rather major issue with switching to MariaDB. It's probably in the docs but I overlooked it.

With my old system, I relied on the database to truncate long fields for me; eg, the user might enter a title that's 100 characters long, but MySQL was set to varchar(50, so it would truncate to 50 characters.

Using Perl's DBI module to run MySQL commands, I discovered that when someone submitted a title longer than 50 characters then the script would try to write it, throw a warning, but not die and it would move on. So nothing in the error log, and to the user it looked like it had gone through... but it didn't, and there was no record of it on my end.

This seemed to fix it, but I don't know if it's a "fix" or a temporary patch:

# /etc/my.cnf
# default for sql-mode, if undefined, is:
# STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
#
# At least remove STRICT_TRANS_TABLES to fix this, but
# allegedly none of it is necessary
sql-mode=''

relied on the database to truncate long fields for me

An old rule (long before there were online databases!) was ALWAYS VET/RESTRICT entry to any field BEFORE IT HITS THE DATABASE. Validate the data before it is submitted and 99.9% of potential errors never have a chance to create havoc!

Learned that the hard way back with DB2, Rbase, Dbase III, etc ... in the 1980s...