Início / dba / Perguntas / 345128
Accepted
TheMemeMachine
Asked: 2025-02-06 20:13:45 +0800 CST

O planejador de execução de consulta no mysql v8 reconhece que x=1 e x in(1) são iguais?

  • 772

Tenho as seguintes 2 dúvidas:

SELECT * FROM mytable
WHERE id=1;

e

SELECT * FROM mytable
WHERE id IN(1);

Supondo que mytableseja muito grande, estou interessado na diferença de desempenho para os 2 em tabelas muito grandes. Sei que IN() deve ser geralmente mais lento nos casos em que forneço uma lista de valores para ele, mas como IN(1) é equivalente ao caso =1 quando um item existe, o planejador/otimizador de consultas reconhece esse caso e lida com a sobrecarga de desempenho que geralmente existe? Existe alguma maneira de verificar isso além de cronometrar os resultados da consulta?

mysql

2 respostas

  1. Best Answer

    O planejador/otimizador de consultas reconhece esse caso e elimina a sobrecarga de desempenho que geralmente existe?

    Sim, MySQLconverte

    id IN (1,2,3..)

    em

    id = 1 OR id = 2 OR id = 3 OR ..

    Então, id IN (1)é igual aid = 1

    Existe alguma maneira de verificar isso além de cronometrar os resultados da consulta?

    Sim, veja o plano de execução, use

    EXPLAIN FORMAT=JSON SELECT * FROM my_table WHERE x = 1;
EXPLAIN FORMAT=JSON SELECT * FROM my_table WHERE x IN (1);

    ou

    EXPLAIN ANALYZE SELECT * FROM my_table WHERE x = 1;
EXPLAIN ANALYZE SELECT * FROM my_table WHERE x IN (1);

    Se ambos produzem o mesmo plano de execução, isso confirma que o MySQL os está tratando de forma idêntica.

    Fiz um teste em um dos meus bancos de dados de produção.

    Versão:8.0.41-0ubuntu0.22.04.1

    CREATE TABLE `technicians_registration_log` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `request` text NOT NULL,
  `response` text NOT NULL,
  `uniqueid` varchar(100) NOT NULL,
  `caller_code` varchar(100) NOT NULL,
  `start_time` datetime NOT NULL,
  `communication_channel` varchar(50) NOT NULL,
  `full_url` text NOT NULL,
  `created_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `created_at` (`created_at`),
  KEY `uniqueid` (`uniqueid`),
  KEY `caller_code` (`caller_code`),
  KEY `start_time` (`start_time`),
  KEY `communication_channel` (`communication_channel`)
) ENGINE=InnoDB AUTO_INCREMENT=153647062;

    Executei as seguintes consultas e elas produziram o mesmo plano de execução idêntico

    explain format=json select * from technicians_registration_log where caller_code = '1000073336';
explain format=json select * from technicians_registration_log where caller_code in ('1000073336');

| {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "431.94"
    },
    "table": {
      "table_name": "technicians_registration_log",
      "access_type": "ref",
      "possible_keys": [
        "caller_code"
      ],
      "key": "caller_code",
      "used_key_parts": [
        "caller_code"
      ],
      "key_length": "102",
      "ref": [
        "const"
      ],
      "rows_examined_per_scan": 413,
      "rows_produced_per_join": 413,
      "filtered": "100.00",
      "cost_info": {
        "read_cost": "390.64",
        "eval_cost": "41.30",
        "prefix_cost": "431.94",
        "data_read_per_join": "122K"
      },
      "used_columns": [
        "id",
        "request",
        "response",
        "uniqueid",
        "caller_code",
        "start_time",
        "communication_channel",
        "full_url",
        "created_at"
      ]
    }
  }
} |

    Agora, se eu adicionar outro valor na incláusula o plano de execução muda

    | {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "479.59"
    },
    "table": {
      "table_name": "technicians_registration_log",
      "access_type": "range",
      "possible_keys": [
        "caller_code"
      ],
      "key": "caller_code",
      "used_key_parts": [
        "caller_code"
      ],
      "key_length": "102",
      "rows_examined_per_scan": 415,
      "rows_produced_per_join": 415,
      "filtered": "100.00",
      "index_condition": "(`myDatabase`.`technicians_registration_log`.`caller_code` in ('1000073336','1000073256'))",
      "cost_info": {
        "read_cost": "438.09",
        "eval_cost": "41.50",
        "prefix_cost": "479.59",
        "data_read_per_join": "123K"
      },
      "used_columns": [
        "id",
        "request",
        "response",
        "uniqueid",
        "caller_code",
        "start_time",
        "communication_channel",
        "full_url",
        "created_at"
      ]
    }
  }
} |
    • 2

  2. Talvez as questões mais críticas sejam:

    • Faça id=1e id IN (1)otimize igualmente bem? Sim
    • Fazer id = 1 OR id = 2e id IN (1,2)otimizar igualmente bem? Sim .
    • Faça id IN (1)e id IN (1,2)otimize igualmente bem? NÃO

    Levando a questão adiante:

    • id BETWEEN 123 AND 456é idêntico a id >= 123 AND id <= 456 Ambos são testes de "alcance".
    • foo LIKE 'prefix%'é um teste de alcance, mas foo LIKE '%suffix'precisa de uma 'varredura de tabela'.
    • id IS NULLfunciona como =, Mas IS NOT NULLnão; ele precisa de uma varredura de tabela.

    A ordem de otimizabilidade:

    1. =e IS NULLeIN (<one item>)
    2. IN(<more than one item>)
    3. "Faixa"
    4. "varredura de mesa"

    Mais: Índice Livro de receitas

    (Essas dicas se aplicam ao MySQL 8 e à maioria das versões mais antigas, além do MariaDB.)

    Não vejo nenhum índice "composto" no seu esquema. Vamos ver se você precisa de um; mostre-nos um 'real' SELECT.

    • 2

relate perguntas