我见过太多人栽在数据库查询上。代码写得好好的，功能也正常，可一到数据量上来，那查询速度慢得让人怀疑人生。你盯着那个转圈的加载图标，心里默念“快点快点”，它偏要跟你作对，一跑就是十几秒。其实问题往往不在数据库本身，而是你压根没搞明白它怎么工作的。
先说最基础也最容易被忽略的——索引。很多人建表的时候图省事，主键有了就算完，其他字段裸奔。等查询的时候，数据库得把整张表从头到尾扫一遍，就像你在一个没有目录的图书馆里找一本书，只能一本一本翻。那速度能快吗？我给一个电商项目做优化的时候，订单表才五十万行，一个普通的按用户ID查订单的语句跑了快三秒。加了个联合索引，直接降到几十毫秒。差距就是这么夸张。
但索引也不是越多越好。我见过一个开发兄弟，恨不得把每个字段都加上索引，结果写入的时候慢得跟蜗牛似的。索引是要占空间的，而且每次插入、更新、删除，数据库都得同步维护索引，等于你每写一条数据都要额外干一堆活。所以加索引要讲究策略，你要盯着那些WHERE、JOIN、ORDER BY后面经常出现的字段来加，而不是拍脑袋乱来。
说完索引，再说说查询语句本身。很多人写SQL那叫一个随性，SELECT * 用得飞起，明明只需要三个字段，非要把整行的数据都捞出来。数据量小的时候感觉不到，一旦数据量大，多传输的那些字段就是白花花的资源消耗。还有人在WHERE里面用函数，比如WHERE DATE(createtime) = '2024-01-01'，这么一写，索引直接失效，因为数据库没法对函数处理过的字段用索引。你改成范围查询，效果立竿见影。
再就是分页问题。你有没有遇到过这种情况：数据量上百万，点击第500页的时候，页面卡得动弹不得？那是因为你用的是LIMIT 500, 20，数据库得先数出前500条再扔掉，这操作本身就慢。我一般建议用游标或者基于上次查询的一条记录的ID来做分页，这样数据库只需要扫描那20条就行，速度完全不一样。
还有个坑，很多新手会踩——N+1查询。比如你先查出100个用户的列表，然后循环里再挨个查每个用户的订单，这等于执行了101条查询。每条查询都有网络开销、解析开销、执行开销，加起来就慢得离谱。正确做法是用JOIN或者IN一次性把数据捞出来，一条SQL搞定。我曾经优化过一个后台报表，原来跑一次要8秒，改成JOIN之后直接变成0.2秒，客户当场愣住。
说到JOIN，这里头也有讲究。两张表关联的时候，最好是让驱动表（也就是外层循环的那个）尽量小，这样循环次数少。还有，关联字段的类型要一致，不然索引又废了。我有一次排查一个慢查询，发现两边的关联字段一个是INT一个是VARCHAR，数据库傻乎乎地把所有INT转成VARCHAR再比较，全表扫描，那叫一个惨烈。改了类型之后，查询时间从6秒降到0.1秒。
你要是觉得这些还不够，再往深了说，就要看看你的表结构设计了。有些表设计得乱七八糟，字段冗余、重复存储，查询的时候自然要处理更多数据。比如你把用户的地址、电话、邮箱全存在订单表里，每次查订单都得把这些字段捞出来，数据量一大，IO开销就上去了。正确的做法是拆表，订单表只存用户ID，需要的时候再去关联用户表。
还有个容易被忽视的点——数据库配置。MySQL的缓冲池大小、连接数上限、临时表大小，这些参数你要是用的默认值，那性能天花板就摆在那儿。我见过一台服务器配置挺高，但缓冲池才128MB，数据一多就疯狂读写磁盘，速度当然上不去。把innodbbufferpoolsize调大，让更多数据留在内存里，查询速度能提升好几个量级。不过这个要谨慎调，得根据你服务器的物理内存来，别把内存吃光了导致系统崩溃。
再说一个实战中特别有效的招——慢查询日志。别嫌它烦，这是数据库自己告诉你的“哪里出了问题”。把慢查询日志打开，设置一个合理的阈值，比如1秒，然后定期去翻，看看哪些SQL经常上榜。我每次接手一个性能有问题的项目，第一件事就是开慢查询日志，跑个一天，拉出来看看，基本上问题就暴露得七七八八了。比你自己瞎猜要靠谱得多。
还有一点，别把数据库当成万能的计算器。有些复杂的统计、报表逻辑，你非要用一条SQL硬刚，结果SQL写得跟天书似的，跑起来还慢。不如拆开，先在数据库层面把基础数据查出来，然后在应用层做处理。这样虽然代码多几行，但每步都清晰，性能也容易控制。
回到开头说的那个“慢如蜗牛”的问题。其实绝大多数情况下，慢不是数据库的锅，是你没用对方法。索引建好、SQL写规范、表结构合理、配置调到位，这四步走完，你的查询速度基本上就告别蜗牛了。每次遇到慢查询，别急着骂数据库，先静下心来，按照这个思路排查一遍，你会发现，飞起来的感觉其实没那么难。
