Discussão do artigo "Como acessar o banco de dados MySQL a partir do MQL5 (MQL4)" - página 29
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Obrigado pelo esclarecimento. Não posso saber tudo, por isso estou perguntando.
Encontrei a solução para mim aqui.
P.S: Verificado para SELECT - funciona
Bem, a conversão do resultado da consulta é permitida, mas não se esqueça de que você tem a definição utf8mb4 no nível da tabela, ou seja, para todos os campos, varchar será usado por padrão, e se você tiver uma condição em um campo de texto na sua consulta, o MySQL tentará convertê-lo implicitamente. E se você levar em conta que você pode ter um índice construído em uma coluna de texto, então o otimizador pode não pegá-lo durante essa conversão... daí os problemas com o desempenho da consulta.
há um campo de descrição. Algo como "comentários", o campo não é necessário, apenas uma explicação em texto. Não haverá índice.
O MySQL utf8mb4 faz isso por padrão. Você pode me dizer como especificar na DDL da próxima vez? O que mudar e para qual codificação?
Alguma ideia?
Continuo recebendo este erro:
Você conseguiu resolver esse problema, Boaz?
Existe alguma maneira de saber o número de campos que podem ser recuperados após MySqlCursorFetchRow?
Talvez alguma função oculta como RowFieldsSize ...
Pelo que entendi, se não houver nenhum campo, MySqlGetFieldAsString retornará vazio. Mas também se o String Field contiver especificamente um campo vazio, ele também retornará vazio. Ou seja, nem sempre é possível rastrear o número de campos por força bruta.
Como muleta, você pode descobrir primeiro por meio do comando sql e depois selecionar novamente, mas isso já é um Select desnecessário.
Por favor, desenvolva a biblioteca, pois ela é muito útil. É claro que, há muito tempo, um par de mysql foi incorporado ao mt
Consulta de inserção e atualização - limite de consulta de apenas 16 kb?
Se a consulta tiver mais de 16.000 caracteres, o metatrader trava (fecha); se tiver menos, não há problema.
Anexei um exemplo de UPDATE com 32.000 caracteres.
Campo para atualização no banco de dados - LONGTEXT
Consulta de inserção e atualização - limite de consulta de apenas 16kb?
Se a consulta tiver mais de 16.000 caracteres, o metatrader trava (fecha); se tiver menos, não há problema.
Anexei um exemplo de UPDATE com 32.000 caracteres.
Campo para atualização no banco de dados - LONGTEXT
Isso é mais parecido com um limite de tamanho de linha em MQL :-(
e você pode escrever de forma mais compacta:
REPLACE d1 ("t", "o", "h", "l", "c") VALUES (time1,open1,high1,low1,close1), (time2,open2,high2,low2,close2) ....
e/ou dividir em duas consultas, combinando-as em uma única transação
Por exemplo, tenho dados de 50.000 elementos e os atualizo na tabela a cada 0,1 segundo (números). O MT5 será capaz de capturá-los do MySQL e atualizá-los a cada 0,1 segundo? Existe alguma limitação da funcionalidade fornecida neste artigo sobre KB por 1 consulta?
Olá! Pergunta para especialistas - quantos dados e com que frequência posso ler do MySQL para o MT5?
Por exemplo, tenho dados de 50.000 elementos e os atualizo na tabela a cada 0,1 segundo (números). O MT5 será capaz de capturá-los do MySQL e atualizá-los a cada 0,1 segundo? Existe alguma limitação da funcionalidade fornecida neste artigo em KB para 1 consulta?
Bem, a pergunta é certamente interessante...
Devo dizer que não há limites para o número de linhas da consulta SELECT retornadas.
O limite de tamanho da consulta em si é de 64 Kb. Portanto, se estiver tentando atualizar 50 mil linhas de dados, é melhor dividi-las em lotes, digamos 1000 linhas cada, e assim enviar 50 consultas.
Quanto à velocidade de 100 ms, se você tiver o banco de dados em um servidor e o terminal no qual executa MQL com uma conexão com o banco de dados for um pouco remoto, é muito provável que você se depare com a latência da rede, do tamanho do ping....
Por exemplo, se você tiver um ping de 60 ms entre o servidor do banco de dados e o terminal, a resposta real do servidor será atrasada = 60 ms (consulta) + tempo de processamento da consulta no lado do banco de dados + 60 ms (resposta).
Este projeto é apenas um invólucro simples para acessar a funcionalidade das bibliotecas dinâmicas do mysql.
O conjunto de funcionalidades é limitado às principais funções úteis na prática; você pode expandir, adicionar o que precisar, por exemplo, adicionar suporte a consultas assíncronas e, então, poderá enviar todas as 50 consultas em 1000 linhas sem esperar pela execução de cada uma delas.
P.S.: no Github, você pode ver os códigos-fonte da biblioteca e os limites predefinidos(https://github.com/elugovoy/MQLMySQL-Project/tree/master/MQLMySQL).
P.P.S.: você também pode fazer download, modificar a seu critério, compilar e testar.
Existe alguma maneira de saber o número de campos que podem ser recuperados após o MySqlCursorFetchRow?
Talvez haja alguma função oculta como RowFieldsSize ...
Pelo que entendi, se não houver nenhum campo, MySqlGetFieldAsString retornará vazio. Mas também se String Field contiver especificamente um campo vazio, ele também retornará vazio. Ou seja, nem sempre é possível rastrear o número de campos por força bruta.
Você pode descobrir primeiro por meio do comando sql e depois selecionar novamente, mas isso já é um Select desnecessário.
Por favor, desenvolva a biblioteca, que é muito útil. É claro que alguns mysql deveriam ter sido incorporados ao mt há muito tempo
Hm... E que tipo de consultas são tão complicadas para você que é necessário determinar o número de campos retornados por elas?
Normalmente, no comando SELECT, liste apenas o que é necessário em uma situação específica. Não use SELECT *, selecione somente o que você precisa :) essa é uma prática normal.
Você não deve criar muletas, pode pegar o código-fonte do Github e adicionar um wrapper para a função mysql_fetch_fields() da API do MySQL