你打开数据库监控面板，看到慢查询日志像瀑布一样往下刷，CPU 飙到 90%，用户投诉系统卡得像幻灯片。这种场景我见过太多次了，每次都是性能优化没做到位。今天咱们就聊数据库性能优化的五大方法，从索引调优到查询重构，全是实战里踩过坑才总结出来的干货。
先说索引调优，这玩意儿是数据库性能的命门。很多人建索引就像往菜里撒盐，随心所欲——主键建一个，外键建一个，看到 WHERE 条件再建一个，结果索引比表还大，写入慢得像乌龟爬。我见过一个电商订单表，开发大哥把时间戳、用户 ID、状态字段全建了独立索引，查询时 MySQL 只能选一个，其他索引白建了还占空间。正确的做法是建联合索引，把区分度高的字段放前面，比如用户 ID + 订单时间，这样单个索引就能覆盖大部分查询。另外别忘了定期用 检查索引使用率，那些半年都没用过的索引，果断删掉，别心疼。
索引调优搞定了，咱们得聊聊查询缓存。这个功能在 MySQL 8.0 之前是个宝，但后来被官方废弃了，为什么？因为在高并发写入场景下，缓存刷新频率太高，反而拖累性能。我接手过一个论坛系统，每天发帖量上万，查询缓存一开，每次新帖插入都要清空相关缓存，读请求还得重新写缓存，CPU 直接炸了。现在更推荐用外部缓存层，比如 Redis 或 Memcached，把高频查询的结果存进去，设置合理的过期时间。可以把用户信息、商品详情这种不常变的数据丢到缓存里，数据库只负责写入和更新，这样压力能降一大半。
接下来是查询重构，这是最能体现功力的一环。很多人写 SQL 就像写散文，想到哪写到哪，完全不考虑执行计划。我见过最离谱的查询是一个三层嵌套的子查询，里面还用了 ，结果扫描了全表 200 万行数据。其实用 加 就能优化成索引查询，速度从 30 秒降到 0.1 秒。重构查询的核心是避免全表扫描，多用 JOIN 代替子查询，用 EXISTS 代替 IN，用 UNION ALL 代替 UNION（去重很耗资源）。还有一点：别在 WHERE 条件里对字段做函数操作，比如 ，这会让索引失效，改成范围查询 ，性能天差地别。
表结构设计是容易被忽视的优化点。很多人设计表时恨不得把所有字段都塞进去，结果一张表三四十个字段，单行长度比你家沙发还长。数据库是按页存储的，单行越长，每页能存的行数越少，查询时 IO 次数就越多。我优化过一个用户表，里面存了头像 URL、个性签名、收货地址这些大字段，结果查询用户列表时连头像链接都要读出来，浪费带宽。正确的做法是把大字段拆分到独立表里，用外键关联；或者用垂直分表，把经常一起查询的字段放在一起，不常用的字段扔到扩展表。另外，字段类型也要精打细算，能用 TINYINT 就别用 INT，能用 VARCHAR(50) 就别用 VARCHAR(255)，省下的空间都是性能。
说说数据库参数调优，这个容易被忽略但效果立竿见影。很多人装完 MySQL 就用默认配置，连 都没改过。默认值只有 128 MB，对于 16 GB 内存的服务器来说简直是浪费。这个参数控制 InnoDB 的缓冲池大小，建议设为物理内存的 70%‑80%，能极大减少磁盘 IO。还有 在 8.0 之前要关掉， 要根据并发量调大， 和 也别设太大，每个连接都会分配一份，设大了内存扛不住。我习惯用 或 这种工具扫一遍配置，它会给出具体的调优建议，比人工翻文档快多了。
这五大方法环环相扣，从索引到查询再到表结构和参数，每一步优化都能让数据库性能有明显提升。但记住，没有银弹——不要一上来就改参数，先分析慢查询日志，找到瓶颈在哪。我见过有人花一周调索引，结果问题是磁盘 IO 瓶颈，换个 SSD 就解决了。所以先诊断再下药，用 分析执行计划，用 看当前连接状态，用 定位资源消耗。数据库优化是门手艺活，得多练多踩坑，慢慢就能一眼看出问题所在。下次你的数据库再卡成幻灯片，按这五个方法逐一排查，大概率能搞定。
