上周帮一个电商团队排查线上问题，他们的订单表才三百万行，一个简单的分页查询居然要两秒多。老板在群里发了个截图，客服那边已经炸锅了。我登录服务器看了一眼，CPU没满，内存没满，磁盘IO也没满，但数据库就是慢。发现罪魁祸首是一个没走索引的LIKE查询，每次请求都在扫全表。这事儿让我想起一个老生常谈的问题：大多数人优化数据库，第一步就搞错了方向。
他们上来就调参数，改配置，加缓存，换硬件，折腾一圈下来效果甚微。其实数据库优化的核心不是那些花哨的招数，而是最基础的原理理解。你今天看到的每一个慢查询，背后都对应着一条数据在磁盘上的物理位置，一个索引节点的组织结构，一段查询计划的选择逻辑。搞懂这些底层的运行机制，你才能像庖丁解牛一样，刀刀切中要害。
先说索引这个最基础也最容易被误解的东西。很多人以为索引就是给字段加个INDEX这么简单，其实索引的选择性才是关键。选择性指的是索引列中不同值的比例，这个比例越高，索引的过滤效果就越好。比如性别字段，只有男和女两种值，选择性就是2/总行数，这种索引加了等于白加，查询优化器根本不会用它。反过来，订单号这种每个值都不同的字段，选择性接近1，建索引的效果立竿见影。我见过太多人给状态字段、类型字段这种低选择性的列建索引，结果查询计划还是全表扫描，他们还在那纳闷为什么没效果。
索引还有个更深层的讲究，就是联合索引的字段顺序。数据库在构建联合索引时，是按照字段定义的先后顺序来组织B+树的。这意味着最左前缀原则不是一句空话，而是数据结构的必然结果。比如你建立了(a, b, c)的联合索引，那么查询条件只有b和c的情况下，这个索引完全帮不上忙。但如果你把顺序反过来了，建立(c, b, a)，同样的查询就能走索引。这个顺序怎么定？不是看哪个字段用得多，而是看哪个字段的区分度更高。区分度高的放前面，这样索引树在每一层都能砍掉更多的数据分支。很多人把查询频率作为排序依据，这是本末倒置。
说完索引，咱们聊聊查询语句本身。同样的业务需求，不同的SQL写法，性能可能差出十倍百倍。最常见的坑是SELECT ，这不仅仅是多传了几个字段的问题。数据库在执行查询时，如果使用了覆盖索引——也就是索引本身就包含了所有需要的字段——那么它根本不需要回表去取数据。但一旦你写了SELECT ，索引覆盖就失效了，每一行都要回表，磁盘IO翻倍甚至更多。我见过一个报表查询，把SELECT *改成只查需要的五个字段后，执行时间从800毫秒降到了120毫秒，就这一个改动，什么都没加。
还有子查询和JOIN的取舍，这里面的学问更大。MySQL的优化器在执行子查询时，有时候会把子查询转换成JOIN，有时候不会。当它不转换的时候，子查询就会变成逐行执行，相当于嵌套循环，每一行都触发一次子查询，那性能就完了。所以写SQL的时候，能明确改写成JOIN的就尽量改写成JOIN，别把选择权交给优化器。另外，JOIN本身也有讲究，小表驱动大表是基本原则，因为嵌套循环连接的外层循环次数等于小表的行数。你可以在EXPLAIN的输出里看到执行顺序，第一行往往是驱动表，确认它是小表就对了。
慢查询日志是另一个被严重低估的工具。很多人只在出问题的时候才去看一眼，其实它应该是一个持续监控的指标。把慢查询阈值设置成1秒，每天定时分析日志，你会发现很多隐藏的问题——某些报表在月初跑得特别慢，某些接口在促销活动期间突然变慢，某些查询在数据量增长到某个临界点后性能断崖式下跌。这些信号如果不通过日志捕捉，光靠用户投诉你根本反应不过来。我习惯每周写个脚本统计慢查询的次数和平均耗时，画成趋势图，哪个时间段异常了一眼就能看出来。
分库分表是很多团队走到后期才会面对的问题，但其实这个决策应该提前做。当单表数据量超过两千万行，或者单表容量超过20GB的时候，索引的维护成本会急剧上升，B+树的层级增加，每次查询的磁盘寻道次数变多。这时候再考虑分库分表，迁移成本已经很高了。更聪明的做法是在设计阶段就预留分片键，比如订单表用用户ID作为分片键，这样后续扩容的时候只需要迁移数据，不需要改业务代码。当然，分库分表会引入分布式事务、跨库查询这些新问题，所以能不分尽量不分，但必须在架构上留好后路。
说说缓存。很多人把缓存当成数据库性能问题的万能药，其实缓存只是把热点数据提前加载到内存里，减少数据库的读压力。但缓存有个致命的弱点——它无法处理写操作，也无法保证数据一致性。你缓存了用户的购物车数据，用户修改了购物车，缓存怎么办？删掉还是更新？删掉的话下次请求又得查数据库，更新的话又面临并发写冲突。所以缓存的正确用法是缓存那些低频变更、高频读取的数据，比如商品详情、配置信息、分类列表。那些频繁更新的数据，缓存反而成了累赘。
回到开头那个电商团队的案例，我帮他们改了三处：给订单表的用户ID和创建时间建了联合索引，把那个LIKE查询改成了前缀匹配，把分页查询的COUNT语句单独优化了一下。三处改动加起来不到半小时，查询时间从两秒多降到了两百毫秒以内。整个过程没有调任何数据库参数，没有加任何缓存，就是回归本质，搞清楚数据库是怎么工作的，然后在正确的层面做正确的优化。数据库优化的秘诀不在那些高深的配置项里，而在你对数据结构、查询计划、存储引擎这些基础原理的理解深度里。你越是深入底层，能做出的优化就越精准，效果也越持久。
