MySQL multiple index columns have a full cardinality? I have noticed indexes like:
+-------------------+------------+-----------------------+--------------+----------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table             | Non_unique | Key_name              | Seq_in_index | Column_name    | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------------------+------------+-----------------------+--------------+----------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| archive_city_item |          1 | ARCHIVE_CITY_ITEM_IDX |            1 | city_id        | A         |        7851 |     NULL | NULL   | YES  | BTREE      |         |               |
| archive_city_item |          1 | ARCHIVE_CITY_ITEM_IDX |            2 | item_id        | A         |      266502 |     NULL | NULL   | YES  | BTREE      |         |               |
| archive_city_item |          1 | ARCHIVE_CITY_ITEM_IDX |            3 | vote_date      | A         |     4530535 |     NULL | NULL   | YES  | BTREE      |         |               |
| archive_city_item |          1 | ARCHIVE_CITY_ITEM_IDX |            4 | ip_address_str | A         |     4530535 |     NULL | NULL   | YES  | BTREE      |         |               |
| archive_city_item |          1 | ARCHIVE_CITY_ITEM_IDX |            5 | month          | A         |     4530535 |     NULL | NULL   | YES  | BTREE      |         |               |
| archive_city_item |          1 | ARCHIVE_CITY_ITEM_IDX |            6 | year           | A         |     4530535 |     NULL | NULL   | YES  | BTREE      |         |               |

I guess since column 3-6 have a full cardinality this index is not goodly constructed, that it shall be deleted and the new indexes should be built (queries should be analyzed to see if it's (city_id, item_id) or maybe (city_id, item_id, votedate) or some other combination starting with (city_id, item_id...) ?
Correct? Or I'm getting this wrong?
As @Johnakahot2use mentioned, indexes on fields with really low uniqueness (low cardinality) is not a bad thing. It's just fields with high uniqueness are generally more efficient when indexed and stored in a B-Tree.
That being said, you don't normally write queries around the cardinality of the fields in your table (usually that's not even a luxury), you write queries for the data that's needed to complete the objective at hand, and you try to index (and design your schema) in a way that offers best performance to those use cases.
In other words, if one of your use cases is to get all ip_address_str in a specific month and year, then it makes sense to create an index on month and year (in the order of which ever field is more unique). If your use case will always require filtering on item_id then adding that to the index would certainly help it to be more performant but it's not a requirement for the index to be of help either.
In conclusion, create indexes and design the schema appropriate for your common use cases, not the queries around your data's cardinality (unless it so happens that works for your use cases).