Navegación · Establecer como página de inicio · Agregar a favoritos · Móvil Tencent · Página de inicio de Tencent Noticias Blog Foro Comentarios Finanzas Valores Fondos de acciones de Hong Kong Entretenimiento Estrellas Películas Música Deportes NBA Fútbol Integral Autos Inmobiliaria Electrodomésticos Tecnología Digital Descargas móviles Mujeres Emociones Crianza Moda Compras Viajes Lectura Original Educación Ir al extranjero Juegos Anime Animación Constelaciones Video Imágenes en vivo Expo Caridad Niños Nuevo Disco de oro chino popular Visite el colorido mundo de la moda y los artículos de lujo Los teléfonos móviles más vendidos a nivel nacional Siga la lista de clasificación para ver qué celebridades cumplen años hoy Su ubicación: Tencent. Página de inicio > Tecnología y Digital > Noticias Scroll Digital > Texto
Catch-21 para el desarrollo de bases de datos de SQL Server http://digi.QQ.com 21 de diciembre de 2009 09:43 Zhongguancun Online Si es responsable de un proyecto basado en SQL Server, o es nuevo en SQL Server, puede que tenga Se enfrenta a algunos problemas de rendimiento de la base de datos y este artículo le proporcionará orientación útil (la mayoría de las cuales también se pueden utilizar con otros DBMS).
Aquí, no voy a presentar consejos para usar SQL Server, ni puedo proporcionar una panacea. Lo que hago es resumir algunas experiencias sobre cómo formar un buen diseño. Esta experiencia proviene 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.
1. Conozca las herramientas que utiliza
No subestimes esto, es el punto más crítico que voy a abordar en este artículo. Quizás también haya visto que muchos programadores de SQLServer no dominan todos los comandos T-SQL ni las útiles herramientas proporcionadas por SQLServer.
"¿Qué? ¿Voy a perder un mes aprendiendo comandos SQL que nunca usaré?", podrías decir. Bien, no es necesario que hagas esto. Pero deberías pasar un fin de semana revisando todos los comandos T-SQL. Su tarea aquí es comprender que en el futuro, cuando diseñe una consulta, recordará: "Por cierto, aquí hay un comando que puede lograr completamente la función que necesito", así que vaya a MSDN para verificar la sintaxis exacta de este comando.
Déjame repetirlo otra vez: no uses cursores. Si desea destruir el rendimiento de todo el sistema, son su primera opción más eficaz. La mayoría de los principiantes utilizan cursores sin darse cuenta del impacto que tienen en el rendimiento. Ocupan memoria, cierran mesas con todas sus extrañas formas y funcionan como un caracol. Y lo peor es que pueden hacer que toda la optimización del rendimiento que su DBA pueda hacer sea equivalente a no hacerlo. ¿Sabes que cada vez que ejecutas FETCH, ejecutas un comando SELECT? ¡Esto significa que si su cursor tiene 10,000 registros, realizará 10,000 SELECCIONES! Será mucho más eficiente si utiliza un conjunto de SELECCIONAR, ACTUALIZAR o ELIMINAR para completar el trabajo correspondiente.
Los principiantes generalmente piensan que usar cursores es una forma más familiar y cómoda de programar, pero desafortunadamente, esto puede conducir a un rendimiento deficiente. Obviamente, el propósito general de SQL es lo que se quiere lograr, no cómo.
Una vez reescribí un procedimiento almacenado basado en cursor usando T-SQL. La tabla solo tenía 100.000 registros. El procedimiento almacenado original tardó 40 minutos en completarse, pero el nuevo procedimiento almacenado solo tardó 10 segundos. ¡Aquí creo que deberías poder ver lo que está haciendo un programador incompetente! ! !
A veces podemos escribir un pequeño programa para recuperar y procesar datos y actualizar la base de datos, lo que a veces es más eficiente. Recuerde: T-SQL no puede hacer nada con respecto a los bucles.
Déjame recordarte de nuevo: no hay ningún beneficio en usar cursores. Nunca he visto nada hecho de manera efectiva usando cursores, excepto el trabajo de DBA.
3. Estandariza tus tablas de datos
¿Por qué no normalizar la base de datos? Probablemente haya dos excusas: motivos de rendimiento y pura pereza. En cuanto al segundo punto, tarde o temprano habrá que pagarlo. Y en cuanto al rendimiento, no es necesario optimizar algo que no sea nada lento. A menudo veo programadores "desnormalizando" una base de datos porque el motivo es "el diseño original era demasiado lento", pero a menudo el resultado es que hacen que el sistema sea más lento. DBMS está diseñado para manejar bases de datos canónicas, así que recuerde: diseñe la base de datos de acuerdo con los requisitos de canonicalización.
4. No utilice SELECCIONAR *
Esto no es fácil de hacer, lo sé muy bien, porque lo hago yo mismo todo el tiempo. Sin embargo, si especifica las columnas que necesita en SELECT, obtendrá los siguientes beneficios:
1 Reducir el consumo de memoria y el ancho de banda de la red.
2 Puedes conseguir un diseño más seguro
3 Déle al optimizador de consultas la oportunidad de leer todas las columnas requeridas del índice.
Página 2: Comprenda lo que va a hacer con sus datos
Crear un índice sólido para su base de datos es algo bueno. Pero hacer esto es simplemente un arte. Siempre que agregue un índice a una tabla, SELECCIONAR será más rápido, pero INSERTAR y ELIMINAR serán significativamente más lentos porque crear y mantener el índice requiere mucho trabajo adicional. Obviamente, la clave de la pregunta aquí es: qué tipo de operación desea realizar en esta mesa. Este problema 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.
6. No cree un índice en la columna "Género"
Primero, debemos entender cómo los índices aceleran el acceso a una tabla. Puede pensar en los índices como una forma de dividir una tabla según ciertos criterios. Si creas un índice en una columna como "género", simplemente estás dividiendo la tabla en dos partes: masculina y femenina. Se trata de una tabla con 1.000.000 de registros. ¿Cuál es el significado de esta división? Recuerde: mantener índices requiere mucho tiempo. Al diseñar el índice, siga esta regla: ordene las columnas de mayor a menor según la cantidad de contenidos diferentes que pueda contener la columna, como por ejemplo: nombre + provincia + género.
7. Utilice transacciones
Utilice transacciones, especialmente cuando las consultas requieran mucho tiempo. Si algo sale mal con su sistema, esto le salvará la vida. Generalmente, los programadores con cierta experiencia comprenderán que a menudo se encuentran situaciones impredecibles que provocarán que el procedimiento almacenado falle.
8. Cuidado con los puntos muertos
Accede a tus tablas en un orden determinado. Si bloquea la tabla A primero y luego bloquea la tabla B, deben bloquearse en este orden en todos los procedimientos almacenados. Si (accidentalmente) bloquea la tabla B primero 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 detectar.
Una pregunta frecuente es: ¿Cómo puedo agregar rápidamente 100.000 registros a un ComboBox? Esto no está bien y no puedes ni necesitas hacerlo. Es muy simple si tu usuario tiene que buscar 100.000 registros para encontrar el registro que necesita, definitivamente te maldecirá. Aquí, lo que necesita es una mejor interfaz de usuario y no debe mostrar más de 100 o 200 registros a sus usuarios.
En comparación con los cursores del lado del servidor, los cursores del lado del cliente pueden reducir la sobrecarga del servidor y de la red y también reducir el tiempo de bloqueo.
11. Utilice consulta de parámetros
A veces, veo preguntas como esta en el foro técnico de CSDN: "SELECT * FROM aWHEREa.id='A'B, se produce una excepción debido a una consulta con comillas simples, ¿qué debo hacer?", y la respuesta común es: usar dos Comillas simples en lugar de comillas simples. Esto está mal. Esto trata los síntomas en lugar de la causa raíz, porque también encontrará problemas similares con otros personajes, sin mencionar que causará errores graves. Además, esto también impedirá que el sistema de almacenamiento en búfer de SQL Server funcione como debería. Al utilizar la consulta de parámetros, todos estos problemas desaparecen.
12. Utilice grandes bases de datos al codificar programas.
La base de datos de prueba utilizada por los programadores en desarrollo generalmente no tiene una gran cantidad de datos, pero a menudo el usuario final tiene una gran cantidad de datos. Nuestro enfoque habitual es incorrecto y la razón es muy simple: los discos duros no son muy caros ahora, pero ¿por qué los problemas de rendimiento no se notan hasta que son irreversibles?
13. No utilice INSERT para importar grandes cantidades de datos
Por favor, no hagas esto a menos que sea absolutamente necesario. Utilice UTS o BCP para obtener flexibilidad y velocidad de una sola vez.
14. Preste atención a los problemas de tiempo de espera
Al consultar la base de datos, el valor predeterminado de la base de datos general es relativamente pequeño, como 15 segundos o 30 segundos. Algunas consultas tardan más en ejecutarse, especialmente cuando la cantidad de datos en la base de datos continúa aumentando.
Página 3: No ignore el problema de modificar el mismo registro al mismo tiempo
15. No ignores el problema de modificar el mismo registro al mismo tiempo.
A veces, dos usuarios modificarán el mismo registro al mismo tiempo, de esta manera, si el último modificador modifica las operaciones del modificador anterior, algunas actualizaciones se perderán. Manejar esta situación no es difícil: cree un campo de marca de tiempo, verifíquelo antes de escribir, combine las modificaciones si está permitido y avise al usuario si hay un conflicto.
16. Al insertar registros en la tabla de detalles, no ejecute SELECT MAX(ID) en la tabla principal
Este es un error común que causa errores cuando dos usuarios insertan datos al mismo tiempo. Puede utilizar SCOPE_IDENTITY, IDENT_CURRENT e IDENTITY. Si es posible, no utilice IDENTITY, ya que puede causar problemas en presencia de desencadenantes (consulte la discusión aquí).
17. Evite configurar columnas como NULLable
Si es posible, debe evitar que las columnas sean NULL. El sistema asignará un byte adicional para cada fila de la columna NULLable, lo que provocará una mayor sobrecarga del sistema al realizar consultas. Además, hacer que las columnas sean NULL complica la codificación porque estas columnas deben verificarse cada vez que se accede a ellas.
No estoy diciendo que los NULLS sean una fuente de problemas, aunque algunas personas así lo creen. Creo que hacer una columna NULLable a veces puede funcionar bien si sus reglas comerciales permiten "datos nulos", pero usar NULLable en una situación como la siguiente genera problemas.
NombreDeCliente1
Dirección del cliente1
ClienteCorreo electrónico1
NombreDeCliente2
Dirección del cliente2
Correo electrónico del cliente3
NombreDeCliente1
Dirección del cliente2
Correo electrónico del cliente3
Si esto sucede, necesita normalizar su tabla.
18. Intente no utilizar el tipo de datos TEXTO
No utilice TEXTO a menos que esté tratando con un conjunto de datos muy grande. Porque no es fácil de consultar, es lento y desperdiciará mucho espacio si no se usa correctamente. En general, VARCHAR puede manejar mejor sus datos.
19. Intenta no utilizar tablas temporales.
Intente no utilizar tablas temporales a menos que sea absolutamente necesario. Generalmente, se pueden utilizar subconsultas en lugar de tablas temporales. El uso de tablas temporales generará una sobrecarga del sistema y, si está programando con COM+, también le traerá muchos problemas, porque COM+ usa un grupo de conexiones de base de datos y la tabla temporal existe de principio a fin. SQL Server ofrece algunas alternativas, como el tipo de datos Tabla.
20. Aprende a analizar y consultar
SQL Server Query Analyzer es su mejor amigo, a través del cual puede comprender cómo las consultas y los índices afectan el rendimiento.
21. Utilice la integridad referencial
Definir claves primarias, restricciones únicas y claves externas puede ahorrar mucho tiempo.