去年双十一，我有个朋友负责的电商平台突然崩了——用户点开商品详情页，转圈圈转得比电风扇还快。后台一查，数据库扛不住，每秒几万次的查询请求直接把服务器干趴了。那场面，比春运抢票还热闹。后来技术团队花了三天三夜，硬是把查询时间从5秒压到0.2秒。这事让我意识到，数据库查询优化不是锦上添花，而是生死攸关。今天咱们就聊聊这个技术活儿，不整那些玄乎的术语，就说人话。
先得搞清楚一个问题：数据库为啥会慢？说白了，就是数据太多，查起来费劲。好比你去图书馆找一本书，书架上有几十万册，没有索引，你就得一本本翻。数据库也一样，全表扫描是最笨的办法。优化的第一步，就是建索引。但索引不是越多越好，就像给书做标签，标签太多反而找起来麻烦。比如一个用户表，你经常按用户名查，那就在用户名上建索引；但如果按生日查，就得考虑是不是高频操作。我见过有人给每个字段都建索引，结果写入慢了10倍，更新数据比蜗牛还慢。所以索引要精，不能滥。
光有索引还不够，还得看查询语句怎么写。很多慢查询都是 SQL 写得烂。比如用 “SELECT ” 这种写法，等于告诉数据库：“把所有字段都给我搬过来。”如果一张表有 50 个字段，你只需要 3 个，那剩下的 47 个字段就是白搬。更坑的是，有时候连索引都用不上。比如在 WHERE 条件里写 “LIKE ‘%关键词%’”，这种模糊查询会让索引失效，数据库只能从头扫到尾。再比如函数操作，像 “WHERE YEAR(createtime)=2023”，索引也白搭。所以写 SQL 要有点洁癖，能用数字别用字符串，能用等号别用模糊匹配，能用具体字段别用星号。
有时候，SQL 写得好、索引也建了，但数据量太大，还是慢。这时候就得考虑分页。比如用户翻到第 100 页，传统做法是 “OFFSET 9900 LIMIT 100”，意思是跳过前 9900 条，再取 100 条。但数据库得先把这 9900 条都查出来，再扔掉，过程特别耗资源。优化方案是用 “游标分页” 或者 “键集分页”。比如按 ID 排序，取第 100 页时，直接查 “WHERE id > 9900 LIMIT 100”，这样数据库就不用白干活。我记得有个新闻网站，做了这个改动后，分页查询从 2 秒降到 0.01 秒，用户体验直接升天。
再往深了说，数据库本身也有瓶颈。单机数据库再牛，也扛不住海量并发。这时候就得用读写分离或分库分表。读写分离好理解，主库负责写，从库负责读，像双职工家庭，各司其职。分库分表更狠，把一张大表拆成几十张小表，按用户 ID 或时间范围分。比如订单表，按月份拆，查 1 月的订单就去 1 月那张表，查 2 月就去 2 月那张，不用全表扫。但分库分表也有代价，跨表查询和事务处理会变得复杂，就像分家后还得串门，沟通成本高了。所以要根据业务场景决定，并非所有情况都适合拆。
缓存也是个好办法。很多查询其实重复率很高，比如商品详情页，10 万个用户看的可能是同一个爆款。每次都去数据库查，纯属浪费。用 Redis 或 Memcached 把热点数据缓存起来，命中率高的场景能扛住 90% 的请求。我朋友那家电商平台，双十一前把热门商品的缓存提前预热，数据库压力直接降了 80%。但缓存也有坑，比如数据一致性问题。用户改了商品价格，缓存没更新，用户还看到旧价格，那就得骂娘了。所以要设置合理的过期时间，或者用消息队列主动刷新缓存。
还有一个容易被忽略的点：连接池。数据库的连接数有限，就像餐馆的座位有限。高峰期几百个请求同时来，每个请求都要建立连接，数据库会直接卡死。连接池的作用就是提前建好一堆连接，请求来了直接复用，省去建立和销毁连接的开销。我见过初创公司代码里每次查询都 new 一个 Connection，结果数据库连接数飙到上限，直接报 “Too many connections”。调优后用了连接池，最大连接数从 200 降到 50，性能反而更稳。连接池参数也得调，比如最大空闲连接数、超时时间，这些细节决定了稳定性。
说个实战案例。有一次我帮一个物流公司优化查询，他们的运单表有 5000 万条记录，每天新增 10 万条。用户查运单状态时，经常按运单号、手机号、发货地址三个条件组合查询。原始 SQL 长这样：“SELECT FROM waybill WHERE waybillno LIKE '%123%' AND phone LIKE '%456%' AND sender_address LIKE '%上海%'”。三个模糊查询让索引全废，每次查询耗时 8 秒。我的优化方案是：把运单号和手机号改成精确匹配，用户输入时自动补全；发货地址单独存一个地址字典表，用 ID 关联，这样查询条件变成等值匹配。再加上联合索引，查询时间从 8 秒降到 0.03 秒。那个运维主管当场给我竖了个大拇指。
说到底，数据库查询优化不是一锤子买卖，而是一个持续迭代的过程。业务在变，数据量在涨，查询模式也在变。今天有效的优化方案，明天可能就失效。比如索引，随着数据分布变化，可能需要重建；缓存策略，随着热点转移，需要调整。所以别指望一次优化管一辈子。定期做慢查询日志分析，用 EXPLAIN 看执行计划，监控系统性能指标，这些都是基本功。优化这事儿，有点像练内功，没有捷径，但每次进步都能让系统喘口气。下次你的数据库慢得像蜗牛，别急着骂开发，先想想是不是索引没建对、SQL 写得烂，还是缓存没用好。毕竟，技术问题，总有解法。
