Al tratar con índices, debe determinar para qué se va a usar su tabla. Si está insertando principalmente 1000 filas por segundo y sin hacer ninguna consulta, entonces un índice agrupado es un acierto para el rendimiento. Si realiza 1000 consultas por segundo, no tener índice generará un rendimiento muy malo. Lo mejor que se puede hacer al intentar ajustar consultas/índices es usar Query Plan Analyzer y SQL Profiler en SQL Server. Esto le mostrará dónde se está ejecutando escaneos de tabla costosos u otros bloqueadores de rendimiento.
En cuanto al argumento GUID vs ID, puede encontrar personas en línea que juran por ambos. Siempre me han enseñado a usar GUID a menos que tenga una buena razón para no hacerlo. Jeff tiene una buena publicación que habla sobre las razones para usar los GUID: http://www.codinghorror.com/blog/archives/000817.html.
Como con casi todo lo relacionado con el desarrollo, si busca mejorar el rendimiento no hay una única respuesta correcta. Realmente depende de lo que intenta lograr y cómo está implementando la solución. La única respuesta verdadera es probar, probar y probar nuevamente contra las métricas de rendimiento para garantizar que cumpla con sus objetivos.
[Editar] @Matt, después de investigar un poco más sobre el debate GUID/ID me encontré con esta publicación. Como mencioné antes, no hay una verdadera respuesta correcta o incorrecta. Depende de sus necesidades específicas de implementación. Pero estas son algunas razones muy válidas para utilizar GUID como clave principal:
Por ejemplo, no es un problema conocido como un "punto caliente", donde algunas páginas de datos en una tabla están bajo relativamente alta contención moneda. Básicamente, lo que sucede es que la mayor parte del tráfico en una tabla (y por lo tanto bloqueos a nivel de página) ocurre en un área pequeña de la tabla, hacia el final. Los nuevos registros siempre irán a este punto de acceso, porque IDENTITY es un generador de números secuencial. Estos insertos son problemáticos porque requieren un bloqueo de página Exlusive en la página a la que se agregan (el punto de acceso). Esto serializa eficazmente todas las inserciones en una tabla gracias al mecanismo de bloqueo de página. NewID(), por otro lado, no sufre hotspots. Los valores generados con la función NewID() solo son secuenciales para ráfagas cortas de insertos (donde la función se llama muy rápidamente, como durante una inserción de varias filas), lo que provoca que las filas insertadas se distribuyan aleatoriamente en todas las páginas de datos de la tabla de todos al final, eliminando así un punto de acceso de inserts.
Además, como las inserciones se distribuyen aleatoriamente, la posibilidad de divisiones de página se reduce considerablemente.Mientras que una página se divide aquí y no está demasiado mal, los efectos se suman rápidamente. Con IDENTIDAD, la página Factor de relleno es bastante inútil como mecanismo de ajuste y también podría establecerse al 100%: las filas nunca se insertarán en ninguna página, sino en la última. Con NewID(), puede utilizar Fill Factor como herramienta de habilitación del rendimiento. Puede establecer Factor de relleno en un nivel que se aproxima al crecimiento de volumen estimado entre reconstrucciones de índice, y luego programar las reconstrucciones durante las horas de menor actividad utilizando dbcc reindex. Esto efectivamente retrasa los resultados de rendimiento de las divisiones de página hasta las horas de menor actividad.
Si incluso piensa en, es posible que tenga que habilitar la replicación para la tabla en cuestión, entonces también podría hacer de PK un identificador único y marcar el campo guid como ROWGUIDCOL. La replicación requerirá un campo guid con un valor único con este atributo, y agregará uno si no existe ninguno. Si existe un campo adecuado, entonces solo usará el que está allí.
Sin embargo, otro gran beneficio para el uso de los GUID de PK es el hecho de que el valor es de hecho garantizada única - no sólo entre todos los valores generados por este servidor, pero todos los valores generados por todos computadoras - ya se trate de su servidor db, servidor web, servidor de aplicaciones o máquina cliente. Casi todos los lenguajes modernos tienen la capacidad de generar un guid válido ahora. En .NET puede usar System.Guid.NewGuid. Esto es MUY útil cuando se trata de conjuntos de datos de detalles maestros en caché en particular. No tienes que emplear esquemas de claves temporales locas solo para relacionar tus registros antes de que se cometan. Simplemente obtiene un nuevo Guid perfectamente válido del sistema operativo para el valor de la clave permanente de cada nuevo registro en el momento en que se crea el registro.
http://forums.asp.net/t/264350.aspx
Como está haciendo la replicación, sus identidades correctas son algo de lo que no hay que preocuparse. Convertiría tu GUID en una clave principal pero no agrupada ya que no puedes usar newsequentialid. Eso me parece tu mejor opción. Si no lo convierte en PK, sino que pone un índice único en él, tarde o temprano puede hacer que las personas que mantienen el sistema no entiendan las relaciones FK introduciendo errores de forma adecuada. – HLGEM