传感器时序数据表：指定条目后续记录查询优化及性能疑问

一、更简洁优雅的实现方式 #

你的原始查询已经很直接，但如果你的MySQL版本是8.0及以上，**窗口函数LEAD()/LAG()**会是更优雅的选择——它能在一次查询中同时拿到当前记录和对应的下一条（或上一条）数据，不用单独发起两次查询。举个例子：

假设你已经通过某个条件定位到了目标记录的sensor和timefield，可以这样写：

SELECT 
  *,
  LEAD(timefield) OVER (PARTITION BY sensor ORDER BY timefield) AS next_time,
  LEAD(temperature) OVER (PARTITION BY sensor ORDER BY timefield) AS next_temperature
FROM mytable
WHERE sensor = 'some_id' AND timefield = '2018-1-29 11:22';

这样就能直接获取当前记录的下一条时间和对应字段值。如果只需要下一条完整记录，也可以用CTE先锁定目标时间，再关联查询：

WITH target_record AS (
  SELECT timefield FROM mytable WHERE sensor = 'some_id' AND timefield = '2018-1-29 11:22'
)
SELECT * FROM mytable 
JOIN target_record ON mytable.sensor = 'some_id' AND mytable.timefield > target_record.timefield
LIMIT 1;

不过如果只是单次获取下一条记录，你的原始写法其实已经足够简洁，窗口函数更适合批量处理多条记录的场景。

二、联合索引下性能不佳的排查点 #

你已经建了(sensor, timefield)的联合索引，理论上这个查询应该能高效命中索引，下面是几个可能的问题排查方向：

• 检查索引是否被实际调用：用EXPLAIN分析你的查询，看type列是不是range，key列是不是HostnameTimestamp。如果没用到索引，可能是优化器选错了执行计划，可以尝试强制指定索引：

  SELECT * FROM mytable FORCE INDEX(HostnameTimestamp) 
  WHERE sensor="some_id" and timefield>"2018-1-29 11:22" 
  LIMIT 1;
  

• 确认timefield的数据类型：如果timefield是字符串类型（比如VARCHAR）而非DATETIME/TIMESTAMP，字符串的范围比较和排序会大幅降低索引效率，建议改成标准日期时间类型。
• 更新表统计信息：如果表数据量变化频繁，MySQL的统计信息可能过时，导致优化器判断错误。可以执行ANALYZE TABLE mytable;更新统计信息，帮助优化器选择正确的索引。
• 清理索引碎片：如果表频繁插入或删除数据，索引会产生碎片，拖慢查询速度。可以在低峰时段执行OPTIMIZE TABLE mytable;重建索引（注意该操作会锁表，需避开业务高峰期）。
• 去掉冗余的ORDER BY：因为你的联合索引是(sensor, timefield)，当sensor固定时，索引内的timefield已经是升序排列的，满足timefield > xxx的记录天然有序，ORDER BY timefield asc可以直接省略，减少排序开销：

  SELECT * FROM mytable 
  WHERE sensor="some_id" and timefield>"2018-1-29 11:22" 
  LIMIT 1;
  

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