MySQL除了连接压缩，还有哪些实用提速技巧？

背景很多同学在遇到慢查询、数据库网络传输大的场景时第一反应就是开启MySQL连接压缩。但实际项目踩坑后会发现连接压缩只是“网络带宽层面”的优化CPU开销会增加并且很多Python驱动如原生pymysql并不支持它只是众多优化手段里很小的一环。真正提升数据库整体响应速度要从SQL、索引、表结构、缓存、架构、运维多维度入手。一、先搞清楚连接压缩的适用边界快速回顾MySQL的COMPRESS连接压缩本质是客户端和服务端之间传输的网络数据包做zlib压缩。✅ 适合跨机房、公网传输、返回大文本爬虫入库、大字段content、长文本查询带宽瓶颈场景❌ 不适合内网高带宽、小查询、CPU资源紧张服务器压缩解压会消耗服务端客户端CPU小数据量反而变慢。一句话总结连接压缩解决的是网络慢不能解决SQL本身执行慢。下面才是项目里高频见效的优化方案。二、SQL语句层面优化收益最高优先做1. 避免SELECT *只查需要字段很多爬虫、后端代码习惯写select * from table。会读取大量无用字段增加磁盘IO、网络流量大TEXT、VARCHAR字段影响尤其明显覆盖索引失效无法走索引优化-- 不推荐SELECT*FROMinformation_listWHEREid1000;-- 推荐只拿业务需要列SELECTid,title,publish_timeFROMinformation_listWHEREid1000;2. 合理分页杜绝大offset分页offset 100000 limit 10数据库需要扫描并丢弃前面10万行越往后越慢。优化方案主键书签分页-- 低效写法selectid,titlefrominfoorderbyidlimit100000,10;-- 高效书签分页下一页基于上一页最大idselectid,titlefrominfowhereid100000orderbyidlimit10;3. 禁止隐式类型转换where str_column 123字符串字段和数字对比会导致索引失效全表扫描。两边类型保持一致是很容易忽略的坑。4. 减少join数量尽量少用子查询多表JOIN在数据量大时成本很高尽量把子查询改成JOIN或者拆成多次简单查询应用层做数据合并。同时避免NOT IN大数据集优先NOT EXISTS或者左连接判断null。5. 慎用like ‘%关键词’前置百分号无法使用索引如果需要全文检索不要强行用like改用MySQL全文索引或者Elasticsearch。三、索引优化数据库优化核心联合索引最左前缀原则联合索引idx_a_b_c(a,b,c)查询条件必须带上最左侧字段a才能命中索引顺序要贴合业务查询条件。不要盲目建索引索引会提升查询、降低写入insert/update/delete性能每张表索引不宜过多。覆盖索引查询字段全部包含在索引内直接从索引返回数据不需要回表查询主键减少磁盘IO。避免索引失效场景索引列做函数运算where DATE(create_time)2026-09-24索引列使用 ! 、is not nullorder by/group by字段没有加到索引里出现filesort文件排序主键选型优先自增整数主键不要用UUID、字符串当主键。随机UUID会造成索引页分裂插入性能暴跌。四、表结构设计优化前期设计决定上限字段类型尽量小能用INT不要BIGINT短字符串用VARCHAR固定短文本用CHAR大文本内容爬虫正文content单独拆到附属内容表主表只存标题、时间等基础字段减少主表行大小。爬虫项目特别适用新闻正文单独一张content表主表只存摘要列表查询不读取大文本。拆分冷热数据大表分区历史归档数据往年新闻、过期日志按时间范围做表分区range分区查询自动只扫描对应分区不用扫全表。旧数据可以归档到归档表业务表只保留最近热数据。尽量避免NULLNULL会增加索引复杂度查询容易出现预期外结果优先用默认值代替。五、缓存层优化减少MySQL查询次数数据库最大的提速是不去查询数据库。Redis缓存热点数据高频查询的列表、详情页查询结果存入Redis设置合理过期时间直接拦截请求不打到MySQL。适合场景网站新闻列表、基础配置、基础字典。注意缓存更新策略更新数据库后同步更新/删除缓存避免脏数据。查询结果本地缓存后端服务内存缓存lru缓存短时间重复请求直接内存返回减少redis和mysql压力。六、MySQL配置参数调优my.cnf/my.ini注意参数调优需要结合服务器内存不要盲目抄网上模板innodb_buffer_pool_size最重要参数InnoDB把热点数据放在内存服务器专用MySQL推荐设置物理内存50%~70%。这是对查询速度提升最明显的参数远比连接压缩收益大。innodb_flush_log_at_trx_commit1每次事务刷盘最安全性能低默认2每秒刷一次日志性能更高断电可能丢失1s数据适合爬虫、非金融可容忍少量丢失场景max_connections不要设置过大连接数太多会耗尽内存一般几百足够配合连接池使用。关闭不必要日志生产环境不要长期开启通用查询日志general_log慢查询日志slow_query_log建议开启用来抓慢SQL。七、应用层 连接池优化后端开发重点很多后端项目慢不是MySQL慢是连接管理不合理。必须使用数据库连接池Python项目DBUtils、sqlalchemy连接池。不要每次查询新建连接、用完销毁连接创建销毁开销很高。注意连接池不要设置过大防止瞬间打爆数据库max_connections。批量操作代替循环单条insert爬虫入库最常见坑循环一条一条insert网络来回次数爆炸。改用INSERT INTO table values (),(),()批量插入或者LOAD DATA导入。读写分离读多写少业务主库负责写入多个从库承担查询。后端代码做路由select查询走从库写操作走主库。八、架构层面超过MySQL适合范围就换方案当单表千万、上亿大量全文检索场景MySQL吃力海量文本检索ES替代MySQL like查询时序日志、监控数据influxdb/clickhouse超大报表统计分析单独数据仓库不要在线业务库做统计聚合九、优化优先级总结工程落地顺序找出慢SQLexplain分析执行计划第一位索引优化、调整SQL写法表结构冷热拆分、大字段剥离增加Redis缓存拦截热点查询调整InnoDB核心参数读写分离/分表分库跨机房场景最后考虑开启连接压缩连接压缩只是解决网络传输大小的小优化放在优化清单的末尾。如果SQL本身全表扫描就算开了连接压缩速度依旧很慢。十、项目踩坑小结爬虫后端场景我们爬虫项目早期也想靠开启连接压缩提升入库速度压测后发现内网环境开启压缩CPU上涨明显速度几乎没有提升。后续优化通过大文本分表、批量insert、增加索引、Redis缓存列表整体吞吐量提升数倍。核心结论不要把连接压缩当成MySQL提速银弹优先优化SQL和索引。