The `property` column on `ImageTagProperties` is declared as `TEXT`, which causes two problems.

**Problem A -- no histogram possible.** MariaDB/MySQL cannot collect statistics on TEXT/BLOB columns. Without a histogram the optimizer has to assume all property values are equally common. In practice the distribution is very skewed:

| value               | rows    | % of table |
|---------------------|---------|------------|
| autodetectedFace    | 580 123 |     69 %   |
| autodetectedPerson  | 116 638 |     14 %   |
| tagRegion           |  53 505 |      6 %   |
| faceToTrain         |  52 670 |      6 %   |
| faceTagExtendedData |  32 960 |      4 %   |
| ignoredFace         |   5 751 |    0.7 %   |

So the optimizer never trusts a range scan on `property = 'autodetectedFace'` and falls back to a full table scan every time.

**Problem B -- existing index has the wrong column order.** The current index is `(tagid, property)`. Queries that filter on `property` first -- which is the normal case for the People panel -- cannot use it. With `property` as TEXT the index also requires a prefix `property(50)`, making cardinality estimates even less accurate.

The relevant query from the slow-query log:

/---code sql
SELECT tagid, COUNT(*) FROM ImageTagProperties
  LEFT JOIN Images ON Images.id = ImageTagProperties.imageid
  WHERE ImageTagProperties.property = 'autodetectedFace'
    AND Images.status = 1
  GROUP BY tagid;
\---

`EXPLAIN`: `type = ALL, 841 k rows, Using temporary; Using filesort`. Fired about 146 times/day for `autodetectedFace` alone (381 s total), plus more for each other value.

**Fix -- three steps:**

/---code sql
-- 1. Change column type so histograms and full-length index keys become possible.
--    All existing values fit easily in VARCHAR(255); this is transparent to the app.
ALTER TABLE ImageTagProperties MODIFY property VARCHAR(255);

-- 2. Add a covering index with property as the leading column.
--    tagid second means GROUP BY tagid needs no filesort.
--    imageid third makes it a covering index (no heap read on ITP at all).
CREATE INDEX idx_itp_property_tagid_img
    ON ImageTagProperties (property, tagid, imageid);

-- 3. Now that property is VARCHAR, build a histogram.
ANALYZE TABLE ImageTagProperties PERSISTENT FOR COLUMNS (property) INDEXES ALL;
\---

After this the optimizer can see that `'autodetectedFace'` is 69 % of the table and weigh a range scan accordingly, and it will definitely choose the index for `'ignoredFace'` (0.7 %) and `'tagRegion'` (6 %).

**Bonus: two redundant indexes can be removed.**

The table currently has 5 indexes. Two are strict prefixes of others and serve no purpose:

/---code sql
-- (imageid) is a prefix of (imageid, tagid) -- redundant
DROP INDEX imagetagproperties_imageid_index ON ImageTagProperties;

-- (tagid) is a prefix of (tagid, property) -- redundant
DROP INDEX imagetagproperties_tagid_index ON ImageTagProperties;
\---

Removing them reduces write amplification during face detection runs, where DigiKam inserts into this table at high volume.