Esta é a quarta e ultima postagem, sobre a tematica das limitações do MySQL em alguns casos de uso ( você pode visualizar as postagens anteriores nos links 1, 2 e 3

MySQL trata-se de um processo único com variados segmentos, nem todos os bancos de dados são arquitetados desta forma, alguns possuem múltiplos processos que se comunicam através de memória compartilhada ou outros meios.

É muito barato e viável criar uma conexão com MySQL, pois ele exige a criação de uma thread, isso geralmente é tão rápido e simples que não se faz necessário a utilização de pools como em outros bancos de dados do mercado, um outro ponto interessante é o threading que sempre dará o seu apoio, no ambiente Linux o threading atualmente encontra-se em um bom estado diferente de tempos atrás.

Muitos ambientes de desenvolvimento e linguagem de programação utilizam pool de conexões. São sempre construídos da mesma maneira como no caso do JAVA, em outros casos usam conexão persistente por padrão, de modo que a conexão não é realmente fechado quando ele está fechado, funcionando como um tipo especifico de pool de conexão, exceto quando a solicitação de conexão encontra-se no mesmo processo .

Pools de conexão e conexões persistentes combinadas com um grande número de servidores de aplicação pode levar a uma situação em que o servidor e o banco de dados tem um número muito grande de conexões abertas,os quais não estão fazendo nada.

Não é incomum para ver um servidor com 1000-5000 conexões abertas, e talvez 1-3 estão na verdade executando consultas. Essas conexões são originárias de dezenas a centenas de instâncias de um servidor de aplicação. Quando você tiver um aplicativo muito sharded ou horizontalmente escalado, não é só fácil de entrar neste problema, é muito difícil ou impossível evitá-lo.

E com 5000 conexões abertas, você tem 5000 tópicos no servidor. Isso aumenta a sobrecarga de agendamento de segmento e, potencialmente, o uso de memória também. Eu sinto que estou esquecendo algumas razões importam, por favor preencha o que está faltando nos comentários!

Pode haver mais de uma solução para este problema, mas o que realmente importa é implementar um conjunto de threads, que foi originalmente codificado para o MySQL 6.0, que está disponível agora em MariaDB .

Infelizmente não é uma solução completa, pois pode causar indesejáveis lock-out de espera, a aplicação específica tem um gargalo de escalabilidade em servidores multicore . Mark Callaghan fez uma investigação muito mais afundo sobre o pool de threads.


Existem varias coisas em MySQL, que não fazem bem, pois muitas a ferramenta é utilizada de forma errada, NotABug, podemos ter como exemplo a sort-merge ou paralelismo intra-consulta.
Seria muito bom ter essas coisas se você estivesse executando um armazém de dados em MySQL ( note que a maioria dos bancos de dados que possuem esses planos de consulta habitualmente utilizam junções de laço aninhado).

Não apenas um data warehouse MySQL DBMS , um general-purpose ou um servidor de dados tipo OLTP que funcionam em um hardware acessível e ótimo para uso na Web, é tão bom que na verdade pode ser utilizado para uma tonelada de outras coisas, como por exemplo armazenamento de dados. Mas não é uma Netezza ou Paraccel se fosse não seria um banco de dados OLTP.

A replicação do MySQL é uma das características fundamentais e a single threaded que conta com o log binário, que são duas limitações, e possuem subqueries que fazem parte de um núcleo fundamental de SQL, por isso listamos algumas limitações como grandes.

E porque o MySQL é um banco de dados multi-threaded para o uso da Web que tende a ser usado em ambientes sharded com toneladas de servidores de aplicação, o que cria uma situação com milhares de conexões ao banco de dados, e porque não lidar com isso muito bem, listamos seu projeto de um thread por conexão como uma limitação séria.