Drop redundant index on cart_rule_combination

[ShaiMagal]

Questions	Answers
Description?	Companion migration for PrestaShop/PrestaShop#42438. That PR removes KEY id_cart_rule_1 from cart_rule_combination in the canonical schema, because it is the leftmost prefix of PRIMARY KEY (id_cart_rule_1, id_cart_rule_2) and therefore can never be selected over the primary key. Since the schema of an existing shop is only ever moved forward by the scripts in upgrade/sql/, the core PR alone would only ever benefit fresh installations. This adds the matching statement so upgraded shops get it too.
Type?	improvement
BC breaks?	no
Deprecations?	no
Fixed ticket?	-
Sponsor company	OpenServis.cz
How to test?	On a shop still carrying the index, SHOW INDEX FROM ps_cart_rule_combination lists PRIMARY, id_cart_rule_1 and id_cart_rule_2. Run the update to 9.3.0 and check that only PRIMARY and id_cart_rule_2 remain. Run it a second time (or on a shop that never had the index) and check that the update still finishes without a warning: the statement then fails with error 1091, which is already in the ignore list.

Why it matters

cart_rule_combination is one of the biggest tables on shops that generate one voucher per customer, because it grows quadratically with the number of cart rules. On a production shop I looked at (PrestaShop 8.1.7, about 14 000 cart rules) it holds 69 555 681 rows and takes 4 289 MB, of which 2 159 MB is secondary indexes.

Both secondary indexes cover the same two int unsigned columns and InnoDB appends the missing primary key column to each, so the two leaf structures are the same size. Dropping the redundant one frees about half of that index space, roughly 1 GB on that shop, and removes one index maintenance operation from every insert and delete on the table.

Why the statement is standalone

DROP INDEX on a missing index raises error 1091, which CoreUpgrader already lists as safely ignorable via MysqlErrorCode::CANNOT_DROP_KEY, so shops that no longer have the index are unaffected.

I deliberately did not fold it into a multi-clause ALTER TABLE: that is exactly the shape that causes #1636, where a failing DROP INDEX discards the other clauses of the same statement. If a drop_index_if_exists.php helper is added later (as discussed in #1636), this line is a one-word change.

File choice

I put it in a new upgrade/sql/9.3.0.sql because the core PR targets develop, which is 9.3.0. If you would rather have it in 9.2.0.sql, say the word and I will move it - though shops already running 9.2.0 would then never receive it, since the runner only applies scripts whose version is strictly greater than the shop version.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud