Is there any way to keep rows with same id sequential even if they are not stored sequentially?
In rare cases the storage order of the data does matter for performance.  By "rare" I mean less than maybe 2% of tables benefit enough to bother doing anything.

Here's a use case where clustering consecutive rows 'together' (or at least 'close') could lead to significant decrease in I/O (sometimes 10-fold).


The table is too big to be cached in RAM in InnoDB's buffer_pool -- hence the potential for being slowed down by I/O.
The main queries do a range scan on whatever controls the data order.  For InnoDB, that is a range scan on the PRIMARY KEY.
Or the main queries are otherwise "close" because of a 2-column PRIMARY KEY.  Think of a messaging system and PRIMARY KEY(user_id, message_id) and the user is jumping around in his messages.


In one application where message_id is AUTO_INCREMENT, changing from 

PRIMARY KEY(message_id),
INDEX(user_id, message_id),
INDEX(user_id, ...)


to

PRIMARY KEY(user_id, message_id)  -- clustered primarily on user_id
INDEX(message_id),    -- sufficient for AUTO_INCREMENT
INDEX(user_id, ...)   -- benefits, too


nearly doubled the capacity of the server.

WordPress's wp_postmeta is an example of where this can be beneficial.  But I would say that less that 2% of such instances are big enough to matter.  Still, there are various reasons to change from 

  PRIMARY KEY (meta_id),
  INDEX(post_id),
  INDEX(meta_key)


to 

  PRIMARY KEY(post_id, meta_key),
  INDEX(meta_key)


More discussion:  http://mysql.rjweb.org/doc.php/index_cookbook_mysql#speeding_up_wp_postmeta . (This link also discusses what to do if you really need to keep meta_id.)

That brings up another topic.  Should the PRIMARY KEY always be a surrogate AUTO_INCREMENT?  In my experience, two-thirds of tables have a perfectly good "natural key" (sometimes composite) that could be used instead.  Wp_postmeta is one of many examples where the surrogate gets in the way of performance.

Semi-related:  A huge table with a UUID index is hopeless for performance.  Clustering won't help because you never do a 'range' scan and two UUIDs are rarely 'near' each other.  (A partial workaround:  http://mysql.rjweb.org/doc.php/uuid )