-- ---------------------------------------------------------------------------
-- O indice das vendas por cliente ampliado: `FK_VENDAS_cliente` em `vendas (cliente)`
-- trocado, COM O MESMO NOME, por `vendas (cliente, status, data_criacao)` (o D308).
--
--   mysql franquia_producao < scripts/migracao-vendas-indice-cliente-status-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 29/09/2026 (o D308, com a autorizacao do dono; no
-- PostgreSQL, `vendas_fk_vendas_cliente (inquilino_id, cliente, status, data_criacao)`,
-- que o gerador emite): ali ela diz "indice ja ampliado" e nao muda nada.
--
-- DECIDIDO PELO DONO EM 04/11/2026 (a resposta 294 (a) ao D697, "Aceitar a espera, com a
-- conta exata"): a Carteira de clientes (a CA1 de `docs/f3-relatorios/spec-carteira.md`,
-- `ClienteRepository::carteira*`) acha a ultima venda finalizada de cada cliente por este
-- indice, e sem ele a conta leva 6,8 a 6,9 s no MySQL, em vez de 1,7 a 1,8 s com o buffer
-- pool de fabrica. O D308 deixava a troca para a migracao final; a 294 (a) a pos no passo 0
-- da etapa 1 -- a mesma mudanca que a 196 (b) fez com o indice da grade da agenda. O mesmo
-- `KEY` no `mysql.sql`; o PostgreSQL o tem pelo gerador (`scripts/gerar-ddl-postgres.php`,
-- `$indicesAmpliados`, que desde esta migracao so repete o que o `mysql.sql` ja diz).
--
-- NAO APAGA LINHA, mas tambem nao so acrescenta: troca um indice por um maior com o mesmo
-- nome. `cliente` e PREFIXO do novo, entao a chave estrangeira `FK_VENDAS_cliente` (para
-- `clientes`) 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").
--
-- NAO COPIA A TABELA. Indice secundario o InnoDB troca INPLACE, com LOCK=NONE: as escritas
-- nas vendas seguem durante a troca. Se o servidor recusar o INPLACE, o ALTER falha e nao
-- muda nada -- melhor que copiar a tabela calado. Medido: 18 s nas 2.269.253 vendas da copia
-- (o D308, 29/09/2026); e de novo em 04/11/2026, num banco descartavel montado so com a
-- `vendas` da copia, a `clientes` (so os ids) e o indice de uma coluna (o tempo esta no
-- D308 e no roadmap desse dia).
--
-- IDEMPOTENTE: com o indice ja nas tres 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. Ensaiado
-- em 04/11/2026 no banco descartavel: a troca em 2,3 s (a tabela recem-carregada, na memoria),
-- a segunda vez "indice ja ampliado" em 0,08 s, a chave estrangeira de pe, e com o indice em
-- `(cliente, status)` a parada com saida 1 e o indice intocado.
--
-- ---------------------------------------------------------------------------
-- 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 Carteira da producao fica com a conta lenta
-- (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 = 'vendas'
       AND index_name = 'FK_VENDAS_cliente'
);

SET @sql = CASE
    WHEN @colunas = 'cliente,status,data_criacao' THEN
        'SELECT ''indice ja ampliado, nada a fazer'' AS aviso'
    WHEN @colunas = 'cliente' THEN
        'ALTER TABLE vendas
           DROP INDEX FK_VENDAS_cliente,
           ADD INDEX FK_VENDAS_cliente (cliente, status, data_criacao),
           ALGORITHM=INPLACE, LOCK=NONE'
    WHEN @colunas IS NULL THEN
        'ALTER TABLE vendas
           ADD INDEX FK_VENDAS_cliente (cliente, status, data_criacao),
           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_VENDAS_cliente_com_colunas_que_esta_migracao_nao_conhece_nada_mudou FROM vendas LIMIT 1'
END;

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

-- Conferencia. O esperado e uma linha: o indice, nao unico, com as tres 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 = 'vendas'
   AND index_name = 'FK_VENDAS_cliente'
 GROUP BY index_name;