The QGIS Expressions engine behind labels, data defined symbology, rule based rendering filters, field calculator... is the same .
The whole expressions engine is quite powerful (and is one of the parts of QGIS that receives an impressive stream of improvements with each and every QGIS release). It is very close to SQL when it comes to calculating things.
The main difference to a lot of SQL implementations is, that it doesn't implement any parts of DDL, TCL or DCL. It only implements a subset of DML, in particular the part for calculations. While I don't think someone ever reviewed its complicance with SQL-standards it should be close enough to port knowledge.
[...] does that mean it's SQL based or am I better writing expressions in something else, MySQL?
That's a tough question with no general answer.
Some points to consider:
- Sometimes you are not able to replace it by something else (try running SQL on a shapefile).
- Sometimes you want it to be portable (QGIS expressions produce the same result regardless if you use a postgis or a csv as data provider)
- Sometimes you don't have access to the database server to define views or modify data to your needs.
- It's just so much easier to build an expression than to define a view
- Sometimes you need to aggregate data from different tables (Note: that's possible with QGIS expressions, but performance is reduced compared to server side calculations)
- There may be other considerations imposed by your environment or requirements.
What to do?
Try your way through the expressions. If you regularly work with QGIS you WILL want to use them. Make them your everyday swiss army knife tool. Just keep in mind that once in a while you will need to solve tasks with something else. If that's the case, you will know ;)
 There are some minor differences depending on the context. For example some variables are only available in certain contexts like variables for the current symbol are only available during rendering and not in the field calculator.