Leia esta resposta abaixo , que detalha maneiras de atenuar os problemas descritos aqui.
As mesmas desvantagens existem usando o PDO, como em qualquer outra interface de banco de dados PHP que faz conexões persistentes: se o script terminar inesperadamente no meio das operações do banco de dados, a próxima solicitação que obtiver a conexão restante continuará de onde o script morto parou. A conexão é mantida aberta no nível do gerenciador de processos (Apache para mod_php, o processo FastCGI atual, se você estiver usando FastCGI, etc), não no nível PHP, e o PHP não diz ao processo pai para deixar a conexão morrer quando o script termina de forma anormal.
Se o script inoperante bloqueou as tabelas, essas tabelas permanecerão bloqueadas até que a conexão morra ou o próximo script que obtém a conexão desbloqueie as próprias tabelas.
Se o script morto estiver no meio de uma transação, isso poderá bloquear várias tabelas até que o cronômetro de deadlock entre em ação e, mesmo assim, o cronômetro de deadlock poderá eliminar a solicitação mais recente em vez da solicitação mais antiga que está causando o problema.
Se o script morto estava no meio de uma transação, o próximo script que obtém essa conexão também obtém o estado da transação. É muito possível (dependendo do design do aplicativo) que o próximo script nunca tente confirmar a transação existente, ou confirme quando não deveria, ou reverta quando não deveria.
Esta é apenas a ponta do iceberg. Tudo isso pode ser atenuado até um certo ponto, sempre tentando limpar após uma conexão suja em cada solicitação de script, mas isso pode ser um problema, dependendo do banco de dados. A menos que você tenha identificado a criação de conexões de banco de dados como a única coisa que é um gargalo no seu script (isso significa que você tem o código feito de perfis usando xdebug e / ou xhprof ), você deve não considerar conexões persistentes como uma solução para nada.
Além disso, a maioria dos bancos de dados modernos (incluindo o PostgreSQL) tem suas próprias maneiras preferidas de executar o pool de conexões que não têm as desvantagens imediatas que as conexões persistentes simples baseadas em PHP.
Para esclarecer um ponto, usamos conexões persistentes no meu local de trabalho, mas não por opção. Estávamos encontrando um comportamento estranho de conexão, em que a conexão inicial do servidor de aplicativos com o servidor de banco de dados estava levando exatamente três segundos, quando deveria levar uma fração de uma fração de segundo. Achamos que é um bug do kernel. Desistimos de tentar solucionar o problema, porque isso aconteceu aleatoriamente e não pôde ser reproduzido sob demanda, e nossa TI terceirizada não tinha a capacidade concreta de localizá-lo.
Independentemente disso, quando as pessoas no armazém estão processando algumas centenas de peças recebidas e cada uma delas leva três segundos e meio em vez de meio segundo, tivemos que agir antes que eles nos sequestrassem e nos fizessem ajudá-los. Por isso, lançamos alguns detalhes em nossa monstruosidade ERP / CRM / CMS, criada em casa, e experimentamos todos os horrores de conexões persistentes em primeira mão. Levamos semanas para rastrear todos os pequenos problemas sutis e comportamentos bizarros que aconteciam aparentemente ao acaso. Aconteceu que aqueles erros fatais que uma vez por semana os nossos usuários retiravam diligentemente do nosso aplicativo estavam deixando tabelas bloqueadas, transações abandonadas e outros estados infelizes.
Essa triste história tem um ponto: quebrou coisas que nunca esperávamos quebrar, tudo em nome da performance. A troca não valeu a pena, e estamos aguardando ansiosamente o dia em que possamos voltar às conexões normais sem uma revolta de nossos usuários.