MySQL百万级高并发网站实战攻略，是选择性能优化还是架构升级？

在面对MySQL百万级高并发网站时，大多数情况下，应该先进行性能优化，再考虑架构升级，因为优化成本低且能解决80%的常见问题；只有当优化触及极限时，才需要架构升级。

第一步：简单检查与快速优化

当网站开始变慢，先别急着改架构。打开MySQL的慢查询日志，看看哪些SQL语句执行时间太长。通常，问题就出在几条常用的查询上。比如，一个没有索引的查询，在数据量大的时候会全表扫描，慢得像蜗牛。加上合适的索引，速度可能提升几十倍。另外，检查一下数据库连接是否太多，连接池设置是否合理。有时候，调整一下连接池的最大连接数，就能缓解并发压力。

第二步：深入优化数据库设计

如果加索引还不够，就得看看表结构了。大表要不要拆分？比如，把一些不常用的字段移到另一张表，或者把历史数据归档。还有，字段类型选对了吗？用INT存IP地址比用VARCHAR高效得多。查询语句也要优化，避免SELECT *，只取需要的字段；多用JOIN，少用子查询。这些调整不需要动架构，但效果往往很明显。

第三步：利用缓存减少数据库压力

高并发下，数据库最怕重复读相同数据。这时候，缓存是救星。可以用Redis或Memcached把热点数据存起来，比如用户信息、商品详情。这样，大部分读请求直接走缓存，数据库压力骤减。写缓存时注意一致性，设置合理的过期时间。缓存策略得当，数据库扛住百万并发也不是不可能。

第四步：读写分离分摊负载

当读请求远多于写请求时，读写分离是个好办法。主库负责写，从库负责读，这样读的压力就被分散了。架构改动不大，加几个从库，用中间件或者代码控制一下读写路由就行。但要注意主从同步延迟问题，对于实时性要求高的数据，还是得查主库。

第五步：垂直拆分与水平拆分

如果以上都做了，数据库还是瓶颈，那就得考虑拆分了。垂直拆分是按业务把表分到不同数据库，比如用户库、订单库。水平拆分是把一张表的数据按某种规则分到多个库，比如按用户ID取模。拆分后，并发能力能大幅提升，但代价是复杂度增加，跨库查询变得麻烦。

第六步：架构升级的终极选择

当单机MySQL无论如何优化都撑不住时，才需要架构升级。比如，引入分布式数据库，或者换用NewSQL。但这意味着重写大量代码，运维成本也高。所以，除非业务增长迅猛，否则优先优化。毕竟，很多网站用优化后的MySQL就能支撑百万级并发。

FAQ

问：什么时候必须选择架构升级而不是性能优化？
答：当性能优化已无法满足业务增长，比如数据量超过单机极限，或并发连接数达到硬件瓶颈，且读写分离、分库分表仍不足时，就需要架构升级。

问：缓存会导致数据不一致吗？如何解决？
答：会的。可以通过设置较短的过期时间、更新数据库时同步删除缓存，或使用消息队列异步更新缓存来缓解。

问：读写分离中，主从延迟如何处理？
答：对于实时性要求高的操作，直接读主库；或使用半同步复制减少延迟；也可以监控延迟，动态切换读库。

引用来源

本文内容基于MySQL官方文档、高并发架构实战案例（如Stack Overflow、淘宝早期架构）及常见运维经验总结。