O mysql ou mariadb tem o conceito de "colunas incluídas" do SQL Server para índices?

Observando a documentação do MySQL, o glossário indica isso sobre Covering Indexes :

Um índice que inclui todas as colunas recuperadas por uma consulta. Em vez de usar os valores de índice como ponteiros para localizar as linhas completas da tabela, a consulta retorna valores da estrutura de índice, economizando E/S de disco. O InnoDB pode aplicar essa técnica de otimização a mais índices do que o MyISAM, porque os índices secundários do InnoDB também incluem as colunas de chave primária. O InnoDB não pode aplicar esta técnica para consultas em tabelas modificadas por uma transação, até que a transação termine.

Qualquer índice de coluna ou índice composto pode atuar como um índice de cobertura, dada a consulta correta. Projete seus índices e consultas para aproveitar essa técnica de otimização sempre que possível.

A implicação aqui é que não há equivalente direto de uma INCLUDEinstrução no MySQL, no entanto, se o índice fornecer cobertura das colunas envolvidas em um índice, ele pode, obviamente, ainda ser considerado como cobertura, como um índice com colunas incluídas no SQL Server seria.

MariaDB tem o seguinte em sua documentação para cobrir índices :

Um índice "Cobertura" é um índice que contém todas as colunas no SELECT. É especial porque o SELECT pode ser concluído olhando apenas para o INDEX BTree. (Como a PRIMARY KEY do InnoDB é agrupada com os dados, "cobrir" não traz nenhum benefício ao considerar a PRIMARY KEY.)

Mini livro de receitas:

1. Reúna a lista de colunas de acordo com o "Algoritmo", acima.
2. Adicione ao final da lista o restante das colunas vistas no SELECT, em qualquer ordem.

Exemplos:

SELECT x FROM t WHERE y = 5; ⇒ INDEX(y,x) -- The algorithm said just INDEX(y)  
SELECT x,z FROM t WHERE y = 5 AND q = 7; ⇒ INDEX(y,q,x,z) -- y and q in either order (Algorithm), then x and z in either order (covering).  
SELECT x FROM t WHERE y > 5 AND q > 7; ⇒ INDEX(y,q,x) -- y or q first (that's as far as the Algorithm goes), then the other two fields afterwards.   

A aceleração que você obtém pode ser pequena, ou pode ser espetacular; é difícil prever.

Mas...

• Não é aconselhável construir um índice com muitas colunas. Vamos cortá-lo em 5 (Regra de ouro).
• Índices de prefixo não podem 'cobrir', então não os use em nenhum lugar em um índice de 'cobertura'.
• Existem limites (3 KB?) de quão 'amplo' um índice pode ser, então a "cobertura" pode não ser possível.

O MySQL não suporta colunas incluídas.

No entanto, se você usar o mecanismo de armazenamento InnoDB (que é o padrão), todas as colunas serão incluídas fisicamente na chave primária. Em outras palavras, a chave primária é a tabela. Se você definir a chave primária como PRIMARY KEY (id)as linhas serão ordenadas fisicamente por id; mas para todas as consultas que usam a chave primária, a chave primária será um índice de cobertura.

A consulta a seguir usa a chave primária como um índice coberto:

SELECT * FROM tab WHERE pk = 10;

Como Akina apontou em um comentário, os índices secundários do InnoDB incluem uma referência à chave primária. Então se você indexar os campos de email, no índice você terá todos os emails em ordem, e para cada um você terá o id correspondente. Assim, para cada índice secundário, a(s) coluna(s) de chave primária são incluídas(s) coluna(s).

A consulta a seguir usa um índice secundário como índice de cobertura:

SELECT indexed_column, pk FROM tab WHERE indexed_column=100;

Como curiosidade, também posso dizer que o mecanismo de armazenamento TokuDB suporta índices de cluster , que é apenas outro nome para colunas incluídas. Infelizmente, o TokuDB não é mais mantido por seu fornecedor, Percona.