This is a difficult area. The “thresholds” that will affect each of the three categories overlap.
If you have problems with operations related to the CPU, you should definitely look at: (a) The structure of your database - is it fully normalized. The poor database structure leads to complex queries that fall into the processor. (b) Your indexes are all that is needed for your indexed queries. The lack of indexes can hit both the processor and memory VERY severely. To check indexes, execute "EXPLAIN ... your query." Any line in the received explanation that says that it does not use an index, you need to carefully and possibly add the index. (c) Use prepared statements where possible. They can save the processor a pretty crunchy one. (d) Use the best compiler with optimizations appropriate for your processor. This is one for selected types, but it can count you extra percentage here and there.
If you are having trouble transferring read operations (a) Make sure you cache where possible. Check the configuration variables for query_cache_limit and query_cache_size. This is not a magical solution, but a raise can help. (b) As above, check your indexes. Good indexes reduce the amount of data that needs to be read.
If you are having problems with your write operations (a) See if you need all the indexes that you currently have. Indexes are good, but the tradeoff for improving query time is that maintaining these indexes can affect the time taken to write data and keep it up to date. Usually you want indexes when in doubt, but sometimes you are more interested in writing letters to a spreadsheet than you are reading. (b) Make it possible to use INSERT DELAYED to write a “queue” to the database. Please note that this is not a magical fix and is often inappropriate, but under the right circumstances can help. (c) Check tables that are heavily read and written at the same time, for example. an access list that constantly updates the visitor’s session data and is read from all of this. It is easy to optimize a table for reading and writing, but it is actually impossible to create a table that is good for both. If you have such a case and this bottleneck, consider whether it is possible to separate its functions or move any complex operations using this table to a temporary table, which you can periodically update as a block.
Note. The only thing outlined above that has a big effect is a good query design / indexing. In addition, you want to start your review with more advanced equipment. In particular, you can greatly benefit from the RAID-0 array, which does not do much to write related problems, but can work wonders for reading-related problems. And it can be a pretty cheap solution for a big boost.
You also missed two objects from your list.
Memory limit. If you run into memory problems, you should check for everything that can be usefully indexed, indexed. You can also look at larger pooling if for some reason you are using a lot of discrete connections to your database.
Network binding. If you run into network problems ... well, you probably don't, but if so, you need a different network card or a better network.
Note that a convenient way to analyze the performance of your database is to enable the log_slow_queries parameter and set long_query_time to 0 to get everything, or 0.3 or similar, to catch anything that might contain your database. You can also enable log-queries-not-using-indexes to find out if something interesting appears. Note that such a log might kill a busy live server. Try in the development window to get started.
Hope this helps. I would be interested to know about the comments above.