Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
A partilha de ligações permite a utilização de partilhas de ligações pré-configuradas nos dialetos de base de dados PostgreSQL e Snowflake.
Se o seu dialeto o suportar, a partilha de ligações à base de dados permite ao Looker usar conjuntos de ligações através do controlador JDBC. A partilha de ligações à base de dados permite um desempenho mais rápido das consultas. Uma nova consulta não precisa de criar uma nova ligação à base de dados, mas pode usar uma ligação existente da partilha de ligações. A capacidade de agrupamento de ligações garante que uma ligação é limpa após a execução de uma consulta e está disponível para reutilização após o fim da execução da consulta.
A opção Database Connection Pooling está ativada na ligação do Looker.
Configurou pools de ligações na sua base de dados.
Seguem-se alguns aspetos a considerar quando usa conjuntos de ligações:
Vários utilizadores partilham um conjunto de ligações se os respetivos valores de atributos de utilizador forem idênticos. Os utilizadores que têm valores únicos ou diferentes no respetivo conjunto de atributos do utilizador usam conjuntos de ligações únicos quando se ligam à base de dados.
O número máximo de ligações que podem ser feitas a conjuntos de ligações em todos os nós da base de dados é limitado pelo valor no campo Máximo de ligações por nó na página Ligação da base de dados.
Se o número de consultas simultâneas emitidas para um conjunto de ligações exceder o número máximo de ligações, as consultas são colocadas em fila no Looker até que as consultas anteriores sejam executadas.
As strings de ligação JDBC únicas criam pools de ligações únicos. Por exemplo, os nomes de utilizadores exclusivos da base de dados ou os nomes de grupos da base de dados que ditam o controlo de acesso baseado em funções à base de dados criam cadeias de caracteres de ligação JDBC exclusivas, que, por sua vez, criam conjuntos de ligações exclusivos. Por exemplo, um grupo de finanças numa empresa pode ter uma função de base de dados que lhe concede acesso a todas as tabelas na base de dados, mas a equipa de vendas e marketing pode ter uma função de base de dados que lhe concede acesso apenas a um subconjunto das tabelas da base de dados. Neste caso, cada grupo teria uma string de ligação JDBC única e um conjunto de ligações único. Um terceiro grupo pode ser um conjunto de clientes de estatísticas incorporadas que têm os seus próprios direitos de acesso à base de dados. Os clientes de estatísticas incorporadas também teriam uma string JDBC única e um conjunto de ligações único, pelo que também teriam um conjunto único de ligações que não estão a ser usadas pelos grupos de finanças ou vendas e marketing.
A cláusula WHERE numa consulta SQL não causa novos conjuntos de ligações. A cláusula WHERE não tem impacto na string de ligação JDBC, pelo que não é criado um novo conjunto de ligações. Por exemplo, os filtros de acesso exclusivos modificam a cláusula WHERE SQL numa consulta e não a string de ligação JDBC, pelo que os filtros de acesso exclusivos não criam novas pools de ligações.
Quando são criados vários conjuntos de ligações, o número máximo de ligações é fragmentado em vários conjuntos, com cada conjunto a conter um subconjunto de ligações disponíveis. Isto ocorre porque o número total de associações não pode exceder o valor máximo de associações.
Suporte de dialetos para o agrupamento de ligações à base de dados
A capacidade de usar o agrupamento de ligações à base de dados depende do dialeto da base de dados que a sua ligação do Looker está a usar. No lançamento mais recente do Looker, os seguintes dialetos suportam o agrupamento de ligações à base de dados:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-20 UTC."],[],[],null,["# Database connection pooling\n\nConnection pooling enables the use of preconfigured connection pools on [PostgreSQL](/looker/docs/db-config-postgresql) and [Snowflake](/looker/docs/db-config-snowflake) database dialects.\n\n[If your dialect supports it](#dialect_support_for_database_connection_pooling), database connection pooling enables Looker to use pools of connections through the JDBC driver. Database connection pooling enables faster query performance; a new query does not need to create a new database connection but can instead use an existing connection from the connection pool. The connection pooling capability ensures that a connection is cleaned up after a query execution and is available for reuse after the query execution ends.\n\nYou can enable connection pooling using the [**Database Connection Pooling**](/looker/docs/admin-panel-general-labs#database_connection_pooling) option when you [create](/looker/docs/connecting-to-your-db) or [edit](/looker/docs/admin-panel-database-connections#editing_connections) a database connection in Looker.\n| **Note:** Database connection pooling was previously a Looker [Labs](/looker/docs/admin-panel-general-labs) feature. When **Database Connection Pooling** moved out of Labs, Looker automatically applied the **Database Connection Pooling** Labs setting to the **Database Connection Pooling** connection setting for any database connections on your instance that support connection pooling.\n\nLooker will use connection pooling on your connection if all of the following are true:\n\n- You are using one of the [dialects that support database connection pooling](#dialect_support_for_database_connection_pooling).\n- The **Database Connection Pooling** option is enabled on the Looker connection.\n- You have configured connection pools on your database.\n\nHere are some things to consider when you're using connection pools:\n\n- Multiple users share a connection pool if their user attribute values are identical. Users who have unique or differing values in their set of user attributes will use unique connection pools when connecting to the database.\n\n- The maximum number of connections that can be made to connection pools across all database nodes is limited by the value in the [**Max connections per node**](/looker/docs/connecting-to-your-db#max_connections) field in the database's **Connection** page.\n\n- If the number of concurrent queries being issued to a connection pool exceeds the maximum number of connections, queries are queued in Looker until prior queries are executed.\n\n- Unique JDBC connection strings create unique connection pools. For example, unique database usernames or database group names that dictate role-based access control to the database will create unique JDBC connection strings, which then create unique connection pools. For example, a finance group in a company may have a database role that grants them access to all tables in the database, but the sales and marketing team may have a database role that grants them access to only a subset of the database tables. In this case, each group would have a unique JDBC connection string and a unique connection pool. A third group might be a set of [embedded analytics](/looker/docs/single-sign-on-embedding) customers who have their own access rights to the database. The embedded analytics customers would also have a unique JDBC string and a unique connection pool, so they would also have a unique set of connections that are not in use by the finance or sales and marketing groups.\n\n- The `WHERE` clause in a SQL query does not cause new connection pools. The `WHERE` clause has no impact on the JDBC connection string, so a new connection pool is not created. For example, unique [access filters](/looker/docs/reference/param-explore-access-filter) modify the SQL `WHERE` clause in a query, not the JDBC connection string, so unique access filters won't create new connection pools.\n\n- When multiple connection pools are created, the maximum number of connections is fragmented into multiple pools, with each pool containing a subset of available connections. This occurs because the total number of connections cannot exceed the maximum connections value.\n\nDialect support for database connection pooling\n-----------------------------------------------\n\nThe ability to use database connection pooling depends on the database dialect your Looker connection is using. In the latest release of Looker, the following dialects support database connection pooling:"]]
