上周帮一个做电商的朋友调数据库，他那订单查询接口慢得离谱，一个简单的按时间范围查订单，居然要等七八秒。我看了看表，告诉他，你这数据量其实不大，才两百万行，问题出在几个关键地方没处理好。他半信半疑，等我调完三个地方，同样的查询从7.2秒变成了0.6秒，他当场就愣住了。这事让我觉得，数据库优化其实没那么玄乎，核心就三个方向：索引优化、查询重构、硬件配置。这三个方案用好了，查询速度飙升10倍真不是吹的。
先说索引优化，这是最立竿见影的。很多人建索引就像往墙上钉钉子，哪疼钉哪。比如给每个字段都建索引，结果写操作慢得像蜗牛。实际上，索引不是越多越好，而是要精准。我习惯先看慢查询日志，找出那些执行时间超过1秒的SQL，然后分析它们的WHERE条件、JOIN字段和ORDER BY字段。比如那次调电商库，发现订单表有个查询经常按userid和createtime组合过滤，但只建了userid的单列索引。改成复合索引(createtime, userid)后，查询直接走索引覆盖，不用回表，速度翻了好几倍。还有个技巧是，复合索引的字段顺序很关键，要把区分度高的字段放前面。比如性别字段区分度低，放前面等于白费；而订单状态字段区分度高，放前面能迅速缩小范围。
索引优化还藏着一个坑：索引失效。很多人建了索引，但查询还是慢，问题出在写法上。比如在WHERE条件里对索引字段做函数操作，像WHERE DATE(createtime)=‘2024-01-01’，索引就废了。改成WHERE createtime >= ‘2024-01-01’ AND createtime < ‘2024-01-02’，索引就能用上。还有LIKE查询用‘%关键词’这种前置通配符，索引也废。这些细节不注意，索引等于白建。我见过最夸张的案例，有人给字符串字段建了索引，但应用程序传参时用了整数类型，数据库隐式转换后索引又废了。所以索引优化不仅是建索引，还得保证查询能用上它。
第二个方案是查询重构，这比索引优化需要更多思考。很多人写SQL只求功能实现，不管性能。比如查用户最近一个月的订单，有人写成SELECT FROM orders WHERE userid=123 AND createtime > DATESUB(NOW(), INTERVAL 1 MONTH)，这种写法没问题，但如果你只关心订单数量和总金额，就不要SELECT ，只查COUNT(*)和SUM(amount)就行，减少数据传输量。更常见的坑是N+1查询，比如先查用户列表，再循环查每个用户的订单。改成一次JOIN或者子查询，性能提升明显。还有个大杀器是分页优化，很多人用LIMIT 100, 20这种写法，数据库得扫描十万行再丢掉，慢得要命。改成记录上次查询的ID，用WHERE id > 上次ID LIMIT 20，扫描量瞬间缩小。
查询重构还有一个高阶玩法：改写业务逻辑。有次遇到个统计需求，要算某个商品每天的销售额，原始查询用了GROUP BY DATE(createtime)，跑一次要30秒。我跟业务方聊了聊，发现他们其实只关心最近30天的数据，而且数据是按天批量写入的。于是改成每天凌晨跑个定时任务，把前一天的数据预聚合到一张汇总表，查询时直接查汇总表，速度从30秒降到0.01秒。这种从业务层面优化，比任何技术手段都管用。做查询重构时，多问问自己：用户真的需要这些数据吗？能不能换个角度查？
第三个方案是硬件配置，最容易被忽视。很多人觉得数据库慢就是代码问题，其实硬件瓶颈也很常见。比如机械硬盘的随机读写速度大概只有几十MB/s，而SSD能到几百甚至上千MB/s。那天调电商库时，我看了眼服务器的磁盘IO，发现等待时间很高，一问才知道用的是老式机械盘。换成NVMe SSD后，同样的查询快了3倍。内存也很关键，如果数据库的缓存池太小，频繁的磁盘读写会拖死性能。MySQL的innodbbufferpoolsize应该设为可用内存的70%左右，很多人设成默认的128MB，活该慢。还有个硬件优化是网络，如果数据库和应用服务器之间延迟高，查询再快也没用。建议把数据库和应用服务器放在同一个机房或云服务的同可用区，延迟能降到1ms以内。
硬件配置这块还有个容易踩的坑：配置参数。很多人买了高配服务器，但数据库配置没跟上。比如MySQL的maxconnections默认是151，如果并发高，连接数不够就会排队。但也不能设太大，否则内存爆了。合理的做法是监控实际连接数，再根据服务器内存调整。还有tmptablesize和maxheaptable_size，如果查询需要创建临时表，这两个值设小了会频繁用磁盘临时表，速度慢10倍。这些参数调优，往往花几分钟改个数字，效果比写半天代码都明显。
这三个方案不是孤立的，得配合着用。比如先通过索引优化把查询时间降到1秒，再通过查询重构降到0.2秒，用硬件配置把0.2秒压到0.05秒。但顺序很重要，先做索引和查询优化，因为成本低、见效快，再考虑升级硬件。我做项目时会先看慢查询日志，找出TOP10的慢SQL，针对性地建索引或改写法。如果优化后还有瓶颈，再查磁盘IO、内存使用率和CPU负载，判断是哪个部件拖后腿。比如CPU负载高，可能是查询没走索引导致全表扫描；磁盘IO高，可能是缓存池太小或用了机械盘。
说个真实案例。去年有个金融客户，他们的风控查询接口平均耗时12秒，客户投诉不断。我过去一看，问题一大堆：索引混乱，有个表建了20个索引但一半用不上；查询写得像裹脚布，一个SQL嵌套了5层子查询；服务器还是老旧的SATA盘。我花了两周时间，先清理冗余索引，给高频查询建复合索引，然后重写了几个核心查询，把嵌套子查询改成JOIN，说服他们升级到SSD。优化后，同一个接口的平均耗时降到0.8秒，整整快了15倍。客户后来开玩笑说，早知道这么简单，早该请你来。我笑了笑说，数据库优化就像看病，得对症下药，但前提是你得知道病在哪。
所以，如果你正在被数据库慢查询折磨，别慌。先抓慢查询日志，找出最慢的那几个SQL，看看索引是不是没建对或者没用到。再看看查询本身能不能简化，比如减少返回字段、避免N+1查询、用预聚合替代实时计算。检查下硬件，该加内存加内存，该换SSD。这三个方案走一遍，查询速度飙升10倍不是梦。当然，优化是个持续的过程，业务量上去了，又会有新的慢查询冒出来。但掌握了这三个方向，你就有了对症下药的底气。
