优化MySQL性能需先分析慢查询日志，通过EXPLAIN定位未走索引的SQL，为WHERE、ORDER BY等字段建立合适索引，避免全表扫描和函数操作；选择紧凑数据类型，拆分大表，使用自增主键；调整innodb_buffer_pool_size等参数；结合Redis缓存热点数据，主从分离读写，连接池复用连接，逐层优化效果更佳。
MySQL 性能优化是一个系统性工程，核心在于减少资源消耗、提升查询效率、合理利用索引和结构设计。关键点不在于堆配置，而在于理解数据访问模式和瓶颈所在。
1. 优化查询语句与索引设计
避免全表扫描是提升查询性能的第一步。大多数慢查询源于缺少合适的索引或写了低效的 SQL。
- 使用 EXPLAIN 分析执行计划，查看是否走了索引、扫描行数多少、是否有临时表或文件排序。
- 为 WHERE、ORDER BY、GROUP BY 涉及的列建立合适的索引，但不要过度建索引，会影响写入性能。
- 避免在 WHERE 条件中对字段进行函数操作，例如
WHERE YEAR(create_time) = 2024，应改为范围查询。 - 尽量避免 SELECT *，只查需要的字段，减少网络和内存开销。
- 大表分页时避免 OFFSET 过大，可用“记录上次位置”的方式改写，如
WHERE id > 100000 LIMIT 10。
2. 合理设计数据库结构
良好的表结构是高性能的基础。冗余要适度，范式与反范式结合使用。
- 选择合适的数据类型：用 INT 而不是 VARCHAR 存数字，用 ENUM 或 TINYINT 替代字符串状态码。
- 避免使用 TEXT/BLOB 大字段，除非必要，它们会拖慢查询，尤其在有排序或临时表时。
- 适当拆分大表（垂直或水平），比如将用户基本信息和日志分开存储。
- 使用 自增主键，保证插入效率和 B+ 树索引的有序性。
3. 配置参数调优
默认配置适合一般场景，高并发或大数据量时需调整关键参数。
- innodb_buffer_pool_size：设置为物理内存的 70%~80%，它是 InnoDB 缓存数据和索引的核心。
- innodb_log_file_size：增大可减少磁盘 I/O，但恢复时间变长，建议设为几百 MB。
- max_connections：根据应用连接池设置，避免连接过多导致内存耗尽。
- query_cache_type 和 query_cache_size：MySQL 8.0 已移除查询缓存，之前版本也建议关闭，因并发下锁争用严重。
4. 利用缓存与读写分离
数据库不是唯一的数据访问层，外部缓存能大幅减轻压力。
- 在应用层引入 Redis 或 Memcached 缓存热点数据，比如用户信息、配置项。
- 读多写少的场景可搭建 主从复制，将读请求分流到从库，减轻主库负担。
- 使用连接池（如 HikariCP）复用连接，避免频繁创建销毁连接的开销。
基本上就这些。优化要从慢查询日志入手，定位问题 SQL，再逐层分析索引、结构、配置。持续监控 + 小步调整，比盲目调参更有效。
