MySQL 3.23中Timestamp索引未提升查询性能，求优化方案

• 确认索引是否实际生效
  执行EXPLAIN SELECT * FROM mytable WHERE last_mod_date >= 'some_date';，查看结果中的type列（显示range/ref代表使用了索引，ALL则是全表扫描）和key列（是否为last_mod_date_idx）。如果未走索引，大概率是查询返回行数占表总数据比例过高（通常超过30%），MySQL会判定全表扫描比索引回表成本更低。这种情况可以强制指定索引：SELECT * FROM mytable FORCE INDEX(last_mod_date_idx) WHERE last_mod_date >= 'some_date';，测试是否能提速。

• 严格匹配timestamp(14)的查询格式
  timestamp(14)存储的是YYYYMMDDHHMMSS格式字符串，查询时必须传入完全符合该格式的参数（例如'20240101000000'），避免MySQL做隐式类型转换导致索引失效。

• 优化MyISAM引擎配置参数
  MySQL 3.23默认使用MyISAM引擎，可在my.cnf中调整以下参数（重启服务生效）：

  • key_buffer_size：调大索引缓存，建议设为服务器内存的1/4（内存充足时），减少索引的磁盘读取次数；
  • read_buffer_size：增大顺序读缓存，适配MyISAM全表扫描或范围查询的场景；
  • sort_buffer_size：若查询涉及排序，调大该参数提升排序效率。

• 整理表碎片
  执行OPTIMIZE TABLE mytable;，MyISAM表经频繁增删改后会产生数据碎片，整理后能让数据与索引更紧凑，降低磁盘IO开销。注意该命令会锁表，必须在业务低峰期执行。

• 手动拆分分表
  MySQL 3.23不支持分区表，可按last_mod_date的时间范围手动拆分表，比如按年拆分为mytable_2023、mytable_2024，查询时直接访问对应时间范围的分表，大幅减少扫描行数。跨时间范围查询时，可通过联合查询多个分表实现。

• 开启查询缓存（按需使用）
  若该查询执行频率高且表更新频率低，可开启查询缓存：在my.cnf中设置query_cache_type=1，query_cache_size设为合适值（如64M），相同查询第二次会直接从缓存返回，避免重复计算。但若表更新频繁，查询缓存命中率极低，反而增加额外开销，此时不建议开启。

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