Para responder a la primera parte de su pregunta, creo que es útil mirar el texto adicional en el archivo de ayuda Creación de índices de atributos sobre índices de columnas múltiples.
El orden en que aparecen los campos en un índice de varias columnas es importante. En un índice de varias columnas con la columna A que precede a la columna B, la columna A se utilizará para realizar la búsqueda inicial. Además, dicho índice será mucho más útil para consultas que involucren solo a la columna A que para consultas que involucren solo a la columna B.
Cree un índice de varias columnas en A y B. Este índice generalmente sería más eficiente para consultas que involucren ambas columnas. Para consultas que involucran solo A, este índice sería más lento que un índice en A solo. Este índice sería de poca utilidad para consultas que involucren solo B. Para compensar, puede crear un índice adicional en B.
Ambos pasajes muestran que los índices de varias columnas son mejores para uso especializado. Además, el uso de dicho índice para ordenar solo una de las columnas incluidas, en realidad podría dañar el rendimiento. Por esta razón, es probable que los índices de columnas individuales sean necesarios para cada uno de los atributos incluidos en un índice de varias columnas.
Encontré un enlace a un documento antiguo pero interesante de ESRI que indica las 9 razones para elegir un archivo en lugar de un GDB personal . Es interesante porque específicamente llama al rendimiento como una de las razones. Parte de esta ganancia de rendimiento se debe al sistema de almacenamiento basado en archivos. Creo que esto también podría jugar con la falta de soporte de múltiples columnas. A diferencia del Personal GDB, que es un archivo único, un índice en un Archivo GDB se almacena como un archivo separado en la estructura GDB. Esto significa que el archivo de índice y el archivo de atributos para una clase de entidad en particular tendrán que vincularse y acceder juntos. Pude ver dónde un índice de varias columnas conduciría a saltar de un lado a otro entre los archivos de índice y atributo, y potencialmente causar un impacto en el rendimiento que supera la ganancia de rendimiento de indexación.
Dado que ya hay ganancias significativas de rendimiento con el File GDB sobre el Personal GDB, probablemente no valía la pena implementar el índice de varias columnas.
En mi experiencia trabajando con ambos tipos de GDB, he visto el Personal GDB ejecutándose aproximadamente un 50% más grande que el archivo. Según los datos que proporcionó con respecto a su archivo GDB, si fuera a convertir a un PGDB, probablemente terminaría con un ~ 300 MB de GDB personal. Por lo que he visto, trabajar con bases de datos de MS Access, tanto dentro de los productos ESRI como por separado, es que comienza a ver una degradación del rendimiento una vez que los archivos ".mdb" aumentan significativamente más de 100 MB de tamaño.
El otro problema probablemente sería que incluso si pudiera acelerar sus búsquedas de atributos, vería un gran impacto en el rendimiento relacionado con moverse en el marco de datos y actualizar la vista. La capa simplemente no se dibujaría tan rápido si estuviera en una PGDB. Este artículo que compara los tipos de geodatabases proporciona más información sobre las diferencias de rendimiento.
Al igual que con muchas cosas, la mejor opción finalmente se reducirá a cuál es su caso de uso. Si hay muchas operaciones específicas de la base de datos que le gustaría realizar, como consultas y actualizaciones, que puede hacer en la interfaz de Access, entonces el GDB personal puede ser mejor. Si solo planea hacer algunas consultas, pero principalmente visualizará los datos espaciales, entonces el rendimiento definitivamente recae en el lado del archivo GDB.