Table size bigger than buffer pool size
Short Answer.  Not a problem, except for slowing down.

Long Answer: (InnoDB-specific)

innodb_buffer_pool_size controls the InnoDB "cache".  It is broken into 16KB "blocks", each of which comes and goes from RAM based, roughly, on a Least-Recently-Used algorithm.  (See "1 page granularity" mentioned in a Comment.)

So, when you fetch something from a table, the query execution probably needs to look in an index to find where to find the something, and proceeds to fetch blocks as needed to find it.  For simple queries, this is a few blocks, for a full table scan of your 231GB, it will involve fetching all the approx 14 million blocks.

When a block needs to be fetched, but the cache is full, then some block must be bumped out of the cache.  (Hence the reference to LRU.)

If the "working set" of your data is a lot smaller than 231GB, then there won't be much I/O, and the size of the cache (buffer_pool) is not critical.  But if you do table scans, or use UUIDs, then queries will still run, but they will run slower due to the I/O due to [re]loading blocks into the cache.

All operations are done in the cache; almost nothing bypasses the cache.  Indexes and Data are each stored in BTrees that are composed of 16KB blocks.