Opened_tables, but itself is not very interesting; Opened_tables / Uptime -- it would be good if this is less than 1/sec.
> I may have to increase table_cache value.
Don't bother. The lookup algorithm is linear; it needs to be hashed (and may someday be). Meanwhile, a huge table_cache (say >1000) is less efficient than a smaller one (say 300). Remember, it is a "cache". I agree with paul that this probably the metric to see if table_cache is "ok": Opened_tables / Uptime.
I did not not give table_cache a very prominent status in
http://mysql.rjweb.org/doc.php/memory
because I don't think it is that important. I almost never encounter a machine where the table_cache value is causing trouble.
> I've been trying to find out exactly what table_cache does cache, but haven't had much luck.
I don't know exactly. I think it holds some info about a table for a connection/query/join/whatever. It probably occupies a fixed amount of RAM. In multi-GB machines, the space for a few hundred table_cache entries seems to be insignificant.
> holds open full tables in memory.
No. Data and indexes are cached in key_buffer, buffer_pool, and the OS. (Details in a reply I wrote minutes ago.)
> then the system will use swap, which is very slow
YES!!
Usually, decreasing key_buffer_size and/or innodb_buffer_pool_size is easiest and best when you blow out RAM.
This is a long-winded thread; if I missed any "bits and pieces", please repeat them.