# I have a simple table
create table t1 (c1 int, c2 int);
# I want to do the following sorting
select * from t1 order by c2 desc, c1 desc;
select * from t1 order by c2 asc, c1 desc;
# add indexs
CREATE INDEX index_1 ON t1 (c1 DESC, c2 DESC);
CREATE INDEX index_2 ON t1 (c1 ASC, c2 DESC);
# then explain
explain select * from t1 order by c2 desc, c1 desc;
# the result is
mysql> explain select * from t1 order by c2 desc, c1 asc;
+----+-------------+-------+-------+---------------+---------------+---------+------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------------+---------+------+------+-----------------------------+
| 1 | SIMPLE | t1 | index | NULL | index_2 | 10 | NULL | 6 | Using index; Using filesort |
+----+-------------+-------+-------+---------------+---------------+---------+------+------+-----------------------------+
1 row in set (0.00 sec)
minhas perguntas são
- Os índices são otimizados o desempenho?
- Por que usar o índice; Usando filesort show ao mesmo tempo?
Você precisa de um índice
(c2, c1)
para esta consulta, não um índice para(c1, c2)
.Claro que seria melhor se houvesse um índice
(c2 DESC, c1 DESC)
para a primeira consulta e um índice(c2 DESC, c1 ASC)
para a segunda consulta. Infelizmente o MySQL não pode criar tais índices. OsASC
eDESC
são ignorados.O que significa seus dois índices:
são realmente idênticos e iguais como se você os tivesse definido como:
Se o desempenho - com o
(c2, c1)
índice - não for bom o suficiente, você tem algumas opções:.
Então você pode indexar
(c2_neg, c1)
e(c2_neg, c1_neg)
VIRTUAL PERSISENT
colunas e índices apropriados para uma solução semelhante (um pouco melhor, pois você não precisará adicionar gatilhos, as colunas serão preenchidas automaticamente).