sql-server - update - variable de tabla sql server 2012

¿Cuál es la diferencia entre una tabla temporal y una variable de tabla en SQL Server?

Question

En SQL Server 2005, podemos crear tablas temporales de dos formas:

declare @tmp table (Col1 int, Col2 int);

o

create table #tmp (Col1 int, Col2 int);

¿Cuáles son las diferencias entre estos dos? He leído opiniones conflictivas sobre si @tmp todavía usa tempdb, o si todo sucede en la memoria.

¿En qué escenarios uno supera al otro?

Answer 1

¿En qué escenarios uno supera al otro?

Para tablas más pequeñas (menos de 1000 filas) use una variable temporal, de lo contrario use una tabla temporal.

Answer 2

1. Tabla temporal: Una tabla temporal es fácil de crear y respaldar datos.

   Variable de tabla: pero la variable de tabla implica el esfuerzo cuando normalmente creamos las tablas normales.

2. Tabla temporal: el resultado de la tabla temporal puede ser utilizado por varios usuarios.

   Variable de tabla: pero la variable de tabla solo puede ser utilizada por el usuario actual.

3. Tabla temporal: la tabla temporal se almacenará en el tempdb. Hará tráfico de red. Cuando tenemos datos grandes en la tabla temporal, entonces tiene que funcionar en toda la base de datos. Existirá un problema de rendimiento.

   Variable de la tabla: pero una variable de la tabla almacenará en la memoria física para algunos de los datos, y luego, cuando el tamaño aumente, se moverá al tempdb.

4. Tabla temporal: la tabla temporal puede realizar todas las operaciones DDL. Permite crear los índices, soltar, alterar, etc.,

   Variable de tabla: mientras que la variable de tabla no permitirá realizar las operaciones DDL. Pero la variable de tabla nos permite crear solo el índice agrupado.

5. Tabla de temperatura: la tabla de temperatura se puede usar para la sesión actual o global. Para que una sesión de múltiples usuarios pueda utilizar los resultados en la tabla.

   Variable de tabla: pero la variable de tabla se puede utilizar hasta ese programa. (Procedimiento almacenado)

6. Tabla temporal: la variable temporal no puede usar las transacciones. Cuando hacemos las operaciones DML con la tabla temporal, entonces se puede revertir o confirmar las transacciones.

   Variable de tabla: Pero no podemos hacerlo para la variable de tabla.

7. Tabla temporal: Las funciones no pueden usar la variable temporal. Más allá no podemos hacer la operación DML en las funciones.

   Variable de tabla: Pero la función nos permite usar la variable de tabla. Pero usando la variable de tabla podemos hacer eso.

8. Tabla temporal: el procedimiento almacenado hará la recompilación (no se puede usar el mismo plan de ejecución) cuando usamos la variable temporal para todas las llamadas subsiguientes.

   Variable de tabla: mientras que la variable de tabla no funciona así.

Answer 3

@wcm: en realidad, para seleccionar la variable de tabla no es solo RAM, se puede almacenar parcialmente en el disco.

Una tabla temporal puede tener índices, mientras que una variable de tabla solo puede tener un índice primario. Si la velocidad es un problema, las variables de la tabla pueden ser más rápidas, pero obviamente si hay muchos registros, o la necesidad de buscar en la tabla temporal de un índice agrupado, una tabla temporal sería mejor.

Buen artículo de fondo

Answer 4

Cita tomada de; Profesionales de SQL Server 2012 Internos y solución de problemas

Estadísticas La principal diferencia entre las tablas temporales y las variables de tabla es que las estadísticas no se crean en las variables de tabla. Esto tiene dos consecuencias principales, la primera de las cuales es que el Optimizador de consultas utiliza una estimación fija para el número de filas en una variable de tabla, independientemente de los datos que contenga. Además, agregar o eliminar datos no cambia la estimación.

Índices No puede crear índices en las variables de la tabla, aunque puede crear restricciones. Esto significa que al crear claves primarias o restricciones únicas, puede tener índices (ya que se crean para admitir restricciones) en las variables de la tabla. Incluso si tiene restricciones y, por lo tanto, índices que tendrán estadísticas, los índices no se utilizarán cuando se compile la consulta porque no existirán en el momento de la compilación, ni tampoco causarán recompilaciones.

Modificaciones de esquema Las modificaciones de esquema son posibles en tablas temporales pero no en variables de tabla. Aunque las modificaciones de esquemas son posibles en tablas temporales, evite usarlas porque causan recompilaciones de sentencias que usan las tablas.

Las variables de tabla no se crean en la memoria.

Existe una idea errónea de que las variables de tabla son estructuras en memoria y, como tales, se ejecutarán más rápido que las tablas temporales . Gracias a un DMV llamado sys. dm _ db _ session _ espacio _ uso, que muestra el uso de tempdb por sesión, puede probar que ese no es el caso . Después de reiniciar SQL Server para borrar el DMV, ejecute el siguiente script para confirmar que su sesión _ id devuelve 0 para el usuario _ objetos _ asignar _ página _ cuenta:

SELECT session_id,
database_id,
user_objects_alloc_page_count
FROM sys.dm_db_session_space_usage
WHERE session_id > 50 ;

Ahora puede verificar cuánto espacio utiliza una tabla temporal ejecutando el siguiente script para crear una tabla temporal con una columna y rellenarla con una fila:

CREATE TABLE #TempTable ( ID INT ) ;
INSERT INTO #TempTable ( ID )
VALUES ( 1 ) ;
GO
SELECT session_id,
database_id,
user_objects_alloc_page_count
FROM sys.dm_db_session_space_usage
WHERE session_id > 50 ;

Los resultados en mi servidor indican que a la tabla se le asignó una página en tempdb. Ahora ejecute el mismo script pero use una variable de tabla esta vez:

DECLARE @TempTable TABLE ( ID INT ) ;
INSERT INTO @TempTable ( ID )
VALUES ( 1 ) ;
GO
SELECT session_id,
database_id,
user_objects_alloc_page_count
FROM sys.dm_db_session_space_usage
WHERE session_id > 50 ;

¿Cuál utilizar?

El uso o no de tablas temporales o variables de tabla debe decidirse mediante pruebas exhaustivas, pero es mejor inclinarse hacia las tablas temporales como el valor predeterminado porque hay muchas menos cosas que pueden salir mal .

He visto a los clientes desarrollar código utilizando variables de tabla porque trataban con una pequeña cantidad de filas, y era más rápido que una tabla temporal, pero unos años más tarde había cientos de miles de filas en la variable de tabla y el rendimiento era terrible , ¡así que intente y permita cierta planificación de capacidad cuando tome su decisión!

Answer 5

Considere también que a menudo puede reemplazar ambos con tablas derivadas, que también pueden ser más rápidas. Sin embargo, al igual que con todos los ajustes de rendimiento, solo las pruebas reales con sus datos reales pueden indicar el mejor enfoque para su consulta particular.

Answer 6

Existen algunas diferencias entre las tablas temporales (#tmp) y las variables de tabla (@tmp), aunque el uso de tempdb no es una de ellas, como se explica en el enlace de MSDN a continuación.

Como regla general, para volúmenes de datos pequeños a medianos y escenarios de uso simples, debe usar variables de tabla. (Esta es una guía demasiado amplia con, por supuesto, muchas excepciones; consulte a continuación y los siguientes artículos).

Algunos puntos a considerar al elegir entre ellos:

• Las tablas temporales son tablas reales, por lo que puede hacer cosas como CREAR ÍNDICES, etc. Si tiene grandes cantidades de datos para los cuales el acceso por índice será más rápido, las tablas temporales son una buena opción.

• Las variables de tabla pueden tener índices mediante el uso de restricciones PRIMARY KEY o UNIQUE. (Si desea un índice no único, simplemente incluya la columna de clave principal como última columna en la restricción única. Si no tiene una columna única, puede usar una columna de identidad). SQL 2014 también tiene índices no únicos .

• Las variables de la tabla no participan en las transacciones y los SELECT están implícitamente con NOLOCK . El comportamiento de la transacción puede ser muy útil, por ejemplo, si desea ROLLBACK a la mitad de un procedimiento, las variables de la tabla que se completaron durante esa transacción aún se completarán.

• Las tablas temporales pueden hacer que los procedimientos almacenados se vuelvan a compilar, tal vez a menudo. Las variables de la tabla no lo harán.

• Puede crear una tabla temporal utilizando SELECT INTO, que puede ser más rápida de escribir (útil para consultas ad hoc) y puede permitirle lidiar con el cambio de los tipos de datos a lo largo del tiempo, ya que no necesita definir su estructura de tabla temporal por adelantado.

• Puede volver a pasar las variables de la tabla desde las funciones, lo que le permite encapsular y reutilizar la lógica mucho más fácilmente (por ejemplo, hacer que una función divida una cadena en una tabla de valores en un delimitador arbitrario).

• El uso de Variables de tabla dentro de las funciones definidas por el usuario permite que esas funciones se usen más ampliamente (consulte la documentación de CREAR FUNCIÓN para obtener más detalles). Si está escribiendo una función, debe usar variables de tabla sobre tablas temporales, a menos que exista una necesidad imperiosa de lo contrario.

• Tanto las variables de tabla como las tablas temporales se almacenan en tempdb. Pero las variables de la tabla (desde 2005) están predeterminadas en la compilación de la base de datos actual frente a las tablas temporales que toman la intercalación predeterminada de tempdb ( ref ). Esto significa que debe tener en cuenta los problemas de intercalación si el uso de tablas temporales y su combinación de db es diferente a las de tempdb, causando problemas si desea comparar los datos de la tabla temporal con los datos de su base de datos.

• Las tablas temporales globales (## tmp) son otro tipo de tabla temporal disponible para todas las sesiones y usuarios.

Algunas lecturas adicionales:

• La gran respuesta de Martin Smith en dba.stackexchange.com

• Preguntas frecuentes de MSDN sobre la diferencia entre las dos: https://support.microsoft.com/en-gb/kb/305977

• Artículo del blog de MDSN: http://blogs.msdn.com/sqlserverstorageengine/archive/2008/03/30/sql-server-table-variable-vs-local-temporary-table.aspx

• Artículo: http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1267047,00.html#

• Comportamientos inesperados e implicaciones de rendimiento de las tablas temporales y las variables temporales: Paul White en SQLblog.com

Answer 7

La otra diferencia principal es que las variables de la tabla no tienen estadísticas de columna, como lo hacen las tablas temporales. Esto significa que el optimizador de consultas no sabe cuántas filas hay en la variable de la tabla (adivina 1), lo que puede hacer que se generen planes altamente no óptimos si la variable de la tabla en realidad tiene un gran número de filas.

Answer 8

Otra diferencia:

Solo se puede acceder a una tabla var desde sentencias dentro del procedimiento que la crea, no desde otros procedimientos llamados por ese procedimiento o SQL dinámico anidado (a través de exec o sp_executesql).

El alcance de una tabla temporal, por otro lado, incluye código en procedimientos llamados y SQL dinámico anidado.

Si la tabla creada por su procedimiento debe ser accesible desde otros procedimientos llamados o SQL dinámico, debe usar una tabla temporal. Esto puede ser muy útil en situaciones complejas.

Answer 9

Para todos ustedes que creen en el mito de que las variables temporales solo están en la memoria

Primero, la variable de tabla NO es necesariamente residente en memoria. Bajo la presión de la memoria, las páginas que pertenecen a una variable de tabla se pueden desplazar a tempdb.

Lea el artículo aquí: http://blogs.msdn.com/sqlserverstorageengine/archive/2008/03/30/sql-server-table-variable-vs-local-temporary-table.aspx

Answer 10

Solo mirando la reclamación en la respuesta aceptada, las variables de la tabla no participan en el registro.

En general, parece falso que haya alguna diferencia en la cantidad de registro (al menos para las operaciones de insert / update / delete en la tabla en sí, aunque desde entonces he descubierto que existe una pequeña diferencia en este sentido para los objetos temporales almacenados en caché en los procedimientos almacenados debido a actualizaciones adicionales de la tabla del sistema).

@table_variable el comportamiento de registro en una tabla @table_variable y una tabla #temp para las siguientes operaciones.

1. Insertar con éxito
2. Inserción de múltiples filas donde la instrucción se revierte debido a una violación de la restricción.
3. Actualizar
4. Borrar
5. Desasignar

Los registros de registro de transacciones fueron casi idénticos para todas las operaciones.

La versión de la variable de la tabla en realidad tiene algunas entradas de registro adicionales porque se agrega una entrada (y luego se elimina) de la tabla base sys.syssingleobjrefs , pero en general se registraron unos pocos bytes menos sys.syssingleobjrefs como el nombre interno de las variables de la tabla consume 236 menos bytes que para #temp tablas #temp (118 menos nvarchar caracteres).

Script completo para reproducir (es mejor ejecutarlo en una instancia iniciada en modo de usuario único y usando el modo sqlcmd )

:setvar tablename "@T"
:setvar tablescript "DECLARE @T TABLE"
/*
--Uncomment this section to test a #temp table
:setvar tablename "#T"
:setvar tablescript "CREATE TABLE #T"
*/
USE tempdb
GO
CHECKPOINT
DECLARE @LSN NVARCHAR(25)
SELECT @LSN = MAX([Current LSN])
FROM fn_dblog(null, null)
EXEC(N''BEGIN TRAN StartBatch
SAVE TRAN StartBatch
COMMIT
$(tablescript)
(
[4CA996AC-C7E1-48B5-B48A-E721E7A435F0] INT PRIMARY KEY DEFAULT 0,
InRowFiller char(7000) DEFAULT ''''A'''',
OffRowFiller varchar(8000) DEFAULT REPLICATE(''''B'''',8000),
LOBFiller varchar(max) DEFAULT REPLICATE(cast(''''C'''' as varchar(max)),10000)
)
BEGIN TRAN InsertFirstRow
SAVE TRAN InsertFirstRow
COMMIT
INSERT INTO $(tablename)
DEFAULT VALUES
BEGIN TRAN Insert9Rows
SAVE TRAN Insert9Rows
COMMIT
INSERT INTO $(tablename) ([4CA996AC-C7E1-48B5-B48A-E721E7A435F0])
SELECT TOP 9 ROW_NUMBER() OVER (ORDER BY (SELECT 0))
FROM sys.all_columns
BEGIN TRAN InsertFailure
SAVE TRAN InsertFailure
COMMIT
/*Try and Insert 10 rows, the 10th one will cause a constraint violation*/
BEGIN TRY
INSERT INTO $(tablename) ([4CA996AC-C7E1-48B5-B48A-E721E7A435F0])
SELECT TOP (10) (10 + ROW_NUMBER() OVER (ORDER BY (SELECT 0))) % 20
FROM sys.all_columns
END TRY
BEGIN CATCH
PRINT ERROR_MESSAGE()
END CATCH
BEGIN TRAN Update10Rows
SAVE TRAN Update10Rows
COMMIT
UPDATE $(tablename)
SET InRowFiller = LOWER(InRowFiller),
OffRowFiller =LOWER(OffRowFiller),
LOBFiller =LOWER(LOBFiller)
BEGIN TRAN Delete10Rows
SAVE TRAN Delete10Rows
COMMIT
DELETE FROM $(tablename)
BEGIN TRAN AfterDelete
SAVE TRAN AfterDelete
COMMIT
BEGIN TRAN EndBatch
SAVE TRAN EndBatch
COMMIT'')
DECLARE @LSN_HEX NVARCHAR(25) =
CAST(CAST(CONVERT(varbinary,SUBSTRING(@LSN, 1, 8),2) AS INT) AS VARCHAR) + '':'' +
CAST(CAST(CONVERT(varbinary,SUBSTRING(@LSN, 10, 8),2) AS INT) AS VARCHAR) + '':'' +
CAST(CAST(CONVERT(varbinary,SUBSTRING(@LSN, 19, 4),2) AS INT) AS VARCHAR)
SELECT
[Operation],
[Context],
[AllocUnitName],
[Transaction Name],
[Description]
FROM fn_dblog(@LSN_HEX, null) AS D
WHERE [Current LSN] > @LSN
SELECT CASE
WHEN GROUPING(Operation) = 1 THEN ''Total''
ELSE Operation
END AS Operation,
Context,
AllocUnitName,
COALESCE(SUM([Log Record Length]), 0) AS [Size in Bytes],
COUNT(*) AS Cnt
FROM fn_dblog(@LSN_HEX, null) AS D
WHERE [Current LSN] > @LSN
GROUP BY GROUPING SETS((Operation, Context, AllocUnitName),())

Resultados

+-----------------------+--------------------+---------------------------+---------------+------+---------------+------+------------------+
| | | | @TV | #TV | |
+-----------------------+--------------------+---------------------------+---------------+------+---------------+------+------------------+
| Operation | Context | AllocUnitName | Size in Bytes | Cnt | Size in Bytes | Cnt | Difference Bytes |
+-----------------------+--------------------+---------------------------+---------------+------+---------------+------+------------------+
| LOP_ABORT_XACT | LCX_NULL | | 52 | 1 | 52 | 1 | |
| LOP_BEGIN_XACT | LCX_NULL | | 6056 | 50 | 6056 | 50 | |
| LOP_COMMIT_XACT | LCX_NULL | | 2548 | 49 | 2548 | 49 | |
| LOP_COUNT_DELTA | LCX_CLUSTERED | sys.sysallocunits.clust | 624 | 3 | 624 | 3 | |
| LOP_COUNT_DELTA | LCX_CLUSTERED | sys.sysrowsets.clust | 208 | 1 | 208 | 1 | |
| LOP_COUNT_DELTA | LCX_CLUSTERED | sys.sysrscols.clst | 832 | 4 | 832 | 4 | |
| LOP_CREATE_ALLOCCHAIN | LCX_NULL | | 120 | 3 | 120 | 3 | |
| LOP_DELETE_ROWS | LCX_INDEX_INTERIOR | Unknown Alloc Unit | 720 | 9 | 720 | 9 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysallocunits.clust | 444 | 3 | 444 | 3 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysallocunits.nc | 276 | 3 | 276 | 3 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.syscolpars.clst | 628 | 4 | 628 | 4 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.syscolpars.nc | 484 | 4 | 484 | 4 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysidxstats.clst | 176 | 1 | 176 | 1 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysidxstats.nc | 144 | 1 | 144 | 1 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysiscols.clst | 100 | 1 | 100 | 1 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysiscols.nc1 | 88 | 1 | 88 | 1 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysobjvalues.clst | 596 | 5 | 596 | 5 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysrowsets.clust | 132 | 1 | 132 | 1 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysrscols.clst | 528 | 4 | 528 | 4 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysschobjs.clst | 1040 | 6 | 1276 | 6 | 236 |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysschobjs.nc1 | 820 | 6 | 1060 | 6 | 240 |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysschobjs.nc2 | 820 | 6 | 1060 | 6 | 240 |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.sysschobjs.nc3 | 480 | 6 | 480 | 6 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.syssingleobjrefs.clst | 96 | 1 | | | -96 |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | sys.syssingleobjrefs.nc1 | 88 | 1 | | | -88 |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | Unknown Alloc Unit | 72092 | 19 | 72092 | 19 | |
| LOP_DELETE_ROWS | LCX_TEXT_MIX | Unknown Alloc Unit | 16348 | 37 | 16348 | 37 | |
| LOP_FORMAT_PAGE | LCX_HEAP | Unknown Alloc Unit | 1596 | 19 | 1596 | 19 | |
| LOP_FORMAT_PAGE | LCX_IAM | Unknown Alloc Unit | 252 | 3 | 252 | 3 | |
| LOP_FORMAT_PAGE | LCX_INDEX_INTERIOR | Unknown Alloc Unit | 84 | 1 | 84 | 1 | |
| LOP_FORMAT_PAGE | LCX_TEXT_MIX | Unknown Alloc Unit | 4788 | 57 | 4788 | 57 | |
| LOP_HOBT_DDL | LCX_NULL | | 108 | 3 | 108 | 3 | |
| LOP_HOBT_DELTA | LCX_NULL | | 9600 | 150 | 9600 | 150 | |
| LOP_INSERT_ROWS | LCX_CLUSTERED | sys.sysallocunits.clust | 456 | 3 | 456 | 3 | |
| LOP_INSERT_ROWS | LCX_CLUSTERED | sys.syscolpars.clst | 644 | 4 | 644 | 4 | |
| LOP_INSERT_ROWS | LCX_CLUSTERED | sys.sysidxstats.clst | 180 | 1 | 180 | 1 | |
| LOP_INSERT_ROWS | LCX_CLUSTERED | sys.sysiscols.clst | 104 | 1 | 104 | 1 | |
| LOP_INSERT_ROWS | LCX_CLUSTERED | sys.sysobjvalues.clst | 616 | 5 | 616 | 5 | |
| LOP_INSERT_ROWS | LCX_CLUSTERED | sys.sysrowsets.clust | 136 | 1 | 136 | 1 | |
| LOP_INSERT_ROWS | LCX_CLUSTERED | sys.sysrscols.clst | 544 | 4 | 544 | 4 | |
| LOP_INSERT_ROWS | LCX_CLUSTERED | sys.sysschobjs.clst | 1064 | 6 | 1300 | 6 | 236 |
| LOP_INSERT_ROWS | LCX_CLUSTERED | sys.syssingleobjrefs.clst | 100 | 1 | | | -100 |
| LOP_INSERT_ROWS | LCX_CLUSTERED | Unknown Alloc Unit | 135888 | 19 | 135888 | 19 | |
| LOP_INSERT_ROWS | LCX_INDEX_INTERIOR | Unknown Alloc Unit | 1596 | 19 | 1596 | 19 | |
| LOP_INSERT_ROWS | LCX_INDEX_LEAF | sys.sysallocunits.nc | 288 | 3 | 288 | 3 | |
| LOP_INSERT_ROWS | LCX_INDEX_LEAF | sys.syscolpars.nc | 500 | 4 | 500 | 4 | |
| LOP_INSERT_ROWS | LCX_INDEX_LEAF | sys.sysidxstats.nc | 148 | 1 | 148 | 1 | |
| LOP_INSERT_ROWS | LCX_INDEX_LEAF | sys.sysiscols.nc1 | 92 | 1 | 92 | 1 | |
| LOP_INSERT_ROWS | LCX_INDEX_LEAF | sys.sysschobjs.nc1 | 844 | 6 | 1084 | 6 | 240 |
| LOP_INSERT_ROWS | LCX_INDEX_LEAF | sys.sysschobjs.nc2 | 844 | 6 | 1084 | 6 | 240 |
| LOP_INSERT_ROWS | LCX_INDEX_LEAF | sys.sysschobjs.nc3 | 504 | 6 | 504 | 6 | |
| LOP_INSERT_ROWS | LCX_INDEX_LEAF | sys.syssingleobjrefs.nc1 | 92 | 1 | | | -92 |
| LOP_INSERT_ROWS | LCX_TEXT_MIX | Unknown Alloc Unit | 5112 | 71 | 5112 | 71 | |
| LOP_MARK_SAVEPOINT | LCX_NULL | | 508 | 8 | 508 | 8 | |
| LOP_MODIFY_COLUMNS | LCX_CLUSTERED | Unknown Alloc Unit | 1560 | 10 | 1560 | 10 | |
| LOP_MODIFY_HEADER | LCX_HEAP | Unknown Alloc Unit | 3780 | 45 | 3780 | 45 | |
| LOP_MODIFY_ROW | LCX_CLUSTERED | sys.syscolpars.clst | 384 | 4 | 384 | 4 | |
| LOP_MODIFY_ROW | LCX_CLUSTERED | sys.sysidxstats.clst | 100 | 1 | 100 | 1 | |
| LOP_MODIFY_ROW | LCX_CLUSTERED | sys.sysrowsets.clust | 92 | 1 | 92 | 1 | |
| LOP_MODIFY_ROW | LCX_CLUSTERED | sys.sysschobjs.clst | 1144 | 13 | 1144 | 13 | |
| LOP_MODIFY_ROW | LCX_IAM | Unknown Alloc Unit | 4224 | 48 | 4224 | 48 | |
| LOP_MODIFY_ROW | LCX_PFS | Unknown Alloc Unit | 13632 | 169 | 13632 | 169 | |
| LOP_MODIFY_ROW | LCX_TEXT_MIX | Unknown Alloc Unit | 108640 | 120 | 108640 | 120 | |
| LOP_ROOT_CHANGE | LCX_CLUSTERED | sys.sysallocunits.clust | 960 | 10 | 960 | 10 | |
| LOP_SET_BITS | LCX_GAM | Unknown Alloc Unit | 1200 | 20 | 1200 | 20 | |
| LOP_SET_BITS | LCX_IAM | Unknown Alloc Unit | 1080 | 18 | 1080 | 18 | |
| LOP_SET_BITS | LCX_SGAM | Unknown Alloc Unit | 120 | 2 | 120 | 2 | |
| LOP_SHRINK_NOOP | LCX_NULL | | | | 32 | 1 | 32 |
+-----------------------+--------------------+---------------------------+---------------+------+---------------+------+------------------+
| Total | | | 410144 | 1095 | 411232 | 1092 | 1088 |
+-----------------------+--------------------+---------------------------+---------------+------+---------------+------+------------------+

Answer 11

Tabla temporal

Las tablas temporales se comportan como tablas reales pero se crean en tiempo de ejecución. Su trabajo es similar al de la mesa real. Podemos hacer casi todas las operaciones posibles en tablas reales. Podemos usar sentencias DDL como ALTER, CREAR, DROP en tablas temporales.

Cualquier cambio en la estructura de la tabla temporal es posible después de la creación. Tabla temporal almacenada en la base de datos "tempdb" de las bases de datos del sistema.

La tabla temporal participa en las transacciones, el registro o el bloqueo. Debido a esa razón es más lento que la Tabla Variable.

Variable de tabla

Es variable pero funciona como una mesa. También se crea en la base de datos Tempdb no en la memoria. Variable de tabla solo disponible en el lote o en el alcance del procedimiento almacenado. No es necesario eliminar la Variable de la tabla, se elimina automáticamente cuando se completa el proceso de ejecución del procedimiento de almacenamiento y lote

La variable de tabla admite clave principal, identidad en el momento de la creación. Pero no soporta índice no agrupado. Después de declarar la clave primaria, la identidad no se puede modificar.

Las variables de la tabla no participan en las transacciones, el registro o el bloqueo. Las transacciones, el registro y el bloqueo no afectan a las variables de tabla.

Lee este artículo para más información - http://goo.gl/GXtXqz