Table cache hit rate as low as 20% can be absolutely devastating for performance. On a very busy, high throughput system that is otherwise reasonably well tuned, I have seen goodput collapse happen due to table_open_Cache not being high enough at over 90% hit rate. Given how cheap this cache is, you don't tune it for cache hit rate, you tune it so that overflows don't happen.
If that is not possible due to some other absurdity on the system (for example, I have seen database systems with over 1M tables on a single server, arising from the one-database-per-customer on a shared host anti-pattern), then no amount of tuning is going to help and the more fundamental underlying design/architecture issue needs to be addressed.
Improve the Health check https://releem.com/blog/mysql-health-checks
Table cache hit rate as low as 20% can be absolutely devastating for performance. On a very busy, high throughput system that is otherwise reasonably well tuned, I have seen goodput collapse happen due to table_open_Cache not being high enough at over 90% hit rate. Given how cheap this cache is, you don't tune it for cache hit rate, you tune it so that overflows don't happen.
If that is not possible due to some other absurdity on the system (for example, I have seen database systems with over 1M tables on a single server, arising from the one-database-per-customer on a shared host anti-pattern), then no amount of tuning is going to help and the more fundamental underlying design/architecture issue needs to be addressed.