刚接手一个电商系统时，我发现订单查询页面慢得让人抓狂。点一下“查询”，咖啡都凉了，数据还没出来。老板在背后盯着，用户疯狂投诉，DBA群里炸了锅。查了一圈，发现罪魁祸首竟是那个看似无害的SQL——。这条查询跑全表扫描，两千万行数据硬生生被翻了个底朝天。当时我就意识到，数据库性能优化不是玄学，而是实打实的工程活。索引设计加SQL调优，这两把刀磨利了，慢查询就能变成闪电。
索引设计是性能优化的第一道防线，但很多人把它当成了万能药。加索引不是越多越好，也不是随便加个字段就完事。那次我遇到一个生产事故：开发同事为了优化查询，一口气在表上加了八个索引，结果写入性能暴跌，数据库CPU飙到99%。为什么？因为每个索引都是一棵B+树，写入时所有树都要更新，就像同时整理八副扑克牌，手速再快也撑不住。正确做法是，先分析查询模式。比如订单表，字段的区分度太低，只有几个值，建索引反而浪费；而这种唯一值多的字段，建索引才能让B+树快速定位。记住一个原则：索引不是给表贴标签，而是给数据建路标，路标太多，找路反而更慢。
复合索引的设计更考验功力，很多人栽在最左前缀法则上。有个金融系统的例子：和这两个字段经常一起查询，开发建了。结果发现，查询时，索引根本用不上。为什么？因为B+树先按排序，再按排序，你跳过第一列直接查第二列，索引就废了。正确的设计是，把区分度高的字段放前面，或者根据查询频率调整顺序。比如的查询次数是的三倍，那就建。还有个小技巧：可以用看字段，判断索引是否被完全使用。如果比预想短，说明索引只用了部分列，得调整顺序。
SQL调优实战中，最坑人的是隐式类型转换。我见过一个案例：是类型，查询写成了，没有加引号。MySQL自动把转成数字，导致索引失效，全表扫描。为什么？因为类型转换发生在索引列上，数据库只能把整列数据都转一遍，才能比较。类似的陷阱还有函数操作，比如，这个函数让索引白建了。正确写法是，范围查询才能用索引。这些细节看起来不起眼，但线上慢查询90%都是这种低级错误。
分页查询的优化也是个老大难问题。这种写法，数据库要扫描十万行数据，再扔掉前十万行，只拿二十行。这不是查询，是翻垃圾。有个招聘平台的例子：简历列表页每次翻到后面，响应时间从50毫秒飙升到5秒。怎么改？用，基于主键的覆盖索引，直接定位起始位置。但这个方案有坑，如果数据被删除过，不连续，结果会漏行。更稳妥的做法是用加条件，配合确认是否用了索引。还有一种情况是，，两个字段排序时，如果重复多，数据库会做文件排序，性能直接打骨折。这时候加个复合索引，就能避免。
JOIN操作在优化时经常被忽略，很多人以为加索引就完事。实际上，JOIN的顺序和驱动表选择才是关键。有个社交系统的案例：用户表和好友表做JOIN，，结果跑了三分钟。查了一下，表一亿行，表五千万行。优化思路是，用小表驱动大表，先查表里符合条件的用户（比如），再JOIN表。改写后变成，响应时间降到500毫秒。还有一点：条件字段必须建索引，否则数据库要做嵌套循环，每条数据都得全表扫描。
调优到往往发现瓶颈不在SQL本身，而在业务逻辑。有个物流系统的例子：查询在途包裹时，，三个状态就够用了。但业务方要求同时查近三十天的数据，范围太大，索引失效。跟产品经理聊了一下，发现用户只看最近三天的包裹，历史数据根本没人关心。把查询范围缩到三天后，性能直接起飞。很多时候，DBA被逼着调SQL，其实该调的是产品逻辑。数据量超过千万级后，索引和SQL能优化到极限，但业务不砍冗余需求，神仙也救不了。所以，性能优化不只是技术活，更是沟通活——敢跟业务方说“不”，敢砍掉伪需求。
回到开头那个订单查询，最终怎么解决的？我给和建了复合索引，去掉改成只查需要的字段，还把的比较改成了枚举值。优化后，查询从8秒降到30毫秒。那天晚上，我发了个朋友圈：“数据库优化的本质，是让数据少走路，让索引多干活。”有人点赞，有人问细节，但更多人吐槽：你们公司是不是没DBA？其实不是，只是每个DBA都在跟慢查询死磕。从索引设计到SQL调优，这条路没有捷径，只有一次次、一个个、一页页慢查询日志堆出来的经验。下次你的系统慢到让人崩溃时，别急着加机器，先把SQL捞出来，用这篇文章里的方法，一条一条改，你会看到奇迹发生。
