Expertos explican diez experiencias en optimización del rendimiento de SQL

Consulta de coincidencia aproximada

Intente evitar el uso del parámetro LIKE en una consulta compleja: el signo de porcentaje marcado en rojo hará que el índice de la columna correspondiente quede inutilizable. Es mejor no hacerlo. para usarlo

Solución:

De hecho, solo necesita mejorar ligeramente el script y la velocidad de consulta aumentará casi cien veces. El método de mejora es el siguiente

Solución:

De hecho, solo necesita mejorar ligeramente el script y la velocidad de consulta aumentará casi cien veces. p>

a Modificar el programa front-end: cambiar la consulta La columna de nombre del proveedor de la condición se ha cambiado de la entrada de texto original a una lista desplegable. Cuando el usuario ingresa vagamente el nombre del proveedor, puede hacerlo directamente. ayude a ubicar el proveedor específico en la recepción. De esta manera, al llamar al programa en segundo plano, esta columna se puede asociar directamente con iguales

b Modifique directamente el fondo: primero busque. seleccione proveedores calificados en función de las condiciones de entrada y guarde los registros relevantes en una tabla temporal, y luego use la tabla temporal para realizar asociaciones complejas

Problema de índice

Durante el proceso de análisis y seguimiento del desempeño, A menudo encontramos que muchos problemas de rendimiento del programa en segundo plano son causados ​​por la falta de índices adecuados. Algunas tablas o incluso ningún índice tienen esta situación. Esto a menudo se debe a que los índices no se definieron al diseñar la tabla. Los registros de la tabla son pocos, la creación de índices puede tener poco impacto en el rendimiento. Por lo tanto, los desarrolladores no le prestan mucha atención. Sin embargo, una vez que el programa se lanza al entorno de producción, la tabla cambia con el tiempo.

En este momento, el impacto de la falta de índices en el rendimiento será mayor

Este problema requiere la atención simultánea de los diseñadores y desarrolladores de bases de datos

p>

Reglas: No realice las siguientes operaciones en las columnas de datos del índice establecido:

◆Evite operaciones de cálculo en campos de índice ◆Evite usar not lt != en campos de índice ◆Evite usar IS NULL y; NO ES NULO en columnas indexadas; ◆Evitar la conversión de tipos de datos en columnas indexadas ◆Evitar el uso de funciones en campos indexados ◆Evitar el uso de valores nulos en columnas indexadas

Operaciones complejas

p><; p>Algunas declaraciones UPDATE SELECT son muy complejas de escribir (a menudo anidadas con subconsultas de varios niveles); puede considerar dividirlas en varios pasos para generar algunas tablas de datos temporales y luego realizar operaciones relacionadas

actualizar

p>

La modificación de la misma tabla ocurre docenas de veces en un proceso, como actualizar el conjunto de tablas col = donde col =; actualizar el conjunto de tablas col = donde col =

De hecho, scripts como este tipo Se puede integrar fácilmente en una declaración UPDATE (descubrí esta situación cuando ayudaba al proyecto xxx en el análisis de problemas de rendimiento hace algún tiempo)

Use UNION en la declaración donde se puede usar UNION ALL

UNION comparará los registros de cada subconjunto de consultas, por lo que suele ser mucho más lento que UNION ALL. En términos generales, si usa UNION ALL puede cumplir con los requisitos, debe usar UNION ALL. Hay otra situación en la que puede Qué. Lo que se ignorará es que, aunque es necesario filtrar la unión de varios subconjuntos de registros duplicados, debido a las particularidades del script, no pueden existir registros duplicados. En este caso, se debe usar UNION ALL. Por ejemplo, esta situación alguna vez existió. un programa de consulta del módulo xx Debido a la particularidad de la declaración, es absolutamente imposible repetir varios subconjuntos de registros en este script, por lo que se puede usar UNION ALL en su lugar)

Intente evitar operaciones de cálculo. en los campos de índice en la declaración WHERE

Creo que la mayoría de los desarrolladores deberían conocer este sentido común, pero todavía hay muchas personas que lo usan de esta manera. Creo que una de las razones principales puede ser que esté comprometido. la sencillez de la escritura.

El rendimiento no es recomendable

Al realizar un análisis de rendimiento en el sistema XX en marzo, descubrí que hay una gran cantidad de programas en segundo plano con un uso similar, como donde trunc(create_date)=trunc(:date )

Aunque el campo create_date ha sido indexado, el índice no se puede utilizar debido a la adición de TRUNC. La escritura correcta aquí debe ser donde create_dategt;=trunc(:date) y create_date

<. p>　O donde create_date ha sido trunc( ：date ) y trunc(：date ) /( * * )

Tenga en cuenta que el rango de been es un intervalo cerrado (mayor o igual al valor bajo y menor que o igual a valor alto), por lo que en sentido estricto se debe restar otro decimal. Aquí, configurémoslo temporalmente para restar segundos (/( * *)).

Reglas para declaraciones Where

Evita usar in not? in o have en la cláusula WHERE

Puedes usar exist y not exist en lugar de in y not en

Puede usar enlaces de tabla en lugar de existir. Usar donde en su lugar. Si no se puede reemplazar, se puede procesar en dos pasos.

Ejemplo SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT. EN (SELECCIONAR NOMBRE_CLIENTE DEL CLIENTE) Optimizar SELECCIONAR *? DE PEDIDOS DONDE NOMBRE_CLIENTE no existe (SELECCIONAR NOMBRE_CLIENTE DEL CLIENTE)

¿No declarar números en formato de caracteres en formato numérico (lo mismo para? fechas). De lo contrario, el índice no será válido y se generará un escaneo completo de la tabla. Por ejemplo, use SELECT emp ename emp job FROM emp WHERE emp empno = <; /p>

Reglas para declaraciones Select

Restringir el uso de select * from table en paquetes y procedimientos de aplicaciones. Consulte el ejemplo siguiente.

Utilice SELECT empno ename categoría FROM emp WHERE. empno = en lugar de SELECT * FROM emp WHERE empno =

Ordenar

Evite operaciones que consuman recursos con DISTINCT La declaración SQL de UNION MINUS INTERSECT ORDER BY iniciará el motor SQL para realizar la La función de clasificación que consume recursos (SORT) requiere una operación de clasificación, mientras que otras requieren al menos dos operaciones de clasificación.

Tabla temporal lishixinzhi/Article/program/ SQL/201311/16379