含多计算、JOIN和ORDER BY的慢MySQL查询优化及替代方案

核心优化思路：先缩小候选集，再做计算和关联，尽量避免全量计算后过滤 #

1. 优先优化地理距离过滤逻辑（收益最高） #

当前你是全量计算所有符合基础条件的用户的距离后，再用HAVING distance < 50过滤，10万+数据全量算三角函数开销极高。

• 先计算目标坐标的经纬度边界框，提前在WHERE阶段过滤掉超出范围的用户：
  50英里对应的纬度差约为0.72°，经度差约为1.2°，新增过滤条件：

  AND lat BETWEEN 53.80592 - 0.72 AND 53.80592 + 0.72
  AND lng BETWEEN -1.53834 - 1.2 AND -1.53834 + 1.2
  

• 给places表的lat、lng加联合索引，边界框过滤可以直接走索引，直接把候选集从10万+缩小到几百甚至几十，后续计算量骤降。

2. 冗余字段消除计算列、减少关联 #

你当前排序用的is_premium、recent_login，以及查询用的is_available、feedback_score都可以通过冗余预存，避免每次查询计算和关联：

• 在users表新增is_premium（tinyint）、is_available（tinyint）、feedback_score（int）三个冗余字段：
  • is_premium：用户续费/到期时自动更新，或每天定时任务批量更新，不用每次查询关联users_places算max
  • is_available：用户修改可用日期时自动更新，或每天定时任务批量更新，不用每次关联users_dates_available
  • feedback_score：新增审核通过的反馈时自动累加，不用每次查询sum子查询
• 排序逻辑可以直接替换为ORDER BY is_premium DESC, last_online_at DESC，和你原来的recent_login倒序效果完全一致，而且last_online_at是实字段，可以走索引。

3. 索引优化 #

针对过滤条件建覆盖索引，避免回表：

-- users表覆盖索引：匹配where条件，包含后续需要用到的所有字段，无需回表
ALTER TABLE users ADD INDEX idx_filter (status, approved, id, username, last_online_at, place_id, is_premium, is_available, feedback_score);
-- places表经纬度联合索引
ALTER TABLE places ADD INDEX idx_lng_lat (lat, lng);

4. 兜底方案（不改表结构的前提下） #

如果暂时不能加冗余字段，可以调整查询逻辑：

• 先通过边界框过滤出符合距离要求的用户ID，只查ID和要计算的字段，拿到候选集后再做后续关联、计算、排序，因为候选集已经很小，不管是MySQL排序还是PHP排序速度都会非常快。
• 如果数据量持续增长，建议迁移到Elasticsearch存储用户属性和位置信息，内置的地理查询+排序能力可以轻松支持毫秒级返回。

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