用好索引需权衡读写代价，避免低区分度字段建索引；控制结果集大小，禁用select *和大offset分页；合理设置buffer_pool_size（物理内存60%–75%）；避免临时表落盘，优先优化group by/order by索引。
用好索引，但别盲目建索引
索引能加速查询，但每个索引都会增加写入开销和磁盘占用，更关键的是——SELECT 扫描范围过大时，即使有索引，也可能触发大量随机 IO。比如 WHERE status = 1 这种低区分度字段建了索引，mysql 很可能放弃走索引而全表扫描；反过来，如果强制 FORCE INDEX，反而导致大量页读取，IO 不降反升。
实操建议：
- 用
EXPLAIN看type是否为range或ref，避免ALL和index（后者是全索引扫描，仍高 IO） - 联合索引遵循最左前缀，把高区分度字段放前面，例如
(user_id, created_at)比(status, user_id)更容易命中有效范围 - 定期用
sys.schema_unused_indexes（MySQL 8.0+）或performance_schema.table_io_waits_summary_by_index_usage查未被使用的索引，删掉它们
控制结果集大小，别让 MySQL 多读一页
MySQL 的 IO 单位是页（默认 16KB），哪怕你只查 1 行，只要该行在某页里，就得把整页从磁盘加载进 buffer pool。如果 SELECT * + LIMIT 10 实际扫描了 10 万行才凑够 10 条，那 IO 成本就由这 10 万行所在的页数决定，不是 10 行。
实操建议：
- 永远明确指定需要的列，避免
SELECT *，尤其不要在宽表上这么做 - 在分页场景中，慎用
OFFSET：例如LIMIT 10000, 20会让 MySQL 先定位前 10000 行，再取后续 20 行——这些中间行对应的页全得读一遍。改用游标式分页（如WHERE id > last_seen_id ORDER BY id LIMIT 20） - 用
SQL_CALC_FOUND_ROWS已被弃用，替代方案是单独跑SELECT count(*)并缓存，或用近似值（如TABLES.ROW_COUNT）预估
调大 innodb_buffer_pool_size，但别超过物理内存 75%
Buffer Pool 是 InnoDB 缓存数据页和索引页的地方。如果它太小，查询频繁触发磁盘 IO；但如果设得太大，会挤压 OS 文件缓存和其他进程内存，反而引发 swap 或 OOM。
实操建议：
- 观察
SHOW ENGINE INNODB STATUS中的Buffer pool hit rate，长期低于 99% 就该扩容 - 用
SELECT (Pages_data*16384)/1024/1024 AS size_mb FROM information_schema.INNODB_BUFFER_POOL_STATS;算当前实际使用量 - 生产环境建议设为物理内存的 60%–75%，且必须是 1MB 对齐（
innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances要整除）
避免临时表落盘，尤其是 GROUP BY 和 ORDER BY
当 GROUP BY 字段没索引，或 ORDER BY 涉及多列且无法利用索引排序时，MySQL 可能创建内部临时表。若该表超出 tmp_table_size 和 max_heap_table_size 中的较小值，就会从内存转成磁盘临时表（ON DISK），带来严重 IO。
实操建议：
- 在
EXPLAIN结果中检查Extra列是否含using temporary；如果是，优先给GROUP BY或ORDER BY字段加索引 - 调高
tmp_table_size和max_heap_table_size（需两者一致），但注意：该内存属于每个连接独占，不能无限制堆高 - 用
SELECT SQL_NO_CACHE ...测试真实 IO 表现，避免被 query cache 干扰判断
缓冲池大小、索引选择性、临时表阈值——这三个地方最容易被当成“配完就完事”的参数，其实它们彼此牵连：一个调得不对，其他优化全打折扣。