por lo que dices cada quien altera su tabla, no hay ninguna colision


y si multiples personas pueden manejar la DB al mismo tiempo, claro, no son "al mismo tiempo", simplemente el motor de la DB realiza una operacion y luego la otra

si las 2 son espejo, entonces no hay mucho sentido de tener una tabla local a menos que realmente haya posibilidad de tener muchas operaciones offline (ya que me dices que se tiene que acceder a la tabla del otro usuario, offline solo empeora el problema), la tabla offline para rapida operacion usualmente es solo un reflejo en memoria, pero no una tabla real

cuantos llamas muchos usuarios? de cuantas operaciones por segundo hablamos?

MySQL soporta un maximo de conexiones concurrentes configurable desde los 60 y tantos a los 2000 y tantos (AWS). Eso significa que podrian estar esa cantidad de usuarios, a la misma vez, manipulando la base de datos de una forma u otra. El tema de colisiones como bien te han comentado es manejado por el propio motor de la base de datos y sus protocolos de control de concurrencia (locks, TPLP, DPP, TSO, etc ), el cual garantiza que no existan  problemas con transacciones concurrentes.
Por otra parte, el mecanismo que comentas de trabajar con todos los datos en memoria no es la mejor practica cuando se trabaja con sistemas distribuidos. La base de datos existe con el objetivo de tener la informacion centralizada y que todos los clientes tengan la ultima version de los datos cada vez que lo soliciten. Luego, por cuanto tiempo manejarias la informacion en la memoria de tu aplicacion antes de enviarla a la BD?, mientras no lo haces el resto de clientes no tendrian la informacion actualizada y quizas cuando te decidas a enviarla entre en conflicto con otro commit. Por otra parte esta la seguridad de la informacion, si tu aplicacion crashea o se cierra todos los datos que manejabas en memoria se perderian. Resumiendo, esa forma de proceder viola muchisimas buenas practicas y anula en si el objetivo de una BD para empezar.
Las BD existen para consultarlas y hacerle peticiones cada vez que necesites obtener informacion, ese es su objetivo y su metodo de funcionamiento, luego ya hay tecnicas de optimizacion de consultas, db caching, etc, pero esos son otros temas. A no ser que tu servidor MySQL este alojado en una PC con escasos recursos o tu sistema vea transacciones por el orden de los miles por minuto o segundo, no creo que tengas problemas. Para el tema de mantener en "cache" por llamarlo de alguna manera, los resultados de una consulta de la base de datos, auxiliate de los controles de tu aplicacion, utiliza tablas, listas, cajas de texto y todo lo que necesites para la permanencia de los resultados de tus consultas y la interaccion del usuario con ellos.
Igual con todo lo anterior no se si he respondido a tu pregunta
Suerte

Lo que sigo sin entender es la finalidad de tener una replica local de la BD remota, en mi opinion estas añadiendo una capa extra innecesaria en el flujo de trabajo, a no ser que evidentemente, el diseño de tu software asi lo requiera para otros fines. Cual es el objetivo de esta copia en tu caso especifico? Que necesitas de la BD local que no puedas usar de la remota?

Ok, habia entendido mal, simplemente ignora mi ultimo mensaje