Tentando localizar o erro

[JoséQuintas]

Deixei programação de lado... fui no mercado fazer compras...

Acho que já sei qual é o problema, o mesmo que acontecia com pedidos.
Preciso acabar com campos chave caractere - a mistura disso.
Dependendo da situação, acho que o MySQL despreza qualquer índice nesses casos.

Isso chegou a acontecer com pedidos.

[bencz]

bom, isso não é para ser um problema... basta criar o índice...
Lembre-se somente, que na hora de criar o índice, existe uma ordem correta para se colocar os campos...

Código: Selecionar todos

CREATE INDEX JPESTOQUE_IDX ON JPESTOQUE (ESTRANSA, ESPORDUTO, ESDATLAN, ESTIPLAN, ESQTDE, ESCFPOP, ESCFOP);

O campo, ESTRANSA, é o campo chave... os demais são os campos incluídos no índice....
Faça um teste com aqueles 3 indices que passei e veja se existe uma melhora na busca

[JoséQuintas]

bom, isso não é para ser um problema... basta criar o índice...

Nos clientes, IDCADASTRO é numérico, e nos pedidos era caractere.
O estoque é recém chegado ao MySQL, o campo de IDPRODUTO é caractere, mas no cadastro de produtos é numérico.
Essa mistura é normal no MySQL, mas conforme a situação causa uma lentidão tremenda,

LEFT JOIN ... ON JPESTOQUE.ESPRODUTO (VARCHAR) = JPPRODUTO.IDPRODUTO (INT)

Tinha me esquecido que isso aconteceu com pedidos e clientes, e somente em algumas pesquisas.
Por isso acho que deve ser a mesma coisa, mas agora com produtos.

NÃO é problema do MySQL, ele até faz muito em relacionar 1 com "000001".
Em querys mais simples isso funciona normalmente, mas em outras pode acontecer a lentidão.

O aplicativo vinha trabalhando como caractere, pro DBF, usando StrZero(x,6) na gravação.
No MYSQL procurei usar campos incremental, então tiveram que ser numéricos.
Pra gravação dupla, mantive caractere pra outros campos "não chave".
Há algum tempo estou deixando só numérico no aplicativo, e desvinculando dessa necessidade dos meus DBFs antigos/compatíveis.

Próximo passo:
Definitivamente só usar caractere na leitura/gravação de DBF - se ainda existir o DBF.
E no MySQL, obrigatoriamente deixar numérico em TUDO, não apenas aonde é chave primária.

Nota:
Não se trata do MySQL não aceitar número ou caractere.
É de usar código de produto no cadastro como sendo numérico, e no movimento de estoque o código do produto como caractere.
Digamos que durante a migração foi possível fazer errado, mas chegou a hora de fazer certo.

Ainda vou poder usar na gravação: SET CODIGO = "000001", mesmo se o campo for numérico.
Isso basta pra continuar com a gravação dupla, até acabar com o DBF de vez.

[bencz]

Foi o que falei nesse comentário: viewtopic.php?f=57&t=24045#p139387

Verifique se os campos "<APELIDO JPTRANSA>.IDTRANSA" e "<APELIDO JPESTOQUE>.ESTRANSA" são do mesmo tipo e verifique a mesma coisa para o outro join

[JoséQuintas]

Foi o que falei nesse comentário: viewtopic.php?f=57&t=24045#p139387

Não percebi, mas já tinha acontecido isso antes.

Já estava caminhando pra deixar tudo numérico.
Até comentei aqui no fórum: as telas sem os zeros ficam mais "limpas".
Então, estou no caminho certo, já estava "resolvendo" o problema, sem perceber que era esse o problema.

De qualquer jeito, todas as alterações agora são pra eliminar DBF, então... sem problemas alterar no banco de dados.
Só que agora vai ser mais pesado, talvez alterar até tudo de uma vez.

Tem que ficar em casa mesmo, em quarentena.... ótimo pra dar uma geral nos fontes.

[asimoes]

Rodei o profiler e vi a falta de um índice, em uma tabela com 4 registros, que é a tabela "FYSCO_SituacaoProcuracoes"... ao criar o índice o tempo de execução da query caiu em 4ms....

Onde baixa o profiler?

[asimoes]

Já achei no HeidiSQL

[janio]

aSimoes
Já achei no HeidiSQL

Onde?

[asimoes]

Onde?

Pra usar o SHOW PROFILE ALL; tem que deixar a caixa Perfil de Consultas, desmarcada

Código: Selecionar todos

SHOW PROFILE ALL;
SELECT
*
FROM
asaprev.cobrancaasaprev c
-- WHERE
-- c.CODIGO = '20735'

[bencz]

Bom dia!
Utilizo esse programa: https://www.devart.com/dbforge/mysql/st ... nload.html

[asimoes]

Gostei disso: EXPLAIN SELECT * FROM cadastrosocios

Código: Selecionar todos

MariaDB [test]> EXPLAIN SELECT * FROM t1 INNER JOIN t2 INNER JOIN t3 WHERE t1.a=t2.a AND t2.a=t3.a;
+------+-------------+-------+------+---------------+------+---------+------+------+--------------------------------------------------------+
| id   | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra                                                  |
+------+-------------+-------+------+---------------+------+---------+------+------+--------------------------------------------------------+
|    1 | SIMPLE      | t1    | ALL  | NULL          | NULL | NULL    | NULL |    3 |                                                        |
|    1 | SIMPLE      | t2    | ALL  | NULL          | NULL | NULL    | NULL |    3 | Using where; Using join buffer (flat, BNL join)        |
|    1 | SIMPLE      | t3    | ALL  | NULL          | NULL | NULL    | NULL |    3 | Using where; Using join buffer (incremental, BNL join) |
+------+-------------+-------+------+---------------+------+---------+------+------+--------------------------------------------------------+

[asimoes]

Agora tem que entender essas informações