1: NO.
2: NO.
3: NO.
4: Depende. habría que analizar el sistema, la estructura de la base, y las necesidades de las aplicaciones.
Las tres primeras opciones son un error de fundamentos de BBDD. Ni siquiera son opciones para tener en cuenta.
Los problemas de diseño de una BBDD no se restringen a considerar solamente la cantidad de registros de una tabla. Eso no es un problema de diseño, sino en todo caso de implementación y performance.
En una de las bases de datos que administré, había tablas que almacenaban más de 70 millones de registros, y de todos modos era eficiente. En otro caso que hoy manejo, una tabla registra 36 millones de registros diarios, y ni siquiera pestañea.
Pero lo esencial es que las bases están bien diseñadas, y la tabla es sólo parte del sistema...
Explicanos como es la estructura, el tipo de datos y veremos.
Cita: No es lo mismo hacer un SELECT de 100.000 registros que de 36.000.000 de registros.
Error. Una consulta en una base no optimizada, puee tardar más en revisar 3.000 registros que en analizar 3.000.000.
Y con una consulta sin optimización, puede tardar más en hacer un JOIN entre dos tablas de 1000 registros cada una, que en verificar una tabla con 145 millones de registros en un join con otra de 15 millones.
No es la cantidad de registros, sino la optimización lo que cuenta. El sólo tener un indice bien definido para un caso dado, puede reducir el tiempo de una consulta de 2:48 horas, a sólo siete segundos. O inclusive un proceso que toma 5 días, llevarlo a ejecutarse en 12 minutos (y no exagero, lo hicimos a principios de este año), sólo por cambiar dos parámetros en el WHERE.