This would depend upon the queries you issue (suppose the large table is `mydb.mytable`).

##ASPECT #1

For starters, think about the MyISAM storage engine. It only caches index pages in the MyISAM key cache (sized by [key_buffer_size][1]). If any queries against `mydb.mytable` reads a significant number of index pages from `/var/lib/mysql/mydb/mytable.MYI`, the query mya purge out index pages from other tables. This would causes other queries for those other table to have to reread them index pages from disk again.

##ASPECT #2

Any queries against a large MyISAM table that is infrequently accessed may have old index statistics, possibly resulting in full table scans down the road. During off hours, you should setup a crontab job that runs this SQL command:

    ANALYZE TABLE mydb.mytable;

This will rebuild the index statistics.

##ASPECT #3

Regardless of Storage Engine (or even RDBMS), any query that requests more that 5% of a table's total size would cause the MySQL Query optimizer to stop using indexes and do full table scans. For example, if you query data for a year and a table contains less than 20 years of log info, it is very probable that a full table scan will happen.

##ASPECT #4

If the cardinality of the indexes is very low, a certain key combination could result in a query not using any indexes and do a full table scan.

For a demonstration of low cardinality affecting query performance and EXPLAIN plain generation, see my `Nov 13, 2012` post http://dba.stackexchange.com/questions/28592/must-an-index-cover-all-selected-columns-for-it-to-be-used-for-order-by/28640#28640


  [1]: http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_key_buffer_size