在不引入分库分表方案的前提下，当某张单表的数据量变得非常大时，有哪些可行的优化手段？请说明你通常会从哪些方面着手处理以及相应的理由。

回答思路

1. 【回答框架 1】核心思路是先从访问模式与瓶颈定位出发，再分层优化。先通过慢查询日志、执行计划与监控确认是磁盘IO、CPU还是锁等待成为瓶颈，避免盲目加索引或换硬件。
2. 【回答框架 2】索引优化是基础手段，针对高频查询的WHERE、JOIN与ORDER BY字段建立合适索引，注意复合索引最左前缀原则，避免冗余索引，并利用覆盖索引减少回表。同时对超宽表做字段拆分，将大字段如TEXT、BLOB移出主表，采用垂直拆分思路在单库内缓解行宽压力。
3. 【回答框架 3】利用缓存分担读压力，对读多写少且实时性要求不高的热点数据引入Redis等缓存，并设计合理的过期策略与穿透、击穿、雪崩应对方案，但需明确缓存只能缓解读取，不能解决写入与一致性根本问题。
4. 【回答框架 4】对于历史数据或大字段可考虑归档与冷热分离，将低频访问数据迁移到归档表或冷存储，定期清理无效数据，保持主表规模可控。若写入并发高，可引入消息队列削峰填谷，并在应用层进行批量写入合并，但需评估最终一致性对业务的影响。
5. 【回答框架 5】若单表数据量增长已影响写事务性能，可考虑表结构优化如分区表，在单表逻辑内按范围或哈希分区，便于分区裁剪与定期归档，但分区不能解决所有性能问题，需评估查询是否带分区键，避免分区失效。
6. 【关键点 1】先定位瓶颈再针对性优化，避免盲目手段叠加。
7. 【关键点 2】索引设计需遵循最左前缀原则并考虑覆盖索引减少回表。
8. 【关键点 3】大字段拆分与冷热数据归档能够显著降低单表行宽与数据规模。
9. 【关键点 4】缓存适用于读多写少且允许一定延迟的场景，不能解决一致性。
10. 【关键点 5】分区表需保证查询条件包含分区键才能有效裁剪，不能滥用。
11. 【易错点 1】将缓存当作万能药，忽视数据一致性与穿透击穿风险。
12. 【易错点 2】建立过多冗余索引反而降低写入性能并增加存储开销。
13. 【易错点 3】分区表使用不当，如未带分区键查询导致扫描全部分区，性能下降。