高并发是大型架构核心，下面我详解MySQL为什么扛不住并发@mikechen
第一，磁盘I/O是天然瓶颈。
数据库最核心的操作是读写数据，而数据最终要落到磁盘。
相比内存，磁盘I/O速度慢得多，即使使用SSD，也依然难以和CPU、内存的处理速度匹配。
高并发场景下，很多请求会同时访问同一批数据页，导致缓冲池频繁命中或缺失。
一旦缓存未命中，就要触发磁盘读写，性能会明显下降。
尤其是写入场景，MySQL不仅要写数据页，还要处理日志刷盘、事务提交等操作，这些都会进一步放大I/O压力。因此，I/O能力不足是MySQL难以支撑超高并发的关键原因之一。
第二，锁机制会放大并发冲突。
为了保证数据一致性，MySQL必须使用各种锁机制，例如行锁、表锁、元数据锁以及事务相关锁。
问题在于，并发越高，冲突概率越大。
多个事务如果同时访问或修改同一资源，就可能发生锁等待，甚至锁竞争升级。
特别是在设计不合理的SQL、缺少合适索引、事务过长的情况下。
锁持有时间会被拉长，后续请求只能排队等待，最终形成性能雪崩。
换句话说，高并发不只是“请求多”，更是“冲突多”，而锁正是冲突被放大的直接体现。
第三：连接资源有限，线程竞争明显。
MySQL在处理客户端请求时，需要建立连接，并为每个连接分配一定的资源。
虽然现代版本已经做了大量优化，但当并发连接数过高时，连接管理、线程调度和上下文切换都会带来额外开销。
如果大量请求同时涌入，数据库需要频繁处理连接建立、释放以及线程切换。
CPU资源会被这些“管理成本”消耗掉，而不是全部用于真正的数据读写。
因此，高并发下最先暴露出来的，往往不是SQL本身，而是连接池、线程池和会话管理的瓶颈。
第四：单机架构的扩展能力有限。
MySQL虽然可以通过主从复制、读写分离、分库分表等方式提升承载能力，但其核心仍然是单实例处理能力有限。
对于绝大多数场景，单个MySQL实例只能在CPU、内存、磁盘和网络带宽的约束下运行。
随着业务增长，数据量和请求量持续上升，单机纵向扩容很快会碰到上限。
一旦达到瓶颈，系统就需要引入更复杂的架构设计，而这些方案本身又会带来一致性、运维和开发复杂度问题。
也就是说，MySQL并不是不能扩展，而是它的扩展方式不够“天然弹性”，难以像分布式系统那样平滑应对极端并发。