MySQL性能优化核心是硬件与配置协同：内存需覆盖热数据以提升InnoDB缓冲池命中率，SSD+RAID10降低索引IO延迟，关闭swap和查询缓存并调优OS参数释放资源，辅以Redis等应用层缓存分担高频查询压力。
服务器配置本身不直接“创建”索引或“设置”缓存，但它决定了索引和缓存能否真正发挥作用。索引是数据库逻辑层的设计产物，缓存（如InnoDB Buffer Pool、查询缓存或Redis）依赖于硬件资源与系统参数协同工作。优化的核心是：让内存足够大、存储足够快、CPU能并发处理、系统不干扰数据库的资源调度。
内存分配要匹配热数据规模
InnoDB缓冲池（innodb_buffer_pool_size）是MySQL最核心的缓存机制，它把频繁访问的数据页和索引页保留在内存中，避免反复读盘。如果服务器有64GB物理内存，而你的热数据（常被查询的表+索引）约30GB，建议将buffer pool设为32–48GB（即50%–75%），留足空间给OS和其他服务。设得太小会导致频繁换页；设得过大可能引发swap抖动。
- 检查当前使用率：执行 SHOW ENGINE INNODB STATUS\G，看“Buffer pool hit rate”是否稳定在99%以上
- 动态调整（无需重启）：SET GLOBAL innodb_buffer_pool_size = 34359738368;（32GB）
- 永久生效：在my.cnf的[mysqld]段添加：innodb_buffer_pool_size = 32G
SSD + 合理RAID提升索引访问效率
索引再好，若底层存储慢，查找过程仍卡在IO上。B+树索引的随机读性能高度依赖磁盘延迟。机械硬盘平均寻道时间约10ms，而消费级SSD约0.1ms，企业级NVMe SSD可低至0.03ms——差出两个数量级。
- 用SSD存放数据文件（datadir）和日志（innodb_log_group_home_dir）
- 生产环境推荐RAID 10（非RAID 1），兼顾速度与容错；若预算有限，单NVMe盘也远胜多块HDD做RAID 5
- 确认IO调度器适配SSD：echo mq-deadline > /sys/block/nvme0n1/queue/scheduler
关闭干扰项，释放缓存资源
操作系统层面的默认设置可能“抢走”本该留给MySQL缓存的空间。比如swap、文件描述符限制、过度预读等，都会间接削弱索引命中率和缓存稳定性。
- 禁用swap倾向：vm.swappiness=1（写入/etc/sysctl.conf并sysctl -p）
- 扩大文件句柄上限：* soft nofile 65535 和 * hard nofile 65535 加入/etc/security/limits.conf
- 关闭MySQL 8.0已废弃的查询缓存（query_cache_type=0），避免写操作触发无效刷新
配合应用层缓存分担索引压力
即使索引高效、buffer pool充足，高频重复查询（如首页商品列表、用户配置）仍会反复穿透到InnoDB层。这时应在数据库之外加一层内存缓存，把结果直接返回，绕过索引查找和行扫描。
- 对读多写少的热点数据，用Redis缓存序列化结果（如JSON），设置合理TTL
- 缓存键设计需包含业务上下文，例如 user:profile:10086 而非泛泛的 profile
- 写操作后主动失效缓存（而非等待过期），保证一致性；必要时结合binlog监听做自动更新
