MySQL提取JSON数据的查询耗时过长，运行超1小时未返回如何解决？

• 最核心的原因是WHERE条件用到的timestamp字段没有建立索引：表仅在m_id上有索引，执行查询时需要全表扫描9万行数据，而每行数据平均1MB，全表扫描需要读取近90GB的磁盘数据，IO开销极高，自然耗时极长。
• JSON字段解析开销大：即使扫描到符合timestamp条件的行，也需要完整解析单条1MB大小的JSON结构才能提取指定路径的数据，进一步拉高了执行耗时。
• 无过滤的全量数据读取：查询没有加LIMIT限制，如果符合timestamp条件的行数量较多，还会额外增加数据解析和返回的开销。

• 优先给timestamp字段建立普通索引：这是成本最低、收益最高的优化手段，建索引后查询时可以直接定位到符合timestamp条件的行，避免全表扫描，不需要读取无关行的超大JSON字段，查询耗时会降到秒级甚至毫秒级。
  建索引语句参考：

  CREATE INDEX idx_mytable1_timestamp ON mytable1(`timestamp`);
  

  注意timestamp是MySQL关键字，建索引时需要用反引号包裹。
• 对常用的JSON提取路径配置生成列：如果经常需要提取$.abc1这类固定路径的内容，可以在MySQL 5.7及以上版本使用生成列预先存储解析结果，避免每次查询都重复解析JSON：

  -- 新增存储式生成列，写入数据时自动计算并存储结果，查询时直接读取
  ALTER TABLE mytable1 ADD COLUMN abc1 JSON GENERATED ALWAYS AS (JSON_EXTRACT(mydata, '$.abc1')) STORED;
  

  如果还需要基于JSON内的字段做过滤，也可以给生成列单独建立索引。
• 高频访问字段拆分为常规列：如果JSON内的某几个字段访问频率极高，可以直接将其拆为独立的常规字段，写入数据时同步更新，查询性能远高于JSON解析提取。
• 查询时增加合理的LIMIT限制：如果仅需要单条结果，加上LIMIT 1可以在匹配到第一条符合条件的数据后就终止查询，进一步降低开销。

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