-- ---------------------------------------------------------------------------
-- O indice da grade da agenda ampliado: `FK_AGENDAS_colaborador` em `agendas (colaborador)`
-- trocado, COM O MESMO NOME, por `agendas (colaborador, data)` (o D189).
--
--   mysql franquia_producao < scripts/migracao-agendas-indice-colaborador-data.sql
--
-- Roda no laco do passo 0 de `docs/procedimento-de-corte.md`, em PRODUCAO (o passo 4 da
-- etapa 1, `docs/procedimento-de-corte-etapa-1.md`), e no laco da copia do
-- desenvolvimento de `docs/ensaio-geral-do-corte.md`, contra a `franquiabv_dev`. AS DUAS
-- COPIAS LOCAIS JA O TEM desde 02/10/2026 (a F4.1 do Profissional Parceiro, com a
-- autorizacao do dono, `docs/f3-relatorios.md`; no PostgreSQL,
-- `agendas_fk_agendas_colaborador (inquilino_id, colaborador, data)`, que o gerador emite):
-- ali ela diz "indice ja ampliado" e nao muda nada.
--
-- DECIDIDO PELO DONO: a resposta 126 (a), "Pelo passo 0, como o do Desmarcar (a sua 50)", e a
-- 196 (b), "O indice entra ja na etapa 1: como mais uma migracao do passo 0"; a 83 (a) para as
-- copias. A grade de um dia (`AgendaRepository::selecionarPorColaboradorData`) e a listagem por
-- unidade (`selecionarPorUnidadeData`) leem, com o indice de uma coluna, o HISTORICO INTEIRO de
-- cada colaborador para achar um dia: 241.218 linhas para devolver 189 (o D189, medido em
-- 21/09/2026). Com o de duas colunas NO LUGAR do de uma, 17,5 s viraram 0,72 ms na grade e 21,4 s
-- viraram 95,7 ms na listagem por unidade, com o buffer pool de fabrica. O MESMO NOME, e nao o
-- `IX_AGENDAS_COLABORADOR_DATA` que o item 2 da etapa 1 dizia: e o nome que as duas copias ja
-- tem, e o que o gerador do PostgreSQL amplia (`scripts/gerar-ddl-postgres.php`,
-- `$indicesAmpliados`) -- o molde da `migracao-vendas-indice-cliente-status-data.sql` (o D308).
-- O mesmo `KEY` no `mysql.sql`.
--
-- NAO APAGA LINHA, mas tambem nao so acrescenta: troca um indice por um maior com o mesmo
-- nome. `colaborador` e PREFIXO do novo, entao a chave estrangeira `FK_AGENDAS_colaborador` (para
-- `usuarios`) continua servida, e tudo que o indice de uma coluna servia, o novo serve. O
-- `DROP` e o `ADD` vao NUM COMANDO SO: em nenhum instante a chave estrangeira fica sem
-- indice (separados, o MySQL recusa o `DROP` -- "needed in a foreign key constraint"). O
-- AMPLIAR, e nao o acrescentar ao lado: com os dois, o otimizador continua escolhendo o de uma
-- coluna na listagem por unidade (30,5 s, o D189).
--
-- NAO COPIA A TABELA. Indice secundario o InnoDB troca INPLACE, com LOCK=NONE: as escritas
-- na agenda seguem durante a troca. Se o servidor recusar o INPLACE, o ALTER falha e nao
-- muda nada -- melhor que copiar a tabela calado. Medido: criar o de duas colunas leva de 11 a
-- 20 s nos 4 milhoes de linhas (o D189), e a troca inteira 25 s na copia (02/10/2026).
--
-- IDEMPOTENTE: com o indice ja nas duas colunas, nao faz nada; com o de uma coluna, troca;
-- sem indice nenhum com esse nome, cria. Qualquer outra forma (o nome com outras colunas)
-- PARA com erro, sem mudar nada: e uma producao que nao e a que esta migracao conhece.
--
-- ENSAIADA em 07/11/2026 (a correcao da fatia 114), num banco descartavel com a `agendas` da
-- copia (4.000.085 linhas) na forma da producao -- o indice de uma coluna e a chave
-- estrangeira para uma `usuarios` so com os ids -- e o buffer pool de fabrica (128 MB): o
-- `DROP INDEX` sozinho recusado (1553, "needed in a foreign key constraint"); a troca em 3,6 s
-- (a tabela recem-copiada, na memoria), a chave estrangeira de pe e as linhas iguais; a
-- segunda vez "indice ja ampliado" em 0,05 s; e com o indice em `(colaborador, status)` a
-- parada com saida 1 (o `|| break` do laco parou nela) e o indice intocado. Os tres ramos
-- tambem rodam a cada suite, numa tabela de ensaio
-- (`EsquemaQueSoAcrescentaTest::testAMigracaoDaGradeTrocaOIndiceDeUmaColunaEParaNaFormaQueNaoConhece`).
--
-- ---------------------------------------------------------------------------
-- 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` volta a uma coluna no `mysql.sql`, e a agenda da producao segue lendo o historico
-- (o gerador do PostgreSQL ainda amplia pelo `$indicesAmpliados`). Por isso o portao do
-- passo 0 exige as duas metades -- esta migracao no laco e o `KEY` no `mysql.sql`.
-- ---------------------------------------------------------------------------

SET @colunas = (
    SELECT GROUP_CONCAT(column_name ORDER BY seq_in_index)
      FROM information_schema.statistics
     WHERE table_schema = DATABASE()
       AND table_name = 'agendas'
       AND index_name = 'FK_AGENDAS_colaborador'
);

SET @sql = CASE
    WHEN @colunas = 'colaborador,data' THEN
        'SELECT ''indice ja ampliado, nada a fazer'' AS aviso'
    WHEN @colunas = 'colaborador' THEN
        'ALTER TABLE agendas
           DROP INDEX FK_AGENDAS_colaborador,
           ADD INDEX FK_AGENDAS_colaborador (colaborador, data),
           ALGORITHM=INPLACE, LOCK=NONE'
    WHEN @colunas IS NULL THEN
        'ALTER TABLE agendas
           ADD INDEX FK_AGENDAS_colaborador (colaborador, data),
           ALGORITHM=INPLACE, LOCK=NONE'
    ELSE
        -- A FORMA QUE NAO SE CONHECE PARA O LACO: o `SIGNAL` nao vale no `PREPARE` (o MySQL o recusa com o erro 1295), e
        -- por isso a parada e uma coluna que nao existe, com o motivo no nome -- "Unknown column ...", saida 1, nada mudou.
        'SELECT FK_AGENDAS_colaborador_com_colunas_que_esta_migracao_nao_conhece_nada_mudou FROM agendas LIMIT 1'
END;

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

-- Conferencia. O esperado e uma linha: o indice, nao unico, com as duas colunas nessa ordem.
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 = 'FK_AGENDAS_colaborador'
 GROUP BY index_name;