做数据库优化这行当久了，你会发现一个残酷的事实：大部分性能问题，压根不是硬件不够快，而是SQL写得太糙、索引建得随意、架构设计的时候压根没想过数据量会涨成这样。我见过太多团队，一遇到慢查询就喊着加机器、上缓存，结果钱花了一大把，数据库该慢还是慢。真正的优化，是把每一分硬件资源都榨干，让数据库在现有条件下跑出极限性能。今天不聊虚的，直接拆解五个我用过无数次的实战技术，每一个都能在关键时刻救命。
第一个技术，也是最容易被忽视的：索引设计，但绝不是“建几个索引”这么简单。很多人以为给WHERE条件的字段加上索引就万事大吉，结果查询还是慢。问题出在索引失效上——比如你对索引字段做了函数运算，或者用了LIKE '%关键字'这种前置模糊匹配，索引直接罢工。我去年优化过一个电商订单查询，原本要3秒，排查后发现就是因为在日期字段上用了DATEFORMAT(createtime) = '2024-05-01'，改成createtime BETWEEN '2024-05-01 00:00:00' AND '2024-05-01 23:59:59'之后，索引生效，查询直接降到0.02秒。还有复合索引的顺序，区分度高的字段放前面，这是铁律。你要是把性别这种只有两个值的字段放第一位，索引基本白建。
第二个核心技术是SQL改写，这里头的门道深了。很多慢查询不是数据库不行，是SQL写得绕。我最常干的事，就是把子查询改成JOIN，把OR改成UNION ALL，把IN改成EXISTS。举个例子，一条查“未下单用户”的SQL，用NOT IN子查询，数据量一大就慢得离谱，因为子查询要全表扫一遍。改成LEFT JOIN + IS NULL，性能直接翻倍。还有分页查询，传统的LIMIT 100, 20，MySQL要扫十万行再丢弃，纯属浪费。改成WHERE id > 100 LIMIT 20，走索引直接定位，快得飞起。这些改写看着简单，但没踩过坑的人根本想不到。
第三个技术是分区表，这个得看场景，用好了是神器，用不好是累赘。分区不是让你随便按个字段就切，得按查询模式来。比如日志表，天然按时间查，那就按月份分区，查询直接命中分区，扫描数据量缩到原来的几十分之一。我做过一个物联网设备数据表，一年涨到2亿行，查询慢到没法用。后来按设备ID哈希分成64个分区，单次查询扫描的数据量从2亿降到300万，响应时间从8秒压到0.3秒。但记住，分区键必须是你查询条件里的常客，否则分区不仅没帮助，反而增加管理复杂度。
第四个技术是连接池与参数调优，这块最枯燥，但收益最稳定。很多人拿着默认配置就跑生产环境，那真是暴殄天物。MySQL的innodbbufferpoolsize，默认才128M，你机器有64G内存，这不是浪费吗？直接调到物理内存的70%，热点数据全在内存里，磁盘IO瞬间降下来。还有maxconnections，默认151，稍微有点并发就报连接数超限。但别傻乎乎地往高了调，得结合threadcachesize一起调，不然线程频繁创建销毁，CPU全耗在上下文切换上了。连接池这块，HikariCP的maximumPoolSize别设太大，10个就够，设成50个反而因为线程竞争更慢。
第五个技术，也是最容易被忽略的：执行计划分析。别信什么“优化靠经验”，EXPLAIN就是你的显微镜。每次SQL慢，第一步就是EXPLAIN看type列，如果是ALL，说明全表扫描，赶紧加索引；如果是ref或者eqref，说明索引用的还行；看到rows列和实际返回行数差距过大，就说明统计信息不准，得ANALYZE TABLE。还有Extra列里出现Using filesort或者Using temporary，这俩就是性能杀手，得想办法通过索引排序或者改写SQL消除掉。我见过一个报表查询，跑了20秒，EXPLAIN一看，Extra显示Using temporary; Using filesort，改完索引后0.5秒，就这么直接。
这五个技术，单独拎出来任何一个都能写篇论文，但实战中它们是组合拳。索引设计是地基，SQL改写是结构优化，分区表是空间换时间，参数调优是榨干硬件，执行计划分析是诊断手段。我见过太多人，一上来就堆缓存、上读写分离，结果治标不治本，缓存击穿的时候照样瘫痪。真正的优化，是从SQL到索引再到架构，一层一层往下钻，每一步都扎实了，性能自然就上来了。数据库这东西，从来不跟你玩虚的，你给它好的SQL和索引，它回你毫秒级的响应；你糊弄它，它就让你加班到深夜。这五项技术，你每掌握一项，就少一次深夜救火的经历。
