在数据库性能调优时，请从多个角度分析SQL查询响应变慢的常见原因，并系统阐述对应的优化策略与实施步骤。

回答思路

1. 【回答框架 1】性能瓶颈可归为四类：硬件资源、数据库配置、表结构与索引、SQL语句本身。硬件方面需关注CPU、内存、磁盘IO和网络带宽，资源不足常导致整体吞吐下降或延迟升高。
2. 【回答框架 2】表结构与索引层面，缺失索引会导致全表扫描，冗余索引增加写开销，统计信息过期使优化器选错执行计划。应定期审查索引使用情况，维护统计信息。
3. 【回答框架 3】SQL语句层面，非SARGable写法如对索引列使用函数或隐式类型转换会阻断索引使用；多表关联时驱动表选择不当、子查询或游标使用过度也会放大开销。改写时优先利用索引下推和覆盖索引。
4. 【回答框架 4】优化路径是先定位再治理：通过慢查询日志和性能监控找出高耗时语句，用EXPLAIN分析执行计划，观察type、key、rows等关键字段识别全表扫描或扫描行数过多；然后按成本从低到高依次调整索引、改写SQL、调整表结构，最后考虑读写分离或分库分表等架构级方案。
5. 【回答框架 5】治理中要建立基线对比，优化前后用压测或真实流量验证；对高频SQL可引入查询缓存或应用层缓存，但需评估数据一致性要求，避免过度设计。
6. 【关键点 1】使用EXPLAIN检查执行计划，重点看type、key、rows字段以识别全表扫描和扫描行数。
7. 【关键点 2】覆盖索引与非SARGable写法直接影响索引能否生效，是初步判断的关键。
8. 【关键点 3】优化顺序建议为索引调优、SQL改写、表结构设计，最后才考虑架构层面。
9. 【关键点 4】统计信息过期会导致优化器选错执行计划，需定期更新。
10. 【关键点 5】任何优化都应通过慢查询日志和实际压测验证效果，以事实数据为准。
11. 【易错点 1】不能只加索引而不关注现有索引的冗余度，过多无用索引会增加写入成本并占用空间。
12. 【易错点 2】在优化前未确认数据量级和实际执行计划，可能被错误系统参数或环境干扰导致误判。
13. 【易错点 3】将查询优化简单等同于索引优化，忽略数据分布和统计信息，可能导致优化方向偏离。