Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Pessoal olha minha select
$sql = mysql_query("SELECT
findupls.XREF,A questão é, eu preciso juntar estas tabelas para trazer o resultado todo, sem paginação, o problema é, que cada tabela destas te em média 70 mil registros.
E ai que esta a questão, mesmo que eu coloque um limit 100 ali continua não trazendo nenhum registro.
Alguém sabe o motivo ou como melhorar essa query para trazer os resultados?
Tentei até mesmo usar o codeigniter para fazer o select para ver se era algo na programação do cliente mas no code é a mesma coisa não traz nada, então estou supondo que é o sql, mas não vejo erro ou como melhorar, alguém poderia ajudar?
Convenhamos: 70 mil registros numa pancada só, é muita coisa para retornar ao usuário.
Concordo plenamente com o hufersil, acho que ir mostrando o conteudo quando o usuarioi vai rolando a pagina seria uma alternativa para o seu problema...
Você pode quebrar essa query em 3 e juntar em um array assossiativo.
Na primeira query você pega todos os ids e nas outras duas você faz algo como
SELECT * FROM tabela WHERE xref IN (1,2,3,4....N)
Redstyle, apesar de parecer "distribuir" o processamento, você apenas vai estar fazendo consumo do servidor PHP e realizando mais transações de dados entre servidor e SGBD.
Além de que, prefira o uso de JOINS ao invés de subqueries. Em sistemas já em produção, tive vários problemas de performance com subquery quando a base de dados atingia um tamanho considerável.
Joins é uma excelente escolha, mas a má engenharia resultará sempre em lentidão. Como o Huserfil já comentou, índeces/indexes de longe é uma poderosa solução para aumento de performance em consultas "custosas". Se não me engano, o MySQL possui um suporte mais básico ao indexes, diferente de outros SGBDs como PostgreSQL, Oracle, SQL Server.
A diferença chega a ser gritante. Tenho casos de pesquisas que demoravam de 2 a 3 minutos, que com a criação de indexes passaram a demorar apenas 3 segundos (testado em SGBD PostgreSQL).
Convenhamos: 70 mil registros numa pancada só, é muita coisa para retornar ao usuário.
Você precisa realmente apresentar os 70 mil sem paginação?
Na minha cabeça isso não tem sentido algum.
Sobre a demora, pode ser inumeras coisas, mas as que me ocorrem de imediato:
-
índices - verifique se os campos utilizados no join possuem índices entre eles;
-
restrição de dados com where - eu ainda acho que você poderia filtrar os dados com alguma condição, e nesta condição, coloque índices;
-
order by - o order by feito em uma coluna sem índice também é "performance killer"
O "limit 100" que você colocou ali não "inflói nem contribói", porque ele só faz o limit depois de toda a query plan ser analisada E executada (além de ordenada, que também consome recursos pra kct).
Para ter uma ideia do que o banco está fazendo, execute
EXPLAIN <sua consulta>
Isso irá lhe mostrar o plano de consulta. Execute em um terminal ou o seu programa de consultas preferido.
Coloque os resultados aqui.
@braços