¿Es una buena idea dividir una tabla de 'usuarios' para fines de autenticación?

Supongamos que tengo una tabla de usuario en mi sitio en la que hay alrededor de 2-3 millones de usuarios (registros) en la tabla.

Para acelerar mi proceso de inicio de sesión, ¿es un buen enfoque dividir mi tabla de usuarios, una para su información y otra para su inicio de sesión?

Si podemos ejecutar una consulta similar a la siguiente desde una tabla:

select username,password from users where username=`test` AND password=****

¿Es necesario dividirlo y esto acelera el proceso de inicio de sesión de mi sitio?

En mi humilde opinión, no es necesario dividirlo físicamente. Sin embargo, sería bueno almacenarlo en caché.

Si la userstabla usa el motor de almacenamiento MyISAM, tiene una buena ventaja.

Dado que MyISAM solo almacena en caché los índices, puede hacer dos cosas

• Puede crear un caché de claves personalizado solo para cargar el índice MyISAM userssolo para la tabla
• Puede indexar el nombre de usuario y la contraseña para forzar que la consulta golpee solo esa caché de claves personalizada

Asegúrese de que existan los siguientes índices para users

ALTER TABLE users ADD UNIQUE INDEX username_ndx (username);
ALTER TABLE users ADD UNIQUE INDEX username_password_ndx (username,password);

Hay dos (2) razones principales para los dos índices

MOTIVO del índice n. ° 1

El índice username_ndxevita que un nombre de usuario tenga múltiples contraseñas, así como también evita que varios usuarios con el mismo nombre

MOTIVO del índice n. ° 2

El índice username_password_ndxproporciona un índice de cobertura . Por lo tanto, su consulta buscará el nombre de usuario y la contraseña solo en el caché MyISAM personalizado, en lugar de verificar la tabla.

Más enlaces sobre los principios de los índices de cobertura

• http://www.mysqlperformanceblog.com/2006/11/23/covering-index-and-prefix-indexes/
• http://ronaldbradford.com/blog/tag/covering-index/
• http://shallop.com/2011/04/covering-indexes-in-mysql/
• http://www.mysqlconf.com/mysql2009/public/schedule/detail/6796

Lo siguiente es crear esa caché de claves personalizada. Estos son los comandos para crear un caché de claves de 8 MB y cargar ese caché de claves dedicado (Ejemplo: si la tabla es mydb.users):

SET GLOBAL authentication_cache.key_buffer_size = 1024 * 1024 * 8;
CACHE INDEX mydb.users IN authentication_cache;
LOAD INDEX INTO CACHE mydb.users;

Debe colocar estas tres líneas en el archivo /var/lib/mysql/startup.sql

Agregue esto a /etc/my.cnf

[mysqld]
init-file=/var/lib/mysql/startup.sql

Esto cargará el caché cada vez que se inicia mysql

Darle una oportunidad !!!

ACTUALIZACIÓN 2011-12-30 17:25 EDT

Si desea obtener el tamaño exacto para configurar el caché, use la siguiente consulta:

SELECT CONCAT('1024 * 1024 * ',ROUND(index_length/power(1024,2))) RecommendedCacheSize
FROM information_schema.tables WHERE table_name='users';

ACTUALIZACIÓN 2011-12-30 23:21 EDT

Aquí hay un método basado en InnoDB

Aún necesitas los índices

ALTER TABLE users ADD UNIQUE INDEX username_ndx (username);
ALTER TABLE users ADD UNIQUE INDEX username_password_ndx (username,password);

Debe asegurarse de que el InnoDB Buffer Pool tenga los nombres de usuario y las contraseñas disponibles. Es posible que tenga que recurrir a hacer un análisis de índice completo al iniciar mysql:

Paso 1) Crear ReadUserPass.sql

echo "select username,password from users;" > /var/lib/mysql/ReadUserPass.sql

Paso 2) Agregue ese script a /etc/my.cnf

[mysqld]
init-file=/var/lib/mysql/ReadUserPass.sql

Paso 3) Realice uno de los siguientes

• $ service mysql restart
• mysql> source /var/lib/mysql/ReadUserPass.sql

Debido a que ambas columnas (nombre de usuario y contraseña) residen en username_password_ndx, todas las páginas de índice que componen este índice se vuelven a cargar en el InnoDB Buffer Pool. Esto es necesario porque existe la posibilidad de que las páginas de índice se eliminen. Para minimizar que eso suceda, aumente el tamaño de la agrupación de almacenamiento intermedio y reinicie mysql (una vez).

No debería ser necesario dividir una tabla de un par de millones de filas. El ajuste del rendimiento debe hacerse a través de índices. MySpace tenía cientos de millones de cuentas en una sola tabla y el rendimiento en esa tabla estuvo bien. (Yo era un DBA para MySpace en el punto más alto de su uso). La tabla en ese caso probablemente tenía entre 80 y 90 bytes de ancho (quizás un poco más).

¿Realmente tienes 2 millones de usuarios? A menos que ya tenga este problema o esté seguro de que lo hará, está optimizando con mucha anticipación. Agregue un índice compuesto en los campos de inicio de sesión y contraseña y termine con él. No optimice a menos que sepa que realmente tiene un problema que resolver. Estoy seguro de que tienes problemas más grandes que resolver.

Si usa Mysql 5.1 y superior, puede intentar particionar su tabla.
En cuanto a su pregunta sobre si acelera el proceso de inicio de sesión, depende de cómo se vea el resto del procedimiento de inicio de sesión (por ejemplo, si su consulta ahora toma 0.05 segundos y el resto del código tarda 20 segundos, prefiero volver a pensar en toda la rutina ...)
Además, independientemente de usar particiones, no olvide agregar índices como lo señaló RolandoMySQLDBA .