MySQL索引查询慢问题咨询：50M行MyISAM表首次查询耗时久

咱们一步一步拆解你遇到的这个性能问题，先搞清楚每个现象背后的原因：

1. 首次查询慢、第二次秒出的核心原因：缓存机制 #

第一次执行查询时，不管是索引数据还是表数据都还没加载到内存缓存里——MyISAM有自己的key_buffer（键缓存）用来存储索引，操作系统也有文件系统缓存存储表数据。这时候MySQL得从磁盘上读取数据，磁盘IO的速度远慢于内存，所以耗时15-40秒是典型的冷加载表现。

间隔1秒再次查询时，需要的索引和数据已经被缓存到内存里了，直接从内存读取即可完成，所以只需要0.02秒。这是缓存命中带来的正常性能提升，不是查询本身的优化问题。

2. EXPLAIN Rows差异的原因：索引结构与统计信息 #

用userid索引时Rows=92000 #

你只给userid建了单值索引，MySQL通过这个索引找到所有userid=4的行后，还需要回表读取id字段，再对id做降序排序。EXPLAIN里的Rows=92000，是优化器预估的userid=4的总行数，这个过程不仅要读索引，还要读表数据，排序的开销也不小，尤其是首次磁盘IO阶段。

强制不使用索引时Rows=3000 #

这个数值大概率是MyISAM的表统计信息过时导致的优化器预估错误——MyISAM的统计信息不会自动实时更新，当表数据量变化较大时，优化器拿到的行数预估就会失真。实际强制不使用索引时，MySQL会做全表扫描，实际扫描行数远不止3000，所以首次查询还是慢。

3. 你的索引和查询的核心问题 #

• 单值索引userid无法覆盖排序需求：查询需要ORDER BY id DESC，但现有索引只包含userid，导致MySQL必须回表取id再排序，额外增加了IO和计算开销。
• MyISAM的统计信息可能过时，导致优化器的执行计划预估不准。
• 键缓存可能不足，导致索引数据无法全部常驻内存，加剧了首次查询的磁盘IO。

解决方案 #

• 创建复合覆盖索引：建一个(userid, id DESC)的复合索引，这样MySQL可以直接通过索引找到所有userid=4的行，并且这些行已经按id降序排好，不需要回表，也不需要额外排序，能极大减少IO和计算开销。执行语句：

  CREATE INDEX idx_userid_id_desc ON your_table_name(userid, id DESC);
  

  （注意把your_table_name换成你的实际表名）
• 更新表统计信息：执行ANALYZE TABLE your_table_name;，让优化器获得准确的行数预估，避免执行计划选择错误。
• 调整MyISAM键缓存大小：检查my.cnf（或my.ini）里的key_buffer_size参数，确保它足够容纳常用索引数据（对于50M行的表，建议根据服务器内存情况设置为几百MB到1GB左右）。

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