说到MySQL数据库优化，这真是个既老生常谈又常谈常新的话题。我自己在维护一个日活10万+的社区网站时，就深刻体会到：数据库优化不是一蹴而就的魔法，而是一个需要持续观察和调整的过程。每当业务量增长20%，我就得重新审视那些SQL查询语句，看看有没有新的性能瓶颈冒出来。
索引优化：别让你的数据库”瞎找”
记得有一次网站突然变慢，查了半天发现是个简单的用户查询居然要5秒！打开执行计划一看——全表扫描。给user_name字段加了索引后，查询时间直接降到0.01秒。但索引也不是越多越好，我曾经犯过给所有字段都建索引的蠢事，结果写入性能暴跌。后来学乖了，只对高频查询条件和JOIN字段建索引。
SQL语句：别让数据库做”数学题”
见过最离谱的SQL是把计算放在WHERE条件里，比如WHERE price*0.8 > 100，这导致每次查询都要做全表计算。改成WHERE price > 125后性能提升了8倍！还有那些SELECT *的写法，明明只需要3个字段却把所有列都查出来，这不是在浪费带宽和内存吗？
刚开始我完全忽略了连接池配置，直到某天晚高峰数据库连接数爆满。调整了max_connections参数后，还把wait_timeout从默认的8小时降到10分钟。你猜怎么着？连接泄漏问题少了一大半。不过要注意，这些值不是越大越好，要根据服务器内存和实际并发量来定。
分表分库：当单表突破千万行
我们的用户日志表去年突破了2000万行，查询变得特别吃力。按月份分表后，单表控制在300万行左右，查询速度又回到了可接受范围。但分表带来新的问题——跨表查询变复杂了。这时候就要权衡利弊，有时候宁愿多做几次简单查询，也好过一次复杂的多表JOIN。
数据库优化真的是一门平衡的艺术。每次调整都要观察业务指标，比如我发现把innodb_buffer_pool_size从1GB调到4GB后，虽然查询快了，但系统整体内存使用率高了15%。所以现在我更倾向于先优化SQL和索引，实在不行才考虑硬件升级。你们在优化MySQL时都遇到过哪些有意思的问题？
评论(11)
索引优化这块真的说到点子上了，之前我们项目也是全表扫描导致性能问题，加了索引立马见效！
WHERE price*0.8 > 100 这个例子太真实了，新手程序员经常犯这种错误😂
想问下作者，分表分库后跨表查询有什么好的解决方案吗？我们最近也在考虑分表。
连接池配置这块太有共鸣了！之前我们线上事故就是因为连接泄漏，调低wait_timeout后问题少了很多。
作为一个DBA，看到SELECT *就想打人，这种写法真的太浪费资源了！
学到了！原来innodb_buffer_pool_size调大也会有副作用，之前一直以为越大越好呢。
数据库优化真的是个无底洞啊，每次以为调好了，业务量一上来又得重新优化🤦♂️
作者提到的平衡艺术很到位，我们领导就老想着靠堆硬件解决问题，其实很多性能问题都是SQL写得不好。
想问下日活10万+的社区，你们用的是什么规格的服务器啊？我们最近也在扩容。
最搞笑的是我们有个开发给布尔字段也建索引，还说’有备无患’，结果被DBA骂惨了哈哈哈
感谢分享！收藏了，正好最近在准备数据库优化的分享，这些案例太实用了👍