¿Existe una diferencia de rendimiento REAL entre las claves primarias INT y VARCHAR?

174

¿Existe una diferencia de rendimiento medible entre el uso de INT vs. VARCHAR como clave principal en MySQL? Me gustaría usar VARCHAR como clave principal para las listas de referencias (piense en los Estados Unidos, los códigos de país) y un compañero de trabajo no cederá en INT AUTO_INCREMENT como clave principal para todas las tablas.

Mi argumento, como se detalla aquí , es que la diferencia de rendimiento entre INT y VARCHAR es insignificante, ya que cada referencia de clave externa INT requerirá un JOIN para que la referencia tenga sentido, una clave VARCHAR presentará directamente la información.

Entonces, ¿alguien tiene experiencia con este caso de uso en particular y las preocupaciones de rendimiento asociadas con él?

Jake McGraw
fuente
3
Hice una publicación con la respuesta "no" con algunos detalles de las pruebas que he realizado ... pero eso fue SQL Server, no MySQL. Entonces borré mi respuesta.
Timothy Khouri
17
@Timothy: no deberías haberlo eliminado. Estaba en proceso de votarlo. La mayoría de los servidores de bases de datos SQL tienen planificadores de consultas similares y cuellos de botella de rendimiento similares.
Paul Tomblin
9
@Timothy, vuelve a publicar tus resultados.
Jake McGraw
2
Muchos comentarios y respuestas suponen que las claves están ahí para ser utilizadas para las uniones. Ellos no son. Las claves están ahí para ser utilizadas para la consistencia de los datos, para evitar filas duplicadas (más de una fila representa la misma entidad). Se puede usar cualquier columna (o conjunto de columnas) en una unión, y para garantizar que la unión sea de uno a cero o muchas, la columna [s] simplemente debe ser única. Cualquier índice único garantiza eso, y no tiene por qué ser significativo.
Charles Bretana

Respuestas:

78

Usted asegura que puede evitar un cierto número de consultas unidas utilizando lo que se llama una clave natural en lugar de una clave sustituta . Solo usted puede evaluar si el beneficio de esto es significativo en su aplicación.

Es decir, puede medir las consultas en su aplicación que son las más importantes para ser rápido, porque funcionan con grandes volúmenes de datos o se ejecutan con mucha frecuencia. Si estas consultas se benefician de la eliminación de una unión y no sufren al usar una clave primaria varchar, entonces hágalo.

No utilice ninguna estrategia para todas las tablas en su base de datos. Es probable que en algunos casos, una clave natural sea mejor, pero en otros casos una clave sustituta es mejor.

Otras personas señalan que es raro en la práctica que una clave natural nunca cambie o tenga duplicados, por lo que las claves sustitutas generalmente valen la pena.

Bill Karwin
fuente
3
Y a veces, (en mi humilde opinión, a menudo), ambos son mejores, el sustituto para usar para referencias FK en otras tablas y para Uniones, y la clave natural para garantizar la coherencia de los datos
Charles Bretana,
@CharlesBretana Eso es interesante. ¿Es una práctica común utilizar una clave natural para la consistencia de los datos junto con el FK? Mi primer pensamiento fue que el almacenamiento adicional que se requeriría en tablas grandes podría no valer la pena. Cualquier información es apreciada. FYI - Tengo un fondo de programación decente pero mi experiencia SQL se limita principalmente a consultas SELECT
Rob
2
@CharlesBretana Cuando leo "almacenarlos a ambos", creo que "redundancia" y "no normalizado", lo que equivale a "Esto podría arruinarse" y "Tengo que asegurarme de que ambos se cambien si alguna vez se cambia". Si tiene redundancia, debe haber una muy buena razón (como un rendimiento completamente inaceptable) porque la redundancia siempre es posible para que sus datos se vuelvan inconsistentes.
jpmc26
3
@ jpmc26, NO hay absolutamente ningún problema de redundancia o normalización involucrado. Una clave sustituta no tiene una conexión significativa con los valores de una clave natural, por lo que nunca debería necesitar ser cambiada. En cuanto a la normalización, ¿de qué problemas de normalización estás hablando? La normalización se aplica a los atributos significativos de una relación; El valor numérico de una clave sustituta (de hecho, el concepto mismo de una clave sustituta) se encuentra completamente fuera del contexto de cualquier normalización.
Charles Bretana
1
Y para responder a su otra pregunta, específicamente sobre una tabla de estados, si tenía una clave sustituta en esta tabla, con valores, digamos, del 1 al 50, pero NO puso otro índice o clave única en el código postal del estado, (y, en mi opinión, también sobre el nombre del estado), ¿qué impide que alguien ingrese dos filas con diferentes valores de clave sustituta pero con el mismo código postal y / o nombre de estado? ¿Cómo lo manejaría la aplicación cliente si hubiera dos filas con 'NJ', 'Nueva Jersey'? ¡Las claves naturales aseguran la consistencia de los datos!
Charles Bretana
81

No se trata de rendimiento. Se trata de lo que hace una buena clave primaria. Único e inmutable en el tiempo. Puede pensar que una entidad como un código de país nunca cambia con el tiempo y sería un buen candidato para una clave primaria. Pero la experiencia amarga es que rara vez es así.

INT AUTO_INCREMENT cumple la condición "única e inmutable en el tiempo". De ahí la preferencia.

Steve McLeod
fuente
25
Cierto. Una de mis bases de datos más grandes tiene entradas para Yugoslavia y la Unión Soviética. Me alegro de que no sean claves principales.
Paul Tomblin
8
@Steve, entonces ¿por qué ANSI SQL admite la sintaxis para ON UPDATE CASCADE?
Bill Karwin
55
La inmutabilidad no es un requisito de una clave. En cualquier caso, las claves sustitutas a veces también cambian. No hay nada de malo en cambiar las llaves si es necesario.
nvogel
9
Paul, ¿cambiaste la Unión Soviética a Rusia en tu base de datos? ¿Y pretender que la SU nunca existe? ¿Y todas las referencias a SU ahora apuntan a Rusia?
Dainius
66
@alga Nací en SU, así que sé lo que es.
Dainius
52

Estaba un poco molesto por la falta de puntos de referencia para esto en línea, así que realicé una prueba yo mismo.

Sin embargo, tenga en cuenta que no lo hago de forma regular, así que compruebe mi configuración y mis pasos para ver si hay factores que puedan haber influido en los resultados involuntariamente y publique sus inquietudes en los comentarios.

La configuración fue la siguiente:

  • CPU Intel® Core ™ i7-7500U @ 2.70GHz × 4
  • 15.6 GiB RAM, de los cuales me aseguré de que alrededor de 8 GB estuvieran libres durante la prueba.
  • Unidad SSD de 148,6 GB, con mucho espacio libre.
  • Ubuntu 16.04 de 64 bits
  • MySQL Ver 14.14 Distrib 5.7.20, para Linux (x86_64)

Las mesas:

create table jan_int (data1 varchar(255), data2 int(10), myindex tinyint(4)) ENGINE=InnoDB;
create table jan_int_index (data1 varchar(255), data2 int(10), myindex tinyint(4), INDEX (myindex)) ENGINE=InnoDB;
create table jan_char (data1 varchar(255), data2 int(10), myindex char(6)) ENGINE=InnoDB;
create table jan_char_index (data1 varchar(255), data2 int(10), myindex char(6), INDEX (myindex)) ENGINE=InnoDB;
create table jan_varchar (data1 varchar(255), data2 int(10), myindex varchar(63)) ENGINE=InnoDB;
create table jan_varchar_index (data1 varchar(255), data2 int(10), myindex varchar(63), INDEX (myindex)) ENGINE=InnoDB;

Luego, llené 10 millones de filas en cada tabla con un script PHP cuya esencia es así:

$pdo = get_pdo();

$keys = [ 'alabam', 'massac', 'newyor', 'newham', 'delawa', 'califo', 'nevada', 'texas_', 'florid', 'ohio__' ];

for ($k = 0; $k < 10; $k++) {
    for ($j = 0; $j < 1000; $j++) {
        $val = '';
        for ($i = 0; $i < 1000; $i++) {
            $val .= '("' . generate_random_string() . '", ' . rand (0, 10000) . ', "' . ($keys[rand(0, 9)]) . '"),';
        }
        $val = rtrim($val, ',');
        $pdo->query('INSERT INTO jan_char VALUES ' . $val);
    }
    echo "\n" . ($k + 1) . ' millon(s) rows inserted.';
}

Para las inttablas, el bit ($keys[rand(0, 9)])se reemplazó con just rand(0, 9), y para las varchartablas, utilicé nombres completos de estados de EE. UU., Sin cortarlos ni extenderlos a 6 caracteres. generate_random_string()genera una cadena aleatoria de 10 caracteres.

Luego corrí en MySQL:

  • SET SESSION query_cache_type=0;
  • Para la jan_intmesa:
    • SELECT count(*) FROM jan_int WHERE myindex = 5;
    • SELECT BENCHMARK(1000000000, (SELECT count(*) FROM jan_int WHERE myindex = 5));
  • Para otras tablas, igual que el anterior, con myindex = 'califo'para chartablas y myindex = 'california'para varchartablas.

Tiempos de la BENCHMARKconsulta en cada tabla:

  • ene_int: 21.30 sec
  • jan_int_index: 18.79 segundos
  • jan_char: 21,70 segundos
  • jan_char_index: 18.85 segundos
  • jan_varchar: 21,76 segundos
  • jan_varchar_index: 18.86 sec

En cuanto a los tamaños de tabla e índice, aquí está el resultado de show table status from janperformancetest;(con algunas columnas no mostradas):

|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Name              | Engine | Version | Row_format | Rows    | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Collation              |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| jan_int           | InnoDB |      10 | Dynamic    | 9739094 |             43 |   422510592 |               0 |            0 |   4194304 |           NULL | utf8mb4_unicode_520_ci |  
| jan_int_index     | InnoDB |      10 | Dynamic    | 9740329 |             43 |   420413440 |               0 |    132857856 |   7340032 |           NULL | utf8mb4_unicode_520_ci |   
| jan_char          | InnoDB |      10 | Dynamic    | 9726613 |             51 |   500170752 |               0 |            0 |   5242880 |           NULL | utf8mb4_unicode_520_ci |  
| jan_char_index    | InnoDB |      10 | Dynamic    | 9719059 |             52 |   513802240 |               0 |    202342400 |   5242880 |           NULL | utf8mb4_unicode_520_ci |  
| jan_varchar       | InnoDB |      10 | Dynamic    | 9722049 |             53 |   521142272 |               0 |            0 |   7340032 |           NULL | utf8mb4_unicode_520_ci |   
| jan_varchar_index | InnoDB |      10 | Dynamic    | 9738381 |             49 |   486539264 |               0 |    202375168 |   7340032 |           NULL | utf8mb4_unicode_520_ci | 
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

Mi conclusión es que no hay diferencia de rendimiento para este caso de uso en particular.

Jan Żankowski
fuente
Sé que es tarde ahora, pero habría tenido curiosidad por ver los resultados si hubiera elegido una cadena menos ideal para la condición where. "califo [rnia]" era ideal ya que podía descartar desajustes después de comparar el primer personaje, solo necesitando verificar más en las coincidencias reales; algo como "newham" habría dado resultados más interesantes, ya que sería nuevo comparar más personajes para eliminar todos los desajustes. Además, al limitar sus enteros de esa manera también se acumulan las probabilidades en contra de ellos, les habría dado al menos 26 valores.
Uueerdo
15
Es sorprendente que en una pregunta de hace 10 años, esta sea solo una de las dos respuestas que no sea solo especulación y se base en puntos de referencia reales.
Adrian Baker
1
Pero sus tablas no tienen una clave primaria, que en realidad en InnoDB es una estructura de datos ordenada. La velocidad entre la clasificación de enteros y la clasificación de cadenas debe ser diferente.
Melkor
1
@Melkor Fair point que uso en INDEXlugar de PRIMARY KEY. No recuerdo mi razonamiento: probablemente asumí que PRIMARY KEYes solo una INDEXrestricción de singularidad. Sin embargo, al leer la sección sobre cómo se almacenan las cosas en InnoDB en federico-razzoli.com/primary-key-in-innodb , creo que mis resultados aún se aplican a las claves principales y respondo la pregunta sobre la diferencia de rendimiento de la búsqueda de valor. Además, su comentario sugiere analizar el rendimiento de los algoritmos de clasificación , que no se aplican al caso de uso que investigo, que es buscar valores en un conjunto.
Jan Żankowski
1
La operación de búsqueda también requiere comparaciones en el campo de clave principal (como una búsqueda binaria), donde int debería ser un poco más rápido que varchar. Pero como sugirieron sus experimentos, no es tan obvio (o tal vez porque no tenía una clave principal, por lo que las consultas fueron más lentas). Creo que es lo mismo al insertar y buscar.
Melkor
38

Depende de la longitud. Si el varchar tendrá 20 caracteres y el int es 4, entonces si usa un int, su índice tendrá CINCO veces más nodos por página de espacio de índice en el disco ... Eso significa que atravesar el índice requerirá una quinta parte de lecturas físicas y / o lógicas.

Entonces, si el rendimiento es un problema, dada la oportunidad, siempre use una clave integral no significativa (llamada sustituto) para sus tablas y para las claves externas que hacen referencia a las filas en estas tablas ...

Al mismo tiempo , para garantizar la coherencia de los datos, cada tabla donde sea importante también debe tener una clave alternativa no numérica significativa (o índice único) para garantizar que no se puedan insertar filas duplicadas (duplicar en función de atributos de tabla significativos).

Para el uso específico del que está hablando (como las búsquedas de estado), realmente no importa porque el tamaño de la tabla es muy pequeño. En general, no hay impacto en el rendimiento de los índices en tablas con menos de unos pocos miles de filas. ..

Charles Bretana
fuente
¿Por supuesto? ¿La mayoría de los formatos de datos están basados ​​en filas? Hay otros datos aparte de las claves. ¿No es el factor 5 utópico?
ManuelSchneid3r
1
@ manuelSchneid3r, ¿qué? utópico? No, el factor 5 no es "utópico". Es solo 20 dividido por 4. ¿Y qué significa "basado en filas de formato de datos"? Los índices no están "basados ​​en filas", son estructuras de árbol equilibradas.
Charles Bretana
36

Absolutamente no.

He realizado varias ... varias ... comprobaciones de rendimiento entre INT, VARCHAR y CHAR.

La tabla de 10 millones de registros con una CLAVE PRIMARIA (única y agrupada) tenía exactamente la misma velocidad y rendimiento (y costo de subárbol) sin importar cuál de los tres usé.

Dicho esto ... use lo que sea mejor para su aplicación. No te preocupes por el rendimiento.

Timothy Khouri
fuente
42
no tiene sentido sin saber cuánto tiempo duraron los varchars ... Si tenían 100 bytes de ancho, garantizaba que no obtendría el mismo rendimiento que un int 4 byte
Charles Bretana
66
También sería útil saber qué base de datos está utilizando y qué versión de la base de datos. El ajuste de rendimiento casi siempre se trabaja y mejora de una versión a otra.
Dave Black el
VARCHAR definitivamente importa para el tamaño del índice. Y el índice determina cuánto puede caber en la memoria. Y los índices en la memoria son mucho, mucho más rápidos que los que no lo son. Podría ser que para sus filas de 10 millones, tenía 250 MB de memoria disponible para ese índice, y estaba bien. Pero si tiene filas de 100m, estará menos bien en esa memoria.
Paul Draper
9

Para códigos cortos, probablemente no haya diferencia. Esto es especialmente cierto ya que es probable que la tabla que contiene estos códigos sea muy pequeña (un par de miles de filas como máximo) y no cambie con frecuencia (cuándo es la última vez que agregamos un nuevo Estado de EE. UU.).

Para tablas más grandes con una variación más amplia entre la clave, esto puede ser peligroso. Piense en utilizar la dirección de correo electrónico / nombre de usuario de una tabla de usuario, por ejemplo. Qué sucede cuando tienes unos pocos millones de usuarios y algunos de esos usuarios tienen nombres largos o direcciones de correo electrónico. Ahora, cada vez que necesite unirse a esta tabla con esa tecla, se vuelve mucho más costoso.

Joel Coehoorn
fuente
2
¿Sabes con seguridad que esto sería costoso? ¿O solo estás adivinando?
Steve McLeod
Por supuesto, depende de la implementación de rdbms, pero por lo que entiendo, la mayoría de los servidores mantendrán el hash del valor real para fines de indexación. Aun así, e incluso si se trata de un hash relativamente corto (por ejemplo, 10 bytes), aún es más difícil comparar 2 hashes de 10 bytes que entradas de 2 4 bytes.
Joel Coehoorn
NUNCA use una clave larga (ancha) para las uniones ... Pero si es la mejor representación de lo que es único para las filas de la tabla, entonces es mejor que haya una clave única (o índice, que es lo mismo) en el tabla usando esos valores naturales. Las claves no están ahí para unirse, puedes unirte a cualquier cosa que tu corazón desee. Las claves están ahí para garantizar la coherencia de los datos.
Charles Bretana
6

En cuanto a la clave primaria, lo que físicamente hace que una fila sea única debe determinarse como clave principal.

Para una referencia como clave externa, usar un entero de incremento automático como sustituto es una buena idea por dos razones principales.
- Primero, generalmente hay menos gastos generales incurridos en la unión.
- En segundo lugar, si necesita actualizar la tabla que contiene el varchar único, entonces la actualización debe descender en cascada a todas las tablas secundarias y actualizarlas todas, así como los índices, mientras que con el sustituto int, solo tiene que actualizar el tabla maestra y sus índices.

El inconveniente de usar el sustituto es que posiblemente podría permitir cambiar el significado del sustituto:

ex.
id value
1 A
2 B
3 C

Update 3 to D
id value
1 A
2 B
3 D

Update 2 to C
id value
1 A
2 C
3 D

Update 3 to B
id value
1 A
2 C
3 B

Todo depende de lo que realmente necesita preocuparse en su estructura y lo que significa más.

LeppyR64
fuente
3

Casos comunes donde AUTO_INCREMENTduele un sustituto :

Un patrón de esquema común es una asignación de muchos a muchos :

CREATE TABLE map (
    id ... AUTO_INCREMENT,
    foo_id ...,
    bar_id ...,
    PRIMARY KEY(id),
    UNIQUE(foo_id, bar_id),
    INDEX(bar_id) );

El rendimiento de este patrón es mucho mejor, especialmente cuando se usa InnoDB:

CREATE TABLE map (
    # No surrogate
    foo_id ...,
    bar_id ...,
    PRIMARY KEY(foo_id, bar_id),
    INDEX      (bar_id, foo_id) );

¿Por qué?

  • Las claves secundarias de InnoDB necesitan una búsqueda adicional; moviendo el par al PK, eso se evita en una dirección.
  • El índice secundario está "cubriendo", por lo que no necesita la búsqueda adicional.
  • Esta tabla es más pequeña debido a la eliminación de idun índice.

Otro caso ( país ):

country_id INT ...
-- versus
country_code CHAR(2) CHARACTER SET ascii

Con demasiada frecuencia, el novato normaliza country_code en un byte 4 en INTlugar de utilizar una cadena 'natural' de 2 bytes, casi inmutable de 2 bytes. Más rápido, más pequeño, menos uniones, más legible.

Rick James
fuente
2

En HauteLook, cambiamos muchas de nuestras tablas para usar claves naturales. Experimentamos un aumento en el rendimiento en el mundo real. Como mencionas, muchas de nuestras consultas ahora usan menos combinaciones, lo que hace que las consultas sean más efectivas. Incluso usaremos una clave primaria compuesta si tiene sentido. Dicho esto, algunas tablas son más fáciles de trabajar si tienen una clave sustituta.

Además, si permite que las personas escriban interfaces en su base de datos, una clave sustituta puede ser útil. El tercero puede confiar en el hecho de que la clave sustituta cambiará solo en circunstancias muy raras.

Herman J. Radtke III
fuente
2

Me enfrenté al mismo dilema. Hice un DW (esquema de constelación) con 3 tablas de hechos, accidentes de tráfico, vehículos en accidentes y víctimas en accidentes. Los datos incluyen todos los accidentes registrados en el Reino Unido desde 1979 hasta 2012, y 60 tablas de dimensiones. En total, unos 20 millones de discos.

Tablas de hechos relaciones:

+----------+          +---------+
| Accident |>--------<| Vehicle |
+-----v----+ 1      * +----v----+
     1|                    |1
      |    +----------+    |
      +---<| Casualty |>---+
         * +----------+ *

RDMS: MySQL 5.6

Nativamente, el índice de Accidente es un varchar (números y letras), con 15 dígitos. Intenté no tener claves sustitutas, una vez que los índices de accidentes nunca cambiarían. En una computadora i7 (8 núcleos), el DW se volvió demasiado lento para consultar después de 12 millones de registros de carga, dependiendo de las dimensiones. Después de mucho volver a trabajar y agregar claves sustitutas bigint, obtuve un aumento promedio del rendimiento de velocidad del 20%. Sin embargo, a la baja ganancia de rendimiento, pero prueba válida. Estoy trabajando en MySQL tuning y clustering.

Diego Duarte
fuente
1
Suena como si necesitaras buscar particiones.
jcoffland
2

La pregunta es sobre MySQL, así que digo que hay una diferencia significativa. Si se trataba de Oracle (que almacena números como una cadena, sí, no podía creerlo al principio), entonces no hay mucha diferencia.

El almacenamiento en la tabla no es el problema, pero sí lo es actualizar y hacer referencia al índice. Las consultas que implican buscar un registro en función de su clave principal son frecuentes: desea que ocurran lo más rápido posible porque suceden con tanta frecuencia.

La cosa es que una CPU trata con 4 bytes y enteros de 8 bytes de forma natural, en silicio . Es REALMENTE rápido comparar dos enteros: ocurre en uno o dos ciclos de reloj.

Ahora mire una cadena: está compuesta por muchos caracteres (más de un byte por carácter en estos días). Comparar dos cadenas de precedencia no se puede hacer en uno o dos ciclos. En cambio, los caracteres de las cadenas deben iterarse hasta que se encuentre una diferencia. Estoy seguro de que hay trucos para hacerlo más rápido en algunas bases de datos, pero eso es irrelevante aquí porque la CPU realiza una comparación int de forma natural y muy rápida en silicio.

Mi regla general: cada clave principal debe ser un INT de aumento automático, especialmente en aplicaciones OO que usan un ORM (Hibernate, Datanucleus, lo que sea) donde hay muchas relaciones entre objetos; por lo general, siempre se implementarán como un FK simple y la capacidad para el La base de datos para resolverlos rápidamente es importante para la capacidad de respuesta de su aplicación.

Volksman
fuente
0

No estoy seguro de las implicaciones de rendimiento, pero parece que un posible compromiso, al menos durante el desarrollo, sería incluir tanto la clave "sustituta" entera auto-incrementada, como la clave "natural" única e intencionada. Esto le daría la oportunidad de evaluar el rendimiento, así como otros posibles problemas, incluida la posibilidad de cambiar las claves naturales.

Dexygen
fuente
0

Como de costumbre, no hay respuestas generales. '¡Depende!' y no estoy siendo gracioso Comprendí que la pregunta original era para las claves en tablas pequeñas, como Country (identificación entera o código char / varchar) que es una clave externa para una tabla potencialmente enorme como la tabla de dirección / contacto.

Hay dos escenarios aquí cuando desea recuperar datos de la base de datos. Primero es un tipo de consulta de lista / búsqueda donde desea enumerar todos los contactos con códigos o nombres de estado y país (los identificadores no ayudarán y, por lo tanto, necesitarán una búsqueda). El otro es un escenario de obtención en la clave primaria que muestra un solo registro de contacto donde se debe mostrar el nombre del estado, país.

Para este último, probablemente no importa en qué se base el FK ya que estamos reuniendo tablas para un solo registro o unos pocos registros y en lecturas clave. El primer escenario (búsqueda o lista) puede verse afectado por nuestra elección. Dado que es necesario mostrar el país (al menos un código reconocible y tal vez incluso la búsqueda en sí misma incluye un código de país), potencialmente no tener que unirse a otra tabla a través de una clave sustituta (solo estoy siendo cauteloso aquí porque en realidad no he probado esto, pero parece altamente probable) mejorar el rendimiento; a pesar del hecho de que ciertamente ayuda con la búsqueda.

Como los códigos son de tamaño pequeño, no más de 3 caracteres generalmente para el país y el estado, puede estar bien usar las claves naturales como claves foráneas en este escenario.

El otro escenario donde las claves dependen de valores varchar más largos y quizás de tablas más grandes; la clave sustituta probablemente tiene la ventaja.

Vinod
fuente
0

Permítanme decir que sí, definitivamente hay una diferencia, teniendo en cuenta el alcance del rendimiento (definición original):

1- El uso de sustituto int es más rápido en la aplicación porque no necesita usar ToUpper (), ToLower (), ToUpperInvarient () o ToLowerInvarient () en su código o en su consulta y estas 4 funciones tienen diferentes puntos de referencia de rendimiento. Consulte las reglas de rendimiento de Microsoft sobre esto. (rendimiento de la aplicación)

2- El uso de sustituto int garantiza no cambiar la clave con el tiempo. Incluso los códigos de país pueden cambiar, vea Wikipedia cómo los códigos ISO cambiaron con el tiempo. Eso llevaría mucho tiempo cambiar la clave primaria para los subárboles. (rendimiento del mantenimiento de datos)

3- Parece que hay problemas con las soluciones ORM, como NHibernate cuando PK / FK no es int. (rendimiento del desarrollador)

Shadi Namrouti
fuente