Notas sobre las bases de datos de SQL Server

Si es responsable de un proyecto basado en SQL Server o es nuevo en SQL Server, es probable que enfrente algunos problemas de rendimiento de la base de datos. Este artículo le brindará orientación útil (la mayoría de las cuales son). también se puede usar con otros DBMS)

Aquí no voy a presentar consejos para usar SQL Server ni puedo proporcionar una solución panacea. Lo que hago es resumir algunas experiencias sobre cómo formar una buena. diseño. Estas lecciones provienen de lo que he aprendido en los últimos años, donde he visto muchos de los mismos errores de diseño repetidos una y otra vez.

¿Conoce las herramientas que utiliza?

No subestimes esto. Este es el punto más crítico del que hablo en este artículo. Quizás también hayas visto que muchos programadores de SQL Server no dominan todos los comandos de T SQL y los proporcionados por SQL Server. . Herramientas útiles

¿Qué? ¿Voy a perder un mes aprendiendo comandos SQL que nunca usaré? Puede decir que no necesita hacer esto, pero debería pasar un fin de semana repasando todos los comandos de T SQL. Su tarea es comprender lo que recordará en el futuro cuando diseñe una consulta. Aquí hay un comando que hace exactamente eso Para lograr la funcionalidad que necesitaba, fui a MSDN para verificar la sintaxis exacta de este comando

No use cursores

Déjame repetir Nuevamente, no use cursores si desea destruir. En términos de rendimiento general del sistema, son su primera opción más efectiva. La mayoría de los principiantes usan cursores sin darse cuenta del impacto que tienen en el rendimiento. Ocupan memoria y bloquean todas las tablas. de maneras extrañas, y se mueven a paso de tortuga. Lo peor es que pueden hacer toda la optimización del rendimiento que su DBA no puede hacer. Me pregunto si sabe que cada ejecución de FETCH es igual a la ejecución de SELECT. ¿dominio? ¡Esto significa que si su cursor tiene registros, realizará SELECCIONAR tiempos! Será mucho más eficiente si usa un conjunto de SELECCIONAR ACTUALIZAR o ELIMINAR para completar el trabajo correspondiente

Los principiantes generalmente piensan que usar cursores es un método de programación más familiar y cómodo, pero desafortunadamente esto puede conducir a malos resultados. Obviamente, el propósito general de SQL es lo que desea lograr en lugar de cómo lograrlo.

Una vez usé T SQL para reescribir un procedimiento almacenado basado en cursor. La tabla solo tenía un registro. tomó minutos. La ejecución del nuevo procedimiento almacenado tomó solo unos segundos. ¡Aquí creo que puedes ver lo que está haciendo un programador incompetente! ! !

Podemos escribir un pequeño programa para obtener y procesar los datos y actualizar la base de datos. Esto a veces es más eficiente. Recuerde que no hay nada que pueda hacer con respecto al bucle de T SQL.

Les recuerdo nuevamente que no hay ningún beneficio en usar cursores. Nunca he visto ningún trabajo realizado de manera efectiva usando cursores excepto el trabajo de DBA

Normalice sus tablas de datos

¿Por qué no normalizar el? ¿base de datos? Probablemente haya dos excusas: consideraciones de rendimiento y pura pereza. En cuanto al segundo punto, tarde o temprano tendrás que pagar por ello. En cuanto al rendimiento, no es necesario optimizar algo que no sea lento en absoluto. desnormalizan la base de datos. Su razón es que el diseño original es demasiado lento, pero el resultado es que a menudo hacen que el sistema DBMS esté diseñado para manejar bases de datos canónicas, así que recuerde diseñar la base de datos de acuerdo con los requisitos canónicos.

No use SELECT *

Esto no es fácil de hacer. Lo sé muy bien porque a menudo lo hago yo mismo, pero si especifica las columnas que necesita en SELECT, aparecerá lo siguiente. beneficios

Reduce el consumo de memoria y el ancho de banda de la red

Puede lograr un diseño más seguro

Dale al optimizador de consultas la oportunidad de leer todas las columnas requeridas del índice

Comprenda lo que va a hacer con los datos

Para su

Crear un índice sólido en una base de datos es una bendición. Hacerlo es casi un arte. Siempre que agrega un índice a una tabla, SELECT es más rápido, pero INSERT y DELETE son significativamente más lentos debido a que la creación y el mantenimiento de los índices. trabajo extra. Obviamente, la clave del problema aquí es qué tipo de operaciones desea realizar en esta tabla. Esta pregunta no es fácil de entender, especialmente cuando se trata de ELIMINAR y ACTUALIZAR porque estas declaraciones a menudo contienen comandos SELECT en la parte WHERE.

No cree un índice para la columna de género

Primero debemos entender cómo los índices aceleran el acceso a las tablas. Puede entender los índices como una forma de dividir tablas según ciertos criterios. Si crea un índice en una columna como género, simplemente divide la tabla en dos partes: masculino y femenino. ¿Cuál es el significado de esta división? Recuerde que mantener un índice requiere mucho tiempo. Cuando diseñe un índice, siga esta regla y ordénelo de mayor a menor según la cantidad de contenidos diferentes que pueda contener la columna, como nombre, provincia, género.

Utilice transacciones

Utilice transacciones, especialmente cuando la consulta lleva mucho tiempo. Si hay un problema con el sistema, esto le salvará la vida. Generalmente, los programadores con cierta experiencia lo entenderán. a menudo se encuentra con situaciones impredecibles que causarán que el procedimiento almacenado falle.

Tenga cuidado con los interbloqueos

Acceda a sus tablas en un orden determinado si bloquea la tabla A primero y luego bloquea la tabla B. , entonces debe bloquearlos en este orden en todos los procedimientos almacenados. Si (sin darse cuenta) bloquea primero la tabla B y luego bloquea la tabla A en un procedimiento almacenado, esto puede causar un punto muerto si la secuencia de bloqueo no se diseña en detalle de antemano. , el punto muerto no es fácil de encontrar

No abra grandes conjuntos de datos

En el foro técnico de CSDN :) Una pregunta que se hace a menudo es ¿cómo puedo agregar registros rápidamente al ¿Cuadro combinado? Esto está mal. No puedes ni necesitas hacer esto. Es muy simple. Tu usuario tiene que buscar registros para encontrar el registro que necesita. Lo que necesitas aquí es una mejor interfaz de usuario. necesita mostrarlo a sus usuarios más de o registros

No utilice cursores del lado del servidor

En comparación con los cursores del lado del servidor, los cursores del lado del cliente pueden reducir el servidor y el sistema de red. gastos generales y también reducir el tiempo de bloqueo

Uso de consulta de parámetros

A veces veo preguntas como esta en el foro técnico de CSDN: SELECT * FROM a WHERE a id= A B ¿Qué debo hacer porque un ¿Se produce una excepción en la consulta de comillas simples? La respuesta común es usar dos comillas simples en lugar de comillas simples. Esto es incorrecto. Trata los síntomas pero no la causa raíz porque también encontrará problemas similares con otros caracteres. , hacerlo también provocará errores graves. El sistema de almacenamiento en búfer de SQL Server no puede desempeñar su función debida. Problemas como el uso de consultas de parámetros para eliminar el problema desaparecen por completo

Uso de bases de datos de gran tamaño al codificar programas

Los programadores están desarrollando La base de datos de prueba utilizada en la base de datos de prueba generalmente tiene una pequeña cantidad de datos, pero a menudo la cantidad de datos del usuario final es muy grande. Nuestro método habitual es incorrecto. Hoy en día los discos duros no son muy caros. ¿Por qué los problemas de rendimiento tienen que esperar hasta que sean irreparables?

No utilice INSERT para importar grandes cantidades de datos

No haga esto a menos que sea necesario. Utilice UTS o BCP para obtener flexibilidad y velocidad en uno. cayó en picado

Preste atención al problema del tiempo de espera

Al consultar la base de datos, la configuración predeterminada de la base de datos suele ser relativamente pequeña, como segundos o segundos. Algunas consultas se ejecutarán por más tiempo. esto, especialmente cuando la cantidad de datos en la base de datos continúa aumentando

No ignores el problema de modificar el mismo registro al mismo tiempo

A veces dos usuarios modificarán el mismo registrar al mismo tiempo. Si el último modificador modifica la operación del modificador anterior, algunas actualizaciones se perderán. Este proceso En este caso no es difícil crear un tiempo.

El campo amp se verifica antes de escribir. Si está permitido, combine las modificaciones y avise al usuario si hay un conflicto.

Al insertar registros en la tabla de detalles, no ejecute SELECT MAX(ID) en la tabla principal. table.

Este es un error común cuando dos usuarios insertan datos al mismo tiempo. Esto causará un error. Puede usar SCOPE_IDENTITY IDENT_CURRENT y @@IDENTITY. Si es posible, no use @@IDENTITY ya que causará algunos errores. problemas en caso de activadores (detalles (Ver discusión aquí)

Evite hacer que las columnas sean NULLable

Si es posible, debe evitar hacer que las columnas sean NULLable. El sistema asigna un byte adicional para cada fila de un Columna NULLable. Incurre en más gastos generales al realizar consultas. Además, hacer columnas NULLable complica la codificación porque deben verificarse cada vez que se accede a ellas.

No estoy diciendo que los NULL sean una fuente de problemas, aunque para algunas personas. Eso creo. Creo que hacer una columna NULLable a veces puede funcionar bien si sus reglas comerciales permiten datos nulos, pero si usa NULLable en una situación como la siguiente, está buscando problemas

CustomerName CustomerAddress CustomerEmail CustomerName CustomerAddress. CustomerEmail CustomerName CustomerAddress CustomerEmail

Si esto sucede, necesita normalizar su tabla

Intente no usar el tipo de datos TEXT

A menos que use TEXT para procesar un gran cantidad de datos, no lo use porque no es fácil de consultar, es lento, no es fácil de usar y desperdicia mucho espacio. Generalmente, VARCHAR puede procesar mejor sus datos

Intente no hacerlo. use tablas temporales

Intente no usar tablas temporales a menos que sea necesario. Generalmente, se pueden usar subconsultas en lugar de tablas temporales. Si está programando, también generará una sobrecarga en el sistema. Usted es un gran problema porque se utiliza el grupo de conexiones de la base de datos y la tabla temporal existe de principio a fin. SQL Server proporciona algunas alternativas, como el tipo de datos de tabla

Aprende a analizar consultas

SQL. El analizador de consultas del servidor es su buen socio. A través de él puede comprender cómo las consultas y los índices afectan el rendimiento

Usando la integridad referencial lishixinzhi/Article/program/SQLServer/201311/22158