¿Tabla que se usa mucho debería clonarse?

[gnzsoloyo]

¿Te refieres a crear datos aleatorios?
No. cada uno hace ese tipo de procedimientos para las bases que diseña, porque cada base es diferente.
Puede que haya programas que te sirvan parcialmente, pero no conozco personalmente ninguno que me haya dado resultados útiles.
Además, en realidad no es necesario demasiada "evaluación de rendimiento", porque el mayor impacto no está en la cantidad de registros, sino en el uso en el mundo real.
Cuando estableces un plan de implementación, una de sus etapas precisamente tiene que ver con el uso esperado de la aplicación, y eso no depende de que algo tenga capacidad ed almacenamiento, sino en la inserción en el mercado, que te permite estimar los requerimientos de los usuarios al sistema. Es allí donde se ve cuáles son las verdaderas necesidades tanto del diseño de la aplicación, como de hardware necesario.
A mi entender, si lo tuyo está en etapa de proyecto, estás preocupándote innecesariamente por cosas que puede que no ocurran nunca.

Una observación que sí puedo hacerte de entrada, es que si tu duda es referente a la tabla que muestras en el diagrama, estás completamente desencaminado...
La tabla de Productos jamás es una tabla problemática, porque es una tabla que recibe poco impacto, ya que sólo se actualiza en modo batch, y eso está fuera del efecto de la concurrencia.
Por otro lado, si tu duda es por el hecho que sea muy consultada en otras partes del proceso, te aclaro que eso sucede en todos los sistemas, y raramente genera inconvenientes, porque el acceso a la misma no ocurre en un único buffer, ni en una única conexión, ni nada que se le parezca.
Para darte una somera idea, en los sistemas que trabajo, existe una sola tabla de productos a nivel país (hay bases distribuidas por país), que contiene (y no exagero) más de 500.000 registros, que se consultan mas o menos unas 1200 veces/segundo, todo el día (con picos mayores o menores), y no fue esa la razón por la que se necesitó particionarla, ya que eso se maneja a nivel servidores de bases de datos, y además con muy potente hardware. Se particionó para descargar los registros obsoletos a segmentos que no estorbasen en las transacciones diarias.
Pero en contexto así, en realidad, son las tablas transaccionales, es decir aquellas donde se asientan las operaciones comerciales, las que realmente representan problemas de concurrencia. Y es a esas tablas (tal vez con pocas relaciones), donde tu análisis debe apuntar. No a una tabla de Productos, por más que esté vinculada a otras 100 tablas.

¿Se entiende a lo que me refiero?

Si estás en etapa de proyecto, no pierdas tiempo evaluando un problema que no existe aún. Evalúa el sistema y lo que puede requerir el usuario, y estudia como gestionar el problema sin tener que sacrificar diseño, consistencia o procesos innecesarios.
La contingencia de un exceso de concurrencia puede simplemente resolverse con mejor hardware, o mejores configuraciones, o servicios, y no necesariamente con lo que estás suponiendo.

A nosotros, ciertos procesos nos bloqueaban ciertas tablas hace un tiempo (no viene al caso cuáles). ¿Y cuál fue la solución?
Cambiar el orden de las tablas del JOIN en tres consultas... porque eso redujo el tiempo de esas consultas a menos de 1/1000.
En otro caso, un proceso que debía realizarse en cinco días (y no miento), se redujo a 12 minutos, simplemente cambiando dos parámetros en un WHERE.

Con esto quiero destacarte que muchas veces no es el tamaño de la tabla el problema, sino lo óptimo de la consulta, porque una consulta puede meterte en un deadlock que no se ve en el diseño de datos. Y eso sí arruina la performance del sistema.