冗余索引规则优化

[LordofAvernus]

版本信息（Version）

4.2504.0-pre2

问题描述（Describe）

冗余索引规则的审核结果的排序不固定

截图或日志（Log）

如何复现（To Reproduce）

重复执行单测能够复现

问题原因

代码中使用sort.Slice方法 对审核的结果做 根据Level大小的排序。Level相同的时候没有做出额外的判断

• Go 的文档明确指出：

sort.Slice sorts the provided slice using the provided less function. The sort is not guaranteed to be stable.

解决方案

使用sort.SliceStable来稳定相同Levle结果的相对位置

变更影响面

受影响的模块或功能

外部引用的潜在问题或风险

版本兼容性

测试建议

[iwanghc]

单测报错的实际问题原因：

AddResult会使用最新的args覆盖之前args，所以对于同一条规则来说，不存在排序问题，因为审核结果中一条规则只对应一个结果。

原因在于规则SQLE00055在计算冗余索引时返回一个map，当有多个冗余索引时，range无序的map不保证最后加入result的agr和单测中最终保留的"[v3]" arg一致，所以出现了不期望的结果。

关于SQLE00055的优化：

1. 因为多个索引出现冗余，不希望都后者覆盖前者，而是希望都保留并展示，可以构建好args后一次性AddResult中
   
2. 对于规则描述, 以下规则描述没有正确表达出在哪个字段冗余什么索引，期望修改为： 在xx字段已存在xx索引，索引xx为冗余索引
3. 注意无序map导致的单测报错问题，同步完成单测修复

[winfredLIN]

测试的SQL

CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    order_status VARCHAR(50),
    created_at DATETIME,
    INDEX idx_user_id (user_id),                        -- 单列索引
    INDEX idx_user_product (user_id, product_id),       -- 两列复合索引
    INDEX idx_user_product_status (user_id, product_id, order_status) -- 三列复合索引
);

---

冗余索引示例

下面这些索引在已有索引的情况下是冗余的（会被优化器忽略或造成资源浪费）：

-- 已有 idx_user_product(user_id, product_id)，所以以下单列索引冗余
CREATE INDEX idx_product_id ON orders(product_id); 

-- 已有 idx_user_product_status(user_id, product_id, order_status)，以下复合索引完全被包含，冗余
CREATE INDEX idx_user_product2 ON orders(user_id, product_id); 

-- 已有 idx_user_product_status(user_id, product_id, order_status)，以下索引是其前缀，冗余
CREATE INDEX idx_user_id2 ON orders(user_id);
CREATE INDEX idx_user_product_status2 ON orders(user_id, product_id, order_status); -- 完全重复

-- 顺序不同但等效的也可能冗余（依据查询模式）
CREATE INDEX idx_product_user ON orders(product_id, user_id); -- 如果没有这种使用场景也冗余