-- ---------------------------------------------------------------------------
-- O indice de `agendas.id_pai`: achar a familia de um horario sem varrer a
-- agenda inteira (D220).
--
--   mysql franquia_producao < scripts/migracao-agendas-indice-id-pai.sql
--
-- Roda no laco do passo 0 de `docs/procedimento-de-corte.md`, em PRODUCAO, e no
-- laco da copia do desenvolvimento de `docs/ensaio-geral-do-corte.md`, contra a
-- `franquiabv_dev`. A COPIA LOCAL A RECEBEU EM 09/10/2026, pela resposta 62 do
-- dono (a opcao (b): "Criar ja na copia local, nos dois bancos, como no D308"):
-- ali ela diz "indice ja existe"; no PostgreSQL da copia, o indice herdado foi
-- criado por `CREATE INDEX CONCURRENTLY` (D220). A base do teste do BVIP fica
-- sem ele ate a proxima copia exportada daqui: a opcao (c), que a incluia, nao
-- foi escolhida.
--
-- O QUE ELA RESOLVE. Todo Desmarcar -- a tela antiga, o aplicativo, a API, o
-- remarcar da tela antiga e as duas leituras do Desmarcar da tela nova -- acha a
-- familia do horario por `AgendaRepository::selecionarHorariosFilhos`, com
-- `status = ? AND (id = ? OR id_pai = ?)`. Sem indice em `id_pai`, o `OR` nao
-- usa nem a `PRIMARY`: a consulta le os 4 milhoes de linhas da agenda para
-- devolver de 1 a 3. Medido na copia em 08/10/2026: 2,8 s no MySQL com o pool de
-- 128 MB e 2,0 a 2,3 s com a tabela inteira na memoria (e CPU, nao disco); com o
-- indice, 0,2 ms, pelo `index_merge` da `PRIMARY` com este.
--
-- DECIDIDO PELO DONO EM 08/10/2026 (pergunta 50 da pagina do lote, a opcao (a)):
-- o indice entra na janela, por esta migracao antes do passo 1, e o mesmo `KEY`
-- no `mysql.sql`. O PostgreSQL o herda pelo gerador (`agendas_IDX_AGENDAS_id_pai`,
-- com o inquilino na frente), SEM linha a mao em `scripts/gerar-ddl-postgres.php`:
-- ela sairia com o mesmo nome do herdado, e o `psql -v ON_ERROR_STOP=1` pararia o
-- passo 4 em "already exists", como quase aconteceu com a `sessoes` (D323).
--
-- IDEMPOTENTE: so cria se nao houver indice com este nome em `agendas`.
--
-- ---------------------------------------------------------------------------
-- ESTA MIGRACAO PRECISA ESTAR EM PRODUCAO ANTES DO PASSO 1 -- o passo 0 (D323).
--
-- O passo 1 refaz o `mysql.sql` a partir da estrutura de producao. Sem o indice
-- la, o `KEY` some do `mysql.sql`, o gerador deixa de emiti-lo, e o PostgreSQL
-- nasce sem ele: nada quebra, e cada Desmarcar volta a varrer a agenda. Por isso
-- o portao do passo 0 exige as duas metades -- esta migracao no laco e o `KEY`.
--
-- NAO COPIA A TABELA. Indice secundario sem chave estrangeira o InnoDB cria
-- INPLACE, com LOCK=NONE: as escritas na agenda seguem durante a criacao. Se o
-- servidor recusar o INPLACE, o ALTER falha e nao muda nada -- melhor que copiar
-- a tabela calado no meio do movimento. Medido em banco descartavel: 6 s numa
-- copia so da agenda (4 milhoes de linhas, 47,6 MB de indice); na tabela inteira,
-- o D189 mediu de 11 a 20 s para um indice parecido.
-- ---------------------------------------------------------------------------

SET @existe = (
    SELECT COUNT(*) FROM information_schema.statistics
     WHERE table_schema = DATABASE()
       AND table_name = 'agendas'
       AND index_name = 'IDX_AGENDAS_id_pai'
);

SET @sql = IF(@existe = 0,
    'ALTER TABLE agendas
       ADD INDEX IDX_AGENDAS_id_pai (id_pai),
       ALGORITHM=INPLACE, LOCK=NONE',
    'SELECT ''indice ja existe, nada a fazer'' AS aviso'
);

PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;

-- Conferencia. O esperado e uma linha: o indice, nao unico, so com `id_pai`.
SELECT index_name                                         AS indice,
       GROUP_CONCAT(column_name ORDER BY seq_in_index)    AS colunas,
       MAX(non_unique)                                    AS nao_unico
  FROM information_schema.statistics
 WHERE table_schema = DATABASE()
   AND table_name = 'agendas'
   AND index_name = 'IDX_AGENDAS_id_pai'
 GROUP BY index_name;