在日常开发中，针对 MySQL 数据库，你会如何开展性能优化？请结合实际场景阐述主要的优化策略。

回答思路

1. 【回答框架 1】MySQL 性能优化应自上而下分层推进：先做架构与设计优化，再做 SQL 与索引优化，最后才是参数与硬件调优。架构层面包括读写分离、分库分表、缓存（如 Redis）引入，目的是降低单库压力并分流读请求。
2. 【回答框架 2】SQL 优化是收益最高的一环：避免 SELECT *，只取必要列；对 WHERE、ORDER BY、GROUP BY 涉及的字段建立合适索引，遵循最左前缀原则；避免在索引列上使用函数或隐式类型转换，防止索引失效；用 EXPLAIN 分析执行计划，关注 type、key、rows 等关键字段。
3. 【回答框架 3】索引优化要结合数据区分度：区分度低的列（如性别）不适合单独建索引；联合索引应把等值查询列放在前面，排序或范围查询列放后面；合理使用覆盖索引减少回表；注意索引数量过多会拖慢写入。
4. 【回答框架 4】配置与硬件层面的优化属于兜底手段：调整 innodb_buffer_pool_size 至物理内存的 60%-80%，合理设置连接数、慢查询日志阈值等；若仍无法满足性能要求，再考虑升级硬件或使用更高效的存储引擎。
5. 【回答框架 5】所有优化都必须以度量为基础：先定位瓶颈（慢查询日志、性能监控），再针对性地优化，避免盲目调参。优化后要通过压测验证效果，并关注对写入、锁等带来的副作用。
6. 【关键点 1】性能优化应遵循从架构、SQL、索引到参数的分层顺序，避免直接调参数。
7. 【关键点 2】索引优化需遵守最左前缀原则并避免索引失效，用 EXPLAIN 验证执行计划。
8. 【关键点 3】任何优化都要基于瓶颈定位和压测验证，而非经验性调整。
9. 【易错点 1】只关注 SQL 和索引而忽略架构层面的读写分离和缓存，可能无法解决高并发下的根本瓶颈。
10. 【易错点 2】对低区分度列建立索引不仅无效，反而增加写入开销。
11. 【易错点 3】过度调大 buffer pool 或连接数可能导致内存或上下文切换压力，需结合资源上限谨慎调整。