SQL 查询优化和索引策略是 Linux 数据库性能提升最直接、见效最快的两个抓手，需结合 EXPLAIN 分析执行计划、合理创建覆盖索引、优先重写低效 SQL，并协同调优 Linux 内核参数与文件系统配置。
SQL 查询优化和索引策略是 Linux 数据库性能提升最直接、见效最快的两个抓手。不合理的查询写法和缺失 / 低效的索引，往往让 CPU、I/ O 和内存白白承压，而这些问题在高并发或数据量增长后会集中爆发。关键不在堆硬件，而在看清执行路径、理解数据分布、精准干预访问方式。
看懂 EXPLAIN：从执行计划里找瓶颈
优化前不看 EXPLAIN，等于蒙眼调参。在 MySQL 或 PostgreSQL 中，用EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=JSON（MySQL 8.0+）获取真实执行细节，重点关注：
- Type 字段：ALL（全表扫描）、index（全索引扫描）是危险信号；尽量落到 range、ref、eq_ref 甚至 const
- Rows/estimated_rows：预估扫描行数远大于实际返回行数？说明索引没走对，或统计信息过期（可运行 ANALYZE TABLE 更新）
- Extra 列：出现 Using filesort、Using temporary、Using join buffer，意味着排序、临时表或缓冲区操作——这些极易成为慢点
- Key/Actual startup time：确认是否命中预期索引；PostgreSQL 中 startup time 显著高于 total time，可能表示过滤条件太弱、索引选择率差
索引不是越多越好：建什么、怎么建、何时删
索引本质是空间换时间，但维护成本（INSERT/UPDATE/DELETE 变慢、磁盘占用、缓冲池压力）必须纳入权衡。实战中坚持三条铁律：
- 覆盖索引优先：把 SELECT 字段和 WHERE/ORDER BY/GROUP BY 涉及的列打包进一个索引，避免回表。例如SELECT name, status FROM users WHERE dept_id = ? ORDER BY created_at DESC，可建(dept_id, created_at DESC, name, status)
- 区分度高的列放前面 ：比如gender（只有 M /F）和user_id（唯一）组合索引，user_id 必须在前，否则索引几乎无效
- 定期清理无用索引 ：MySQL 可通过sys.schema_unused_indexes 视图，PostgreSQL 查 pg_stat_all_indexes 中 idx_scan 为 0 且存在半年以上的索引，结合慢日志交叉验证
查询重写比加索引更治本的 5 种情况
很多慢查询根源在逻辑本身。与其硬扛索引，不如先重构 SQL：
- 用 EXISTS 替代IN (子查询），尤其子查询结果集大时，EXISTS 可短路退出
- 避免SELECT *，只取必要字段——减少网络传输、避免大字段拖累缓冲池
- 拆分复杂 JOIN：单次查 10 张表不如分 2–3 次查核心关联，用应用层组装，可控性更强
- 日期范围慎用函数包裹字段：WHERE DATE(create_time) = ‘2024-01-01’无法走索引，改写为WHERE create_time >= ‘2024-01-01’ AND create_time
- 分页深翻用游标替代 OFFSET：LIMIT 10000, 20 极慢，改用WHERE id > last_seen_id ORDER BY id LIMIT 20
Linux 环境下的协同调优要点
数据库跑在 Linux 上，内核参数和文件系统行为直接影响 IO 效率：
