What happens when you update a VARCHAR cell with a longer string?
MySQL's InnoDB stores rows in blocks of 16KB each.  Within a block there could be a few big rows or hundreds on narrow rows.  Almost always, there is some spare room in a block.  When a column in a row is changed, the row is rewritten in the same block (if possible) and things are shuffled around within the block to make room.  (The exact details are buried in the code.)

If so much text (or blob or whatever) is added, that there is not room in the block, then there is a "block split".  This is where the rows in the original block are split between two blocks.

Blocks are stored in a B+Tree arrangement of blocks.  (See Wikipedia.)  Therefore, the blocks are not necessarily stored consecutively, but they can be referenced consecutively.  Thus, a block split in a billion-row table is about the same small amount of work as in a hundred-row table.

Another aspect is the "MVCC" that goes on to allow for multiple transactions to touch the same rows at the same time.  This leads to not just replacing a row with the modified value, but actually hanging onto the previous copy of the row until the transaction that needs it is finished.  But again, the spare room in a block, plus block splits, plus the BTree organization handles this.

So, your next question is about deleting?  Well, if the text is shrunken a lot, or a bunch of rows are DELETEd, then it seems like a block might be shrunken a lot, possibly even emptied?  Yes.  In this case, InnoDB checks to see if two adjacent blocks are small enough to combine, and does so, thereby freeing up one of the blocks for future use.  (This freed up block is kept in the tablespace and not given back to the OS, hence ibdata1 never shrinks; etc.)

All of that stuff happens under the covers, and we don't need to worry about it.

Really large records:  For example a row with a MEDIUMTEXT column with 1MB of data won't fit in 16KB.  What to do?  Well, the bulky columns are actually stored in other blocks, separate from the main part of the record.  This leads to some confusing limitations on the maximum size of a row and some unexpected performance issues.  Again, this is handled transparently, and the unit of allocation is 16KB.

While I am at it, note that the structure of an INDEX is essentially identical to that of a table -- a BTree of 16KB blocks that play block split/merge games under the covers as the index entries are added/deleted for row inserts/deletes.