What do you want to achieve with that? Save memory by not storing garbage in the query cache? Or make queries to this table faster, because they won't have query cache overhead?

The first is possible. The second — not really. SELECT queries are looked up in the query cache before they are parsed. When the server checks whether a query is cached, it does not know yet what tables this query uses. That is, all SELECT queries will be looked up.

But your ignore list could cause certain queries not to be stored in the query cache. This is doable, yes. But is it what you want?

Sergei,

Your response time continues to amaze me. Thank you.

What I'm interested in achieving:

When a SELECT comes in for the first time, check the cache (miss), parse the query, check the ignore list, then proceed without any interaction with cache.

1) For selects, this arrangement will prevent having to acquire the query cache lock to add the result set and also prevent any pruning from occurring to make room for the result set.

It's like SQL_NO_CACHE, but for every query that includes a particular table.

2) For updates/Inserts involving ignored tables, it allows the entire invalidation process to be bypassed

This can be done at sql_cache.cc function
void Query_cache::store_query(THD *thd, TABLE_LIST *tables_used)
just check if we have a table inside tables_used, if one table is inside ignored table return with
DBUG_PRINT("qcache", ("Table <table name>ignored by list", table_name));
DBUG_VOID_RETURN;

and including a server variable "sql_cache_ignore_tables"

this could be done at database schema level too (all tables from a database schema), using a server variable "sql_cache_ignore_database"

—
please include QUERY CACHE at components inside this MDEV jira header