¿Por qué INT no es más eficiente que UNIQUEIDENTIFIER (de acuerdo con el plan de ejecución)?

Question

Tengo una tabla principal y una tabla secundaria donde las columnas que las unen son del tipo UNIQUEIDENTIFIER.

La tabla secundaria tiene un índice agrupado en la columna que lo une a la tabla primaria (su PK, que también está agrupada).

He creado una copia de estas dos tablas, pero cambié las columnas de relación para que sean INT, he reconstruido los índices para que sean esencialmente la misma estructura y puedan consultarse de la misma manera.

Cuando consulto 20 registros conocidos de la tabla principal, extrayendo todos los registros relacionados de las tablas secundarias, obtengo costos de consulta idénticos en ambos, es decir, el costo 50/50 para los lotes.

Si esto es cierto, entonces mi proyecto gigante de cambiar todas las tablas como esta parece ser inútil, aparte de acelerar las inserciones. ¿Alguien puede dar alguna luz sobre la situación?

---

EDIT:

La pregunta no es sobre lo que es más eficiente, pero ¿por qué el plan de ejecución de la consulta mostrando tanto las consultas como tener el mismo costo?

Answer 1

Buscar-en una clave en un índice agrupado es básicamente lo mismo en una clave de 4 bytes, una clave de 16 bytes o una clave de 160 bytes. El costo de comparar las ranuras con el predicado es solo ruido en el costo general de la consulta (preparación de la ejecución, preparación del contexto de ejecución, apertura de los conjuntos de filas, ubicación de las páginas, etc.), , incluso cuando no se trata de IO.

Si bien nadie argumentará que los GUID e INT están en pie de igualdad, la comparación de solo 20 búsquedas no revelará las diferencias. Una cosa que puede medir inmediatamente es espacio: un ahorro de 12 bytes por fila y por página no hoja en índice agrupado, más 12 bytes en cada página hoja en índices no agrupados se sumarán en millones de filas y decenas de tablas e índices. Menos espacio significa menos IO, mejor rendimiento de memoria caché, mejor calidad en general, y que puede medirse, pero debe medir cargas reales, no una búsqueda de 20 filas insignificantes.

En condiciones de laboratorio, podrá medir la diferencia de velocidad bruta entre la búsqueda de una INT o GUID, pero ese no debería ser su objetivo. El argumento de INT vs. GUID no se ve afectado por una ganancia de rendimiento del 5% en una búsqueda, es impulsado por el ahorro de espacio y por la aleatoriedad guiada que conduce a la fragmentación, mediciones muy fáciles de medir que justifican por sí mismas la INT motivos, no es necesario presentar el argumento de rendimiento de búsqueda.

Answer 2

Much más eficiente.

Int es mucho más pequeño. Esto significa que obtiene índices mucho más pequeños, lo que significa que obtiene un mejor uso de la memoria y tiempo de carga para acceder al índice. Depende mucho, sin embargo, de qué tan grandes son sus tablas y qué hace con ellas.

Answer 3

Además de lo que dijo Remus, el uso de GUID para índices agrupados llevará a una tremenda fragmentación de ellos en la mayoría de los casos, afectando el rendimiento de las consultas en términos de IO. Esto sucede cuando no se usan guiones generados secuencialmente, lo que supongo que es principalmente el caso cuando una aplicación genera guid fuera de la base de datos. Para crear un guid secuencial ('más grande' que la base de datos generada previamente) debe usar la función newsequentialid()

La comparación del costo de dos planes en un lote no es precisa en todos los casos. El costo se calcula, entre otros, en el número de operaciones de E/S necesarias para ejecutar la consulta. En bases de datos pequeñas, la diferencia entre INT y GUID no cambiará IO de manera significativa para mostrar la diferencia en los planes de ejecución.