MySQL存储股票历史价格查询慢优化及替代存储方案咨询

你的性能问题核心出在联合索引的顺序设计不符合查询场景：
你当前的主键是PRIMARY KEY (date, symbol)，遵循InnoDB联合索引的最左匹配原则，只有查询条件前缀带date时才能用上这个索引。而你最常用的查询是WHERE symbol = 'xxx' AND date BETWEEN 'xxx' AND 'xxx'，查询条件前缀是symbol，根本走不上主键索引，每次查询都是全表扫描50万行数据，所以才会耗时8秒。
你可以在SQL中执行EXPLAIN关键字查看执行计划，会看到type列的值为ALL，也就是全表扫描，可直接验证这个问题。

• 存储层优化：优先选用时序数据库存储行情这类时间序列数据，索引设计完全适配按标的+时间范围查询的核心场景，同时做冷热数据分离，高频访问的近期数据存在高性能存储，低频历史数据存在高吞吐低成本存储
• 多级缓存体系：热门股票的全量行情、常用时间范围的查询结果会提前缓存在Redis等内存数据库中，静态资源、接口返回结果会通过CDN做边缘节点缓存，同时浏览器端也会做本地缓存避免重复请求
• 预聚合计算：提前按日、周、月、年等不同时间粒度预计算好行情数据，用户查询对应粒度的图表时直接返回结果，不需要实时聚合计算
• 按需加载：前端不会一次性拉取全量行情数据，优先加载当前可视区域的时间范围数据，用户缩放、拖拽图表时再请求对应粒度的增量数据

该方案在你的轻量业务场景下是可行的，每只股票单独存一个CSV文件，查询时直接读取对应文件过滤时间范围，性能会显著优于你当前未优化索引的数据库查询。但CSV存储存在明显短板：

• 没有内置索引，查询时间范围仍需遍历整个文件，当单股票行情数据量超过万行后性能会明显下降
• 不支持事务，并发读写时容易出现脏读、文件损坏问题，需要额外实现锁机制
• 无法支持复杂查询需求，比如多股票行情比对、批量指标计算等场景完全无法适配
  如果你的业务只有单股票时间范围查询这一个核心需求，可以短期使用该方案，长期还是推荐优化数据库存储方案。

你当前的核心性能瓶颈是索引设计错误，不做优化的前提下迁移到任何服务器都不会有明显提升。如果完成索引优化后，PythonAnywhere的共享资源限制（CPU、IO、数据库连接数限速）成为新的瓶颈，迁移到AWS可以获得明显提升：

• 可以自主选配高IO的云数据库实例，调整数据库参数匹配业务场景
• 可以灵活搭建Redis缓存、CDN等架构，进一步降低接口响应时间
• 可以根据流量动态扩容资源，避免共享主机的性能波动影响

直接调整表的索引设计，要么将联合主键的顺序修改为PRIMARY KEY (symbol, date)，要么新增一个二级索引CREATE INDEX idx_symbol_date ON EOD_QRSTU (symbol, date)，调整后单表50万行的查询耗时可以直接降到10毫秒以内，投入成本远低于改文件存储或提前迁移云服务。

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