我跟你说，数据库调优这事，真不是玄学。做开发的谁没被慢查询折磨过？页面转圈、接口超时、老板盯着你，那滋味比吃苍蝇还难受。很多人一说调优，就想着加索引、换硬件，但实际干过的人都知道，技巧用对了，不用砸钱也能让查询快得像坐火箭。
第一个技巧，别让索引白建了。很多人以为建了索引就万事大吉，结果执行计划一看，全表扫描。为什么？索引失效了。最常见的情况是对索引列做函数操作，比如 ，这直接把索引废了。正确写法是 。还有模糊查询， 和 天差地别，前者索引失效。记住，索引适用于精确匹配和范围查询，不是给函数和通配符玩的。我见过一个项目把时间戳字段存成字符串，查询时用 截取比较，慢得能睡一觉。改成时间类型并加索引后，速度直接起飞。
第二个技巧，别让数据库干它不擅长的事。比如排序， 如果没走索引，数据库就得把数据全捞出来再排序，这叫 filesort。数据量大、内存不够时会写磁盘，慢成狗。解决办法很简单：排序字段要建索引，且排序顺序要和索引一致。分页也是坑， 这种写法，数据库必须先找到第 100 条再取 20 条，前面 10 万条都白查了。优化思路是使用覆盖索引加子查询，先查主键再关联原表，或者用游标分页。我帮一个电商系统调过，他们的订单分页从 8 秒降到 0.2 秒，用户再也不骂娘了。
第三个技巧，用好覆盖索引。什么是覆盖索引？就是查询需要的所有字段都在索引里，数据库不需要回表查数据。比如表中有 ，经常按 查询 和 ，可以建联合索引 ，查询时直接在索引树上拿到所有数据，IO 次数大幅下降。我见过一个报表系统，查询字段十几个，却只建了主键索引，导致每次都全表扫描加回表。改为按常用查询组合建覆盖索引后，查询时间从 30 秒降到 3 秒。这招特别适合查询频繁、更新少的场景。
第四个技巧，别让数据量成为负担。很多表几年不清理，几百上千万条数据堆在那儿，但业务上可能只用最近三个月的数据。这时分区表就派上用场了。按时间分区后，查询时只会扫描相关分区。比如订单表按月份分区，查询上个月的数据，数据库只扫一个分区，速度快几十倍。还有一种做法是归档旧数据，把不常用的历史记录移到归档表或冷存储。我帮一个金融系统做过，交易记录表原本 5 亿条，查询慢得要死。按季度分区并归档后，查询时间从分钟级降到秒级。
第五个技巧，别让连接查询变成噩梦。多表 是性能杀手，尤其是大表关联小表。优化原则是：小表驱动大表，先过滤再关联。比如 ，应该先查出活跃用户，再关联订单。关联字段一定要有索引，而且类型要一致。我见过 与 关联的，隐式类型转换导致索引失效，速度惨不忍睹。还有一个技巧是用 代替 ， 改成 ，对大数据集效果明显。
第六个技巧，别让数据库做重复劳动。相同查询在短时间内执行多次时，可以复用结果。缓存是最直接的方式，使用 Redis 或 Memcached 把热门查询结果缓存起来，设置合适的过期时间。但要注意不要缓存过于复杂的数据，更新时要处理好缓存失效。另一个办法是物化视图，把复杂查询结果存成一张表，定期刷新，适用于数据变更不频繁但查询很重的场景。我帮一个数据分析平台做过，他们的每日报表查询原本要跑 20 分钟，改为物化视图后，用户点一下就能看到结果，体验直接拉满。
第七个技巧，别让日志拖垮你。很多人忽略了日志对性能的影响。MySQL 的 binlog、redo log、undo log 如果配置不当，写日志的 I/O 压力会很大。尤其是 binlog， 会在每次事务提交时强制刷盘，性能会下降很多。对非关键数据可以改为 或使用组提交。慢查询日志平时开启会消耗性能，建议只在排查问题时打开。我见过一个系统因为慢查询日志文件太大，磁盘满了导致数据库挂掉，所以日志要定期轮转、压缩、清理。
第八个技巧，别让配置裸奔。默认配置适合开发环境，生产环境必须调优。比如 决定 InnoDB 能使用的内存，建议设为物理内存的 70%‑80%。太小会导致频繁磁盘读取，太大则可能触发 OOM。 默认 151，业务并发高时需要调大，但不要超过 2000，否则内存会爆。还有 与 ，临时表超过这个大小会写磁盘，速度会慢到怀疑人生。我调过一台服务器，把这两个参数从默认的 16M 调到 256M，复杂查询速度提升了一倍。
第九个技巧，别让 SQL 写得像傻子。很多人写 SQL 不讲究，比如 把所有字段都查出来，浪费带宽和内存。应该只查询需要的字段。 与 也要分清场景，能用 过滤的就别用 ，因为 在分组前过滤， 在分组后过滤。嵌套子查询也要慎用，能拆成多个简单查询的就别写成一个复杂查询，有时拆开后利用临时表反而更快。我见过一个 SQL 包含三层子查询，执行计划像迷宫，拆成两步后，速度从 15 秒降到 2 秒。
第十个技巧，别让监控成为摆设。调优不是一次性的，数据库会随数据增长和业务变化而变慢，所以必须建立监控体系。用 分析慢查询的执行计划，查看是否出现全表扫描、filesort、临时表等问题；用 观察当前执行的查询，是否有长时间锁等待；利用 和 库进一步定位瓶颈。我建议每个 DBA 和开发都养成定期查看慢查询日志的习惯，把执行时间超过 100 毫秒的 SQL 抓出来优化。一个团队每天查看慢查询日志，发现一条就优化一条，半年后系统的平均查询时间从 500 毫秒降到 50 毫秒。
说到底，数据库调优是一场和时间的博弈。每优化一点，数据库就快一点。但别指望一招吃遍天，不同场景要用不同技巧。索引用好了，查询快如闪电；连接写对了，数据秒级响应；缓存搭好了，用户爽到飞起。这十个技巧，你拿去试试，别光看，动手干一干，就能体会到什么叫“查询速度提升十倍”。记住，慢查询不是数据库的错，而是我们还没找到最优的道路。
