Sugerencias para agilizar SELECT. Incluir JOIN?

193 views
Skip to first unread message

Zarlu

unread,
Sep 30, 2020, 5:03:20 PM9/30/20
to Comunidad de Visual Foxpro en Español
Buenas tardes foxeros!

Tengo una búsqueda que tarda espantosos segundos y creo son demasiados para el volumen de registros

VFP9 SP2
Tengo dos tablas nativas:
Tabla:testis&&15000 registros de los cuales 726 cumplen la condición de ubicación
campo exped&&tiene indice
campo ubicacion&&tiene indice

Tabla: recep&&50000 registros
campos: exped&&tiene indice
campos escritura&&tiene indice

Requiero por cada registro de la tabla testimonios con ubicación="X", obtener el campo escritura de la tabla recep

Ya probé estos códigos:
Select testis.exped, recep.escritura From testis, recep Where testis.exped==recep.exped .and. testis.ubicacion Like "%X%"

Select  testis.exped, recep.escritura From testis JOIN recep ON recep.numexped==testis.expediente;
 .and. testis.ubicacion like "%X%";
*-aquí ya alterné tabla derecha e izquierda, ya probe left join y right join

Gracias
zarlu
Chetumal, Quintana Roo, México

Carlos Miguel FARIAS

unread,
Sep 30, 2020, 6:13:02 PM9/30/20
to Grupo Fox
Aunque tengan índices las tablas, antes de efectuar el SELECT, ¡desactivarlos!
La ubicación es igual a "X", o debe contener una "X"?
Si tiene que ser igual, mejor codificar testis.ubicacion = "X"
Si eso es correcto (igual a, y no que contiene) un índice sobre testis.ubicación puede mejorar algo (sobre todo si un % < 20% cumple con ese requisito)
Rushmore usa los índices que existan pero no tienen que estar activados. El activa por su cuenta los índices que les sirva o crea algunos temporales
Saludos: Miguel

--
Visita el Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/2cf8e11f-f0c5-4db8-9181-2f1d9be2d95cn%40googlegroups.com.

Zarlu

unread,
Sep 30, 2020, 6:35:49 PM9/30/20
to Comunidad de Visual Foxpro en Español
Gracias Miguel!

Probadas todas tus sugerencias.
Sigo igual

zarlu
Chetumal, Quintana Roo, México

Luis suescún

unread,
Sep 30, 2020, 7:08:45 PM9/30/20
to publice...@googlegroups.com
inner join también?
si la bd está normalizada y debería de haber integridad referencial entonces el inner join mejora mucho

Carlos Miguel FARIAS

unread,
Oct 1, 2020, 9:29:24 AM10/1/20
to Grupo Fox
Pero el filtro es sobre  testis.ubicacion Like "%X%" testis.ubicacion = "X"?
recep.numexped es el que usas para asociar las tablas pero dices que tienes índice recep.exped? Es un error cortar y pegar o realmente es así?
La consulta es en una máquina local o sobre un servidor?
El disco está de-fragmentado? (Por experiencia, procesos de 15' se extendía a 5 o 6 horas solo por estar el disco fragmentado).
Saludos: Miguel

ggcagnola gmail

unread,
Oct 1, 2020, 9:32:58 AM10/1/20
to publice...@googlegroups.com

el like ES LENTO siempre...

Antonio Lima

unread,
Oct 1, 2020, 9:50:15 AM10/1/20
to publice...@googlegroups.com
Hola a Todos,

ggcagnola tiene razón ,  los likes siempre son lentos ( son secuenciales)

Pero puedes probar esto:

Primero que nada ambas tablas deben de estar indexados por los campos testis.Expediente  y recep.NumExped  

Si crees que no hay muchos registros de ubicación para cada Expediente puedes hacer un select con subconsultas  
por ejemplo primero obtener todos los registros que  testis.Expediente  == recep.NumExped    y luego hacer una consulta con el like 

select * from (
select testis.exped, recep.escritura from testis
inner join recep on recep.NumExped = testis.Expediente ) tmp
where tmp.ubicacion like "%X%"

Saludos,

Carlos Miguel FARIAS

unread,
Oct 1, 2020, 9:52:45 AM10/1/20
to Grupo Fox
Si, iba a proponer lo mismo, pero si lees lo que plantea, los indices estan sobre exped, y conecta con exped cuando junta desde el where y usa otros campos con el join.
Ahí al menos hay una inconsistencia de enunciado.
Mejor que aclare, porque posiblemente lo que le propongamos no tiene nada que ver con lo que plantea (por error en el planteo)
Saludos: MIguel

Carlos Miguel FARIAS

unread,
Oct 1, 2020, 9:54:52 AM10/1/20
to Grupo Fox
Si, el like que puede ser mejorado un poco es cuando la parte variable es al final, por ejemplo "X%", pero si es "%X%" el índice no sirve y se tiene que comer todos los registros.
Por eso pregunte si era por X contenida o por igual a X (y si el filtro no selecciona menos de un 20% de los registros, tampoco sirve).
Mirando nuevamente lo que das como base observo que:
Mencionas índices sobre exped (en ambas tablas) pero el join lo haces sobre exped (cuando haces filtro completo por where) pero en el join utilizas numexped y expediente
Puedes aclarar?
Saludos: Miguel


Zarlu

unread,
Oct 1, 2020, 11:00:58 AM10/1/20
to Comunidad de Visual Foxpro en Español
Buenos días foxeros!

Miguel, ggcagnol, ideasgt, luisandrey........gracias a todos!
Estoy por probar sus últimas sugerencias.

Si hay un problema de planteamiento en el segundo select, DISCULPENME. Los campos e índices "exped" son iguales

Ya probé estos códigos: (aquí corregido)

Select testis.exped, recep.escritura From testis, recep Where testis.exped==recep.exped .and. testis.ubicacion Like "%X%"

Select  testis.exped, recep.escritura From testis JOIN recep ON recep.exped==testis.exped;

 .and. testis.ubicacion like "%X%";
*-aquí ya alterné tabla derecha e izquierda, ya probe left join y right join
zarlu
Chetumal, Quintana Roo, México

Marcos Godoy

unread,
Oct 1, 2020, 11:01:22 AM10/1/20
to publice...@googlegroups.com
Agrega un indice  asi:

index on deleted() tag borrados
y probá



--
Marcos E. D. Godoy
Alicia Moreau de Justo 1120
te: (54 -11) 5365-8767 Interno 2005

Zarlu

unread,
Oct 1, 2020, 7:46:47 PM10/1/20
to Comunidad de Visual Foxpro en Español
Les comento foxeros!
Una sopa de mi propio chocolate...

Tenia el indice sobre Alltrim(ubicacion). No permitía una consulta óptima. No me había percatado.

Mis comentarios:
Los indices sobre Deleted() ya los tenía.
Desactivarlos (SET ORDER TO) no es relevante. Como menciona el colega VFP usa los que optimicen.
Incluir una subconsulta lo demoró más
Funcionó mejor usando "<>" en lugar de "like" ó "="
No usé JOIN (en sintaxis)

Logré optimizar la consulta. Aunque la rapidez no depende sólo de eso.
Reduje el tiempo en primera ejecución de .1167 segundos hasta .0333
optimis.png
Éste artículo me ha servido antes se los dejo de nuevo:
https://comunidadvfp.blogspot.com/2014/09/visual-foxpro-y-la-optimizacion-rushmore.html

Gracias a todos
zarlu
Chetumal, Quintana Roo, México




HernanCano

unread,
Oct 2, 2020, 2:55:12 AM10/2/20
to Comunidad de Visual Foxpro en Español
Bien, muy bien, Zarlu.
Estoy haciendo también unos estudios (sobre un caso particular), y esta info me sirve a lo grande.

Gracias por compartir.

Antonio Lima

unread,
Oct 2, 2020, 3:06:25 AM10/2/20
to publice...@googlegroups.com
Excelente noticia, y un buen trabajo.  Lo que sería ideal es que pudieras compartirnos la consulta, y cómo has sacado la imagen.   la consulta es realmente sencilla me ha quedado duda como la has optimizado.

Un saludo

--
Visita el Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Zarlu

unread,
Oct 2, 2020, 11:00:56 AM10/2/20
to Comunidad de Visual Foxpro en Español
Buenos días ide...@gmail.com!

En mi consulta el detalle principal era que tenía un indice formado con Alltrim(ubicación). Eliminé Alltrim(). Eso me permitió optimizar
(Comentario: la estructura de las comparaciones de la búsqueda debe ser semejante a la del índice y opino es mejor no usar funciones)
Y como dice el artículo los índices sobre Deleted()

La sintaxis final quedó así:
Select testis.exped, recep.escritura From testis, recep Where testis.exped=recep.exped .and. testis.ubicacion<>"ENTREGADO"&&el código inicial era "Like "%ENTREGAR%"

El código para obtener el resultado de optimización es:
lcIni=Val(sys(2))
=SYS(3054,11,"cmemvar")
*aquí el Select * From...
? cmemvar
?
? "Tiempo: "
?? (Val(sys(2))-lcIni)/60.

Optimización no precisamente es velocidad, pero es ideal. También intervienen otras cuestiones físicas (red), tamaño de la información, sintaxis del select.....

zarlu
Chetumal, Quintana Roo, México

mpulla

unread,
Oct 2, 2020, 2:07:13 PM10/2/20
to Comunidad de Visual Foxpro en Español
Hola Zarlu.

Como recomendación, la sintaxis con que escribes Sql es ANSI-89, para ANSI-92 y posteriores se usa Inner Join, Left Join, etc. es mas legible y el rendimiento no se ve afectado.

Saludos.
Mauricio

Zarlu

unread,
Oct 2, 2020, 3:17:54 PM10/2/20
to Comunidad de Visual Foxpro en Español
Buenas tardes jmaur...@yahoo.es !

Se te agradece.

Si percibí una diferencia de rendimiento, pero MUY mínima y por costumbre opté por la "vieja" sintaxis que lleva implícito un join.

zarlu
Chetumal, Quintana Roo, México


Reply all
Reply to author
Forward
0 new messages