MySQL Join+OrderBy查询性能优化求助：耗时77秒未用title索引

针对你遇到的查询耗时77秒、依赖临时表和文件排序的问题，以下是具体优化方案：

1. 优化report_urls的过滤索引 #

给report_urls添加联合索引(report_id, url_id)：

ALTER TABLE report_urls ADD INDEX idx_report_url (report_id, url_id);

这个索引能让MySQL快速定位到指定report_id下的所有url_id，无需扫描全表，大幅缩小后续JOIN操作的数据集规模，从源头降低排序压力。

2. 给urls添加排序+关联的联合索引 #

给urls添加联合索引(title, id)：

ALTER TABLE urls ADD INDEX idx_title_id (title, id);

原查询单独的title索引无法满足排序+关联的需求，因为关联需要用到id字段。这个联合索引同时包含排序所需的title和关联所需的id，MySQL可以直接通过该索引按title顺序获取匹配的id，彻底避免临时表和文件排序。

3. 改写查询逻辑，先排序再取数 #

将查询拆分为子查询先获取排序后的小数据集，再关联取完整数据：

SELECT ru.*, u.*
FROM (
    SELECT ru.url_id
    FROM report_urls ru
    JOIN urls u ON ru.url_id = u.id
    WHERE ru.report_id = '8f6598f0-34d0-48b0-be8b-41c1b8f61ffd'
    ORDER BY u.title ASC
    LIMIT 11 OFFSET 0
) AS sorted_ids
JOIN report_urls ru ON sorted_ids.url_id = ru.url_id
JOIN urls u ON sorted_ids.url_id = u.id

子查询仅返回需要的前11个url_id，后续关联操作只处理极小的数据集，避免对大量数据进行排序和临时存储。

4. 优化UUID主键的性能问题 #

InnoDB的聚簇索引特性导致UUID作为主键会产生大量索引碎片，影响查询效率。如果业务允许：

• 考虑将主键替换为自增INT或BIGINT；
• 改用有序UUID（如UUIDv1带时间戳前缀、UUIDv7），减少索引碎片，提升整体读写性能。

内容的提问来源于stack exchange，提问作者Josh M