你是不是也遇到过这种情况：一个SQL查询跑了几十秒，老板站在背后盯着屏幕，你手心冒汗，心里只有一个念头——快！快！快！数据库慢得像蜗牛，谁都受不了。别急，这事儿有解。我用过不少数据库优化手段，今天聊五个实战方法，不扯玄学，直接上干货，保证让你的查询速度翻倍。别觉得数据库优化是DBA的专利，你一个开发或者运维，掌握这些技巧，也能让数据库跑得飞起。
第一招：索引，索引，还是索引。很多人以为建索引就是随便加几个字段，结果索引建了一大堆，查询还是慢。问题出在哪儿？索引不是越多越好，关键是要建对地方。比如，你有个用户表，经常按“注册时间”查，那就在注册时间上建个索引。但如果你查的是“状态”和“城市”组合，那就得建联合索引。联合索引有个讲究：最左前缀原则。也就是说，索引的顺序要跟你查询的条件一致。举个例子，建了(状态, 城市)的联合索引，查询时如果只按城市查，索引就废了。我见过一个线上案例，公司订单表每天几百万数据，查询卡得不行。DBA一看，表上有个单列索引，但查询条件里用的两个字段都没覆盖。加了个联合索引，查询时间从3秒降到0.1秒，效果立竿见影。所以，别偷懒，仔细看你的慢查询日志，分析哪些字段是高频查询条件，然后针对性地建索引。记住，索引是数据库的“目录”，目录不对，翻书当然慢。
第二招：合理设计表结构，别让数据“横向膨胀”。很多人建表时，习惯把能想到的字段全塞进去，一个表动辄上百个字段。你想想，每次查询都要读这么多字段，能不慢吗？尤其是那些大字段，比如text或者blob，每次扫描都得读大块数据，磁盘I/O直接炸裂。优化思路很简单：垂直拆分。把频繁查询的字段和很少查询的字段分开，建两个表。比如，文章表里，标题、发布时间这类频繁用的字段放主表，正文这种大字段放到扩展表，查询时只联表取需要的。还有一个常见的坑：字段类型选得不对。比如，存手机号用varchar(11)就够了，有人偏用bigint，结果查询时类型转换，索引失效。再比如，用datetime存时间戳，字段长度比int大，索引也慢。所以，设计表时，字段类型要精打细算，别图省事。我优化过一个用户日志表，原来字段全是varchar(255)，改成了合适的int和datetime后，查询速度快了一倍。别小看这些细节，积少成多，效果惊人。
第三招：用好查询缓存和连接池。很多人以为数据库优化只在SQL层面，其实架构层面也有大文章。比如，查询缓存。如果你的业务是读多写少，比如博客、新闻网站，查询缓存能直接把SQL结果存到内存里，下次同样的查询直接返回，速度飞起。MySQL的querycache虽然争议不少，但在特定场景下很好用。不过要注意，缓存失效太频繁反而会拖慢性能，所以你得评估业务特点。另一个是连接池。每次连接数据库都要创建TCP连接、身份验证，开销很大。用连接池，比如HikariCP或者Druid，可以复用连接，减少开销。我优化过一个电商后台，原来每次请求都新建数据库连接，响应时间在500毫秒左右。换了连接池后，降到50毫秒，用户体验直接提升。但连接池不是越大越好，设置太大反而会拖垮数据库。一般建议根据并发数调整，比如每秒请求100次，连接池设20-30个就够了。
第四招：优化SQL语句，别让数据库“做无用功”。很多人写SQL时，图省事直接select *，结果字段一多，数据库得读一堆不需要的数据。正确的做法是只查你需要的字段。比如，你只需要用户ID和姓名，就写select id, name from users，别用星号。再比如，用EXISTS替代IN。IN子查询会把子表结果全查出来，再跟主表匹配，而EXISTS只要查到一条就返回，效率高得多。还有一个经典问题：避免在WHERE条件里用函数。比如，WHERE DATE(createtime) = '2023-01-01'，这样会导致索引失效，改成createtime >= '2023-01-01' AND createtime < '2023-01-02'，索引就能用了。我调优过一个统计报表，原来SQL里嵌套了好几层子查询，跑一次要30秒。改成JOIN和聚合函数后，只用了2秒。写SQL时，多想想数据库是怎么执行你的语句的，减少不必要的扫描和计算，性能自然就上来了。
第五招：利用分区表和读写分离。当单表数据量超过千万级别时，索引优化已经不够用了，你需要更“硬核”的手段。分区表就是把一个大表拆成多个物理分区，比如按时间分区，每个月一个分区。查询时，数据库只扫描相关分区，而不是全表。比如，你有个日志表，每天新增100万数据，按天分区后，查询某一天的数据，扫描量从几亿降到几百万，速度翻倍不是问题。另一个是读写分离。主库负责写，从库负责读，把压力分散。比如，用户注册写入主库，浏览商品从从库读。这样主库不用被读请求拖累，写入速度也能提升。我参与过一个电商平台优化，订单表数据量上亿，读写分离后，读查询响应时间从5秒降到0.5秒。但注意，分区表要提前规划好分区键，读写分离要注意数据延迟问题，别让用户看到过时数据。
这五个方法用下来，数据库性能基本能翻倍。但别忘了，优化不是一劳永逸的。业务在变，数据量在涨，你得定期监控慢查询、分析索引命中率、调整配置参数。比如，用Performance Schema或者慢查询日志工具，找出那些“拖后腿”的SQL，然后对症下药。另外，别盲目追求极致性能，数据库优化要跟业务需求匹配。比如，一个后台报表系统，允许几秒延迟，就没必要花大功夫优化到毫秒级。说到底，数据库优化是门手艺活，需要你持续学习和实践。下次再遇到慢查询，别慌，拿出这五个方法，一个个试，总有一个能帮你解决问题。你的查询速度快了，老板开心了，你也轻松了，何乐而不为？
