Eu estava verificando a seletividade de algumas colunas para um índice.
Onde está documentado esse comportamento de "ignore o que eu lhe dou"?
Isso dá 4.851.908, 4.841.060 e 1.000.052
SELECT
COUNT(*),
COUNT(DISTINCT Col1), COUNT(DISTINCT Col2)
FROM Sometable;
Isso dá 4.843.634 pares únicos de acordo com a extensão do MySQL
SELECT COUNT(DISTINCT Col1, Col2) FROM Sometable
O seguinte está errado: o COUNT(DISTINCT colx) individual fornece a contagem de pares exclusivos de 4.843.634, independentemente de qualquer coluna de preenchimento ou ordem de expressão.
Eu esperava COUNT(DISTINCT Col1) = 4,841,060
, e COUNT(DISTINCT Col1) = 1,000,052
.
SELECT COUNT(DISTINCT Col1), COUNT(DISTINCT Col2) FROM Sometable
SELECT COUNT(DISTINCT Col2), COUNT(DISTINCT Col1) FROM Sometable
SELECT COUNT(DISTINCT Col1), 1 AS Filler, COUNT(DISTINCT Col2) FROM Sometable
Mas isso fornece valores corretos novamente com outro agregado (como COUNT(*)
acima)
SELECT COUNT(DISTINCT Col1), MAX(col1) AS Filler, COUNT(DISTINCT Col2) FROM Sometable
Dúvidas, caso não tenha ficado claro:
- Por que
COUNT(DISTINCT Col1), COUNT(DISTINCT Col2)
se comporta comoCOUNT(DISTINCT Col1, Col2)
- Por que outro agregado é necessário para fazê-lo funcionar?
Parece que você está atingindo este bug de regressão:
Uma das soluções sugeridas é usar sql_buffer_result
Sem ver seus resultados exatos, não tenho certeza se entendi qual é o problema. Eu tentei isso em uma tabela aleatória na minha máquina e obtive os resultados que eu esperava.
Você diz
mas isso não faz o menor sentido. As duas primeiras consultas devem retornar duas colunas, a última deve retornar 3.
Você pode fornecer seus resultados reais alinhados com o que você esperava ver e talvez possamos descobrir se há um problema real ou se você está simplesmente entendendo mal alguma coisa.
Para referência, executei isso no Percona Server 5.5.16
EDIT: Eu também tentei isso em um conjunto de dados diferente com ~ 5MM linhas e obtive os mesmos resultados... tudo verificado. Isso foi no Percona Server 5.1.43