On the relationship between ascending and descending order, order by relation and failure of federated index

Mysql: I have previously read a saying that inconsistent sorting of items after order by will lead to the invalidation of federated indexes, such as

 order by a ASC, b DESC, c DESC  

an ascending order, b descending order, sorting inconsistency, index (arecine bjournal c) invalidation

but you can also specify sorting when building an index
if you build an index (an ASC, b DESC, c DESC)
then will the order by an ASC, b DESC, c DESC statement index still fail?

May.26,2022

description of ASC and DESC in the index definition in the mysql document

MySQL < 8.0

A key_part specification can end with ASC or DESC. These keywords are permitted for future extensions for specifying ascending or descending index value storage.
Currently, they are parsed but ignored; index values are always stored in ascending order.

MySQL > = 8.0

A key_part specification can end with ASC or DESC to specify whether index values are stored in ascending or descending order. The default is ascending if no order specifier is given. ASC and DESC are not permitted for HASH indexes. As of MySQL 8.0.12, ASC and DESC are not permitted for SPATIAL indexes.

therefore, in versions prior to 8.0, DESC is not valid, and the index (an ASC, b DESC, c DESC) equals (an ASC, b ASC, c ASC) , so the entire federated index cannot be used for sorting.

After

8.0, index sorting is allowed, leaving aside details such as sql optimization, as long as the order by order is the same as the index order, then index sorting can be used.

Previous: Docker and virtual machine cannot communicate

Next: Modified Nginx configuration in docker does not work

Menu