Lea:Limitaciones de particionamiento de MySQL
1.) Los FK no se admiten en tablas particionadas.
- Una opción es crear un procedimiento almacenado que inserte/actualice el registro y verificar dentro del procedimiento que la identificación de usuario pasada esté presente en su tabla de usuarios antes de que se realice la inserción. Debe configurar los permisos en la tabla para que solo el SP pueda actualizarse e insertarse para permitir que las aplicaciones y/o los usuarios accedan a la verificación por la puerta trasera. También deberá tomar precauciones al eliminar usuarios de la tabla de usuarios.
2.) La columna que use para la partición dependerá de cómo acceda a la tabla. Si sus consultas siempre se basan en el número de vehículo, entonces probablemente tenga sentido hacer una partición hash en esa columna. Si está consultando o informando más sobre algo como "qué vehículos se agregaron este mes" o si desea "desplegar" las particiones a medida que alcanzan cierta edad, entonces la partición en la fecha puede ser el camino a seguir. Esto es algo que tendrá que decidir en función de su uso.
3.) Consulte el enlace anterior para obtener más información.
Editar según la pregunta del usuario:
Insertar un registro cada 3 segundos no es mucho rendimiento. Asegúrese de tener una clave principal en su tabla de usuarios para que la verificación dentro del procedimiento se realice de manera eficiente. (Esto es cierto incluso si los FK fueran compatibles) El DB estaría haciendo esta verificación por usted detrás de escena si tuviera soporte para FK, por lo que, en ese sentido, no lo está perjudicando. Si la verificación termina siendo un cuello de botella, es posible que sienta la necesidad de descartarla y posiblemente informar las identificaciones de usuario errantes como un proceso por lotes nocturno, pero si su tabla de usuario es relativamente pequeña y está indexada correctamente, no veo que esto sea un problema.
Otra opción sería realizar la partición manualmente (es decir, fragmentación) con tablas particionadas o no particionadas. Por supuesto, con las tablas no particionadas, puede usar claves foráneas nativas. Por ejemplo, dividiría la tabla de vehículos en varias tablas como:(asumiendo que desea usar el número de vehículo como "clave")
VehículosNosMenosDe1000
VehículosNosMensThan2000
VehículosNosMenosDe...
VehículosNosLessThanMAX
Aquí probablemente quiera tener un SP nuevamente para que la aplicación/usuario no tenga que saber acerca de las tablas. El SP sería responsable de insertar/actualizar la tabla correcta en función del número de vehículo que se pasó. También querrá un SP para seleccionar datos para que la aplicación/el usuario no tenga que conocer la tabla para seleccionar tampoco. Para acceder fácilmente a todos los datos, puede crear una vista que una todas las tablas.
Tenga en cuenta que un beneficio de esto es que actualmente MyISAM bloquea una tabla particionada completa durante las actualizaciones, no solo la partición que está actualizando. Fragmentar una tabla de esta manera alivia esa disputa porque las tablas mismas son las "particiones".
Según los datos limitados que tengo sobre lo que está haciendo, probablemente escribiría 2 procedimientos almacenados, 1 para seleccionar los datos y 1 para actualizar/insertar los datos y hacer que su aplicación los use para todos los accesos. Luego probaría la partición regular a través de hash en el vehículo No primero mientras se aplica la clave de ID de usuario dentro del procedimiento. Si esto se convierte en un problema, puede migrar fácilmente para fragmentar los datos en varias tablas sin tener que cambiar la aplicación porque toda la lógica sobre cómo recuperar y actualizar los datos está contenida en los SP.
