嘿，朋友，既然你点开了这篇内容，我就知道你不是来“随便问问”的。你正站在一个让无数后端工程师头秃的十字路口：MySQL 在高并发下崩了。
别慌，我不是来给你念教科书的。咱们来聊点真刀真枪的东西。想象一下，你的电商大促来了，订单量瞬间翻了100倍，数据库连接池爆了，主从同步延迟了几秒，查询慢得像蜗牛——这时候，你该怎么办？
我会用我这些年踩过的坑、调优过的案例，带你一步步拆解MySQL高并发的完整解决方案。从连接池的细微配置，到读写分离的架构设计，再到分库分表的拆分策略，最后到索引和锁的底层优化。每一部分都有代码、有配置、有原理，保证你能直接落地。
咱们开始吧。
一、连接池配置：高并发的第一道防线
1.1 为什么连接池是重中之重？
很多开发者以为“高并发”就是加机器，但其实连接池配置不当往往是第一个瓶颈。每次新建数据库连接的成本很高（TCP三次握手、SSL握手、权限验证等），如果频繁创建销毁连接，数据库服务器会被这些握手包打爆。
我见过一个案例：某短视频APP在大促期间，QPS达到5000，但数据库连接池配置的是默认值（max_connections=151，wait_timeout=28800）。结果连接池瞬间打满，新请求全部排队等待，响应时间从50ms飙升到5秒。
1.2 HikariCP vs Druid vs C3P0：选哪个？
直接说结论：首选HikariCP。
根据2024-2025年的性能基准测试，HikariCP在连接获取速度上比Druid快约30%，比C3P0快60%。它的核心优势是：
- 极简的代码库，减少潜在的bug
- 高效的最小空闲连接维持算法
- 自动检测泄漏连接
- 对JDBC规范的严格遵循
但如果你需要详细的监控指标（SQL执行统计、连接池状态可视化），Druid也是个不错的选择。
1.3 HikariCP核心参数详解与调优策略
让我直接给你一套经过生产验证的配置模板，然后逐个参数拆解：
# application.yml 或 Spring Boot 配置
spring:
datasource:
hikari:
# 连接池名称，方便监控时识别
pool-name: main-pool
# 最小空闲连接数，建议设置为最大连接数的20%-30%
minimum-idle: 10
# 最大连接数，根据业务QPS和数据库负载调整
# 计算公式：max_connections = (CPU核心数 * 2) + 有效磁盘数
# 对于8核CPU + SSD的情况，建议设置为16-24
maximum-pool-size: 20
# 连接超时时间，单位毫秒。建议20-30秒
connection-timeout: 30000
# 空闲连接最大存活时间，建议比wait_timeout稍大
idle-timeout: 600000
# 连接最大生命周期，防止数据库端因长期连接而中断
max-lifetime: 1800000
# 测试查询，用于验证连接有效性
connection-test-query: SELECT 1
# 自动提交，建议在业务层控制事务
auto-commit: false
# 读写分离时，主库连接数占比（重要！）
# 设置30%的连接用于写操作，70%用于读操作
dataSourceProperties:
spring.datasource.driver-class-name: com.mysql.cj.jdbc.Driver
spring.datasource.url: jdbc:mysql://192.168.1.100:3306/ecommerce?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true
spring.datasource.username: dbuser
spring.datasource.password: dbpassword123
# 启用prepared statement缓存，提升性能
cachePrepStmts: true
prepStmtCacheSize: 250
prepStmtCacheSqlLimit: 2048
useServerPrepStmts: true
useLocalSessionState: true
rewriteBatchedStatements: true
cacheResultSetMetadata: true
cacheServerConfiguration: true
eliminateInPool: true
关键参数调优逻辑：
maximum-pool-size：这是最关键的参数。连接池不是越大越好。如果设置过大，会导致：- 数据库端连接数过多，上下文切换开销增大
- 连接竞争加剧，反而降低吞吐量
实测经验：对于SSD + 8核CPU + 32GB内存的MySQL服务器，maximum-pool-size设置在15-25之间性能最佳。超过30后，性能开始下降。
minimum-idlevsmaximum-pool-size：minimum-idle应该等于或略小于maximum-pool-size- 如果两者相等，连接池会始终保持最大连接数，避免动态扩容的开销
- 对于高并发场景，建议设置为：
minimum-idle = maximum-pool-size
connection-timeout：- 默认30秒，对于高并发场景可能太长
- 建议设置为10-15秒，避免请求长时间阻塞
- 配合应用层的超时熔断机制使用
max-lifetime：- 必须小于数据库的
wait_timeout（默认28800秒） - 建议设置为25-30分钟，定期回收连接，防止数据库端因长时间空闲而断开
- 必须小于数据库的
1.4 读写分离场景下的连接池配置
读写分离是提升读性能的核心手段。但很多团队在配置时犯了一个错误：读写连接池没有按比例分配。
假设你的业务是80%读、20%写，但你只配置了一个连接池，那么写操作可能会因为读连接占用太多资源而变慢。
正确的做法是配置两个独立的连接池：
@Configuration
public class DataSourceConfig {
// 主库连接池（用于写操作）
@Bean
@Primary
public DataSource masterDataSource() {
HikariConfig config = new HikariConfig();
config.setPoolName("master-pool");
config.setMaximumPoolSize(10);
config.setMinimumIdle(5);
config.setConnectionTimeout(30000);
config.setIdleTimeout(600000);
config.setMaxLifetime(1800000);
config.setJdbcUrl("jdbc:mysql://master:3306/ecommerce?useSSL=false&...");
config.addDataSourceProperty("cachePrepStmts", "true");
config.addDataSourceProperty("prepStmtCacheSize", "250");
config.addDataSourceProperty("rewriteBatchedStatements", "true");
return new HikariDataSource(config);
}
// 从库连接池（用于读操作）
@Bean
public DataSource slaveDataSource() {
HikariConfig config = new HikariConfig();
config.setPoolName("slave-pool");
config.setMaximumPoolSize(30); // 读多写少，从库连接池可以更大
config.setMinimumIdle(15);
config.setConnectionTimeout(30000);
config.setIdleTimeout(600000);
config.setMaxLifetime(1800000);
config.setJdbcUrl("jdbc:mysql://slave1:3306/ecommerce?useSSL=false&...");
config.addDataSourceProperty("cachePrepStmts", "true");
config.addDataSourceProperty("prepStmtCacheSize", "250");
return new HikariDataSource(config);
}
// 动态数据源切换
@Bean
public DynamicDataSource dynamicDataSource() {
Map<Object, Object> targetDataSources = new HashMap<>();
targetDataSources.put(DataSourceType.MASTER, masterDataSource());
targetDataSources.put(DataSourceType.SLAVE, slaveDataSource());
DynamicDataSource dataSource = new DynamicDataSource();
dataSource.setTargetDataSources(targetDataSources);
dataSource.setDefaultTargetDataSource(masterDataSource());
return dataSource;
}
}
动态数据源切换的核心实现：
public class DynamicDataSource extends AbstractRoutingDataSource {
private static final ThreadLocal<DataSourceType> contextHolder = new ThreadLocal<>();
public static void setDataSourceType(DataSourceType type) {
contextHolder.set(type);
}
public static DataSourceType getDataSourceType() {
return contextHolder.get();
}
public static void clearDataSourceType() {
contextHolder.remove();
}
@Override
protected Object determineCurrentLookupKey() {
return getDataSourceType();
}
}
public enum DataSourceType {
MASTER, SLAVE
}
AOP切面自动切换：
@Aspect
@Component
public class DataSourceAspect {
@Pointcut("@annotation(com.example.annotation.ReadFromSlave)")
public void readFromSlavePointcut() {}
@Pointcut("@annotation(com.example.annotation.WriteToMaster)")
public void writeToMasterPointcut() {}
@Before("readFromSlavePointcut()")
public void readFromSlaveBefore(JoinPoint point) {
DataSourceType.setDataSourceType(DataSourceType.SLAVE);
}
@After("readFromSlavePointcut()")
public void readFromSlaveAfter(JoinPoint point) {
DataSourceType.clearDataSourceType();
}
@Before("writeToMasterPointcut()")
public void writeToMasterBefore(JoinPoint point) {
DataSourceType.setDataSourceType(DataSourceType.MASTER);
}
@After("writeToMasterPointcut()")
public void writeToMasterAfter(JoinPoint point) {
DataSourceType.clearDataSourceType();
}
}
注解使用示例：
@Service
public class OrderService {
@Autowired
private OrderMapper orderMapper;
@WriteToMaster
public void createOrder(Order order) {
orderMapper.insert(order);
// 业务逻辑...
}
@ReadFromSlave
public Order getOrder(Long orderId) {
return orderMapper.selectById(orderId);
}
// 复杂查询，可能需要读主库保证数据一致性
public Order getLatestOrder(String userId) {
// 使用主库查询，避免从库延迟
return orderMapper.selectLatestByUserId(userId);
}
}
二、读写分离：架构层面的性能提升
2.1 读写分离的核心原理与陷阱
读写分离的本质是：让读操作和写操作分开，分别走不同的数据库实例。
主库（Master）负责所有写操作和读操作，从库（Slave）通过异步复制主库的binlog来同步数据，专门负责读操作。
但这里有个巨大的陷阱：主从延迟！
在高峰期间，主库写入压力大，从库复制可能滞后。如果用户刚写完数据，立刻读，可能会读到旧数据。这在电商场景下是灾难性的——用户刚下单，查询订单状态却显示“未支付”。
2.2 解决主从延迟的实战策略
我遇到过无数团队在这里踩坑。以下是经过验证的解决方案：
策略一：强一致性读取（强制读主库）
对于关键业务数据（订单状态、支付状态、库存数量），必须读主库：
@Service
public class OrderService {
// 创建订单后，立即读主库获取最新状态
@WriteToMaster
public OrderResult createOrder(OrderCreateRequest request) {
// 写操作
Order order = orderMapper.insert(request);
// 强制读主库，确保数据一致性
DataSourceType.setDataSourceType(DataSourceType.MASTER);
try {
Order latestOrder = orderMapper.selectById(order.getId());
return new OrderResult(latestOrder);
} finally {
DataSourceType.clearDataSourceType();
}
}
// 普通查询，允许读从库
@ReadFromSlave
public List<Order> getUserOrders(String userId) {
return orderMapper.selectByUserId(userId);
}
}
策略二：复制延迟监控与自动切换
@Component
public class SlaveDelayMonitor {
@Autowired
private MasterDataSourceConfig masterConfig;
@Autowired
private SlaveDataSourceConfig slaveConfig;
// 每秒检查一次主从延迟
@Scheduled(fixedRate = 1000)
public void checkReplicationDelay() {
long delaySeconds = getReplicationDelay();
if (delaySeconds > 5) { // 延迟超过5秒
log.warn("主从延迟较大：{}秒，切换到主库读取", delaySeconds);
// 可以在这里触发通知，或者自动切换配置
notifyAlert("主从延迟告警：" + delaySeconds + "秒");
}
}
private long getReplicationDelay() {
// 查询从库的Slave_IO_Running和Slave_SQL_Running
// 计算Seconds_Behind_Master
// 具体实现取决于你的监控方案
return 0;
}
}
策略三：业务层补偿机制
对于不能容忍延迟的场景，可以采用“最终一致性”+“业务补偿”：
@Service
public class PaymentService {
@WriteToMaster
public PaymentResult processPayment(PaymentRequest request) {
// 1. 写支付记录到主库
Payment payment = paymentMapper.insert(request);
// 2. 调用第三方支付渠道
ThirdPartyResponse thirdPartyResponse = thirdPartyClient.pay(request);
// 3. 更新支付状态（写主库）
if (thirdPartyResponse.isSuccess()) {
payment.setStatus(PaymentStatus.SUCCESS);
paymentMapper.updateById(payment);
// 4. 异步通知业务系统（允许延迟）
rabbitTemplate.convertAndSend("payment.success", payment);
} else {
payment.setStatus(PaymentStatus.FAILED);
paymentMapper.updateById(payment);
}
// 5. 立即读主库返回结果
DataSourceType.setDataSourceType(DataSourceType.MASTER);
try {
Payment latestPayment = paymentMapper.selectById(payment.getId());
return new PaymentResult(latestPayment);
} finally {
DataSourceType.clearDataSourceType();
}
}
}
2.3 中间件方案：MyCAT vs ShardingSphere
如果你不想自己写动态数据源，可以使用成熟的中间件：
MyCAT（适合简单场景）：
<!-- mycat schema.xml 配置示例 -->
<schema name="ecommerce" checkSQLschema="false" sqlMaxLimit="100">
<!-- 表配置 -->
<table name="orders" primaryKey="id" dataNode="dn1,dn2" rule="mod-long" />
<table name="order_items" primaryKey="id" dataNode="dn1,dn2" rule="mod-long" />
</schema>
<dataNode name="dn1" dataHost="host1" database="ecommerce" />
<dataNode name="dn2" dataHost="host2" database="ecommerce" />
<dataHost name="host1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native">
<!-- 读写分离：0表示所有读操作分发到从库 -->
<writeHost host="hostM1" url="master:3306" user="root" password="password">
<readHost host="hostS1" url="slave1:3306" user="root" password="password" />
</writeHost>
</dataHost>
ShardingSphere（适合复杂场景，推荐）：
# application.yml ShardingSphere配置
spring:
shardingsphere:
datasource:
names: master,slave1,slave2
master:
type: com.zaxxer.hikari.HikariDataSource
driver-class-name: com.mysql.cj.jdbc.Driver
jdbc-url: jdbc:mysql://master:3306/ecommerce
username: root
password: password
slave1:
type: com.zaxxer.hikari.HikariDataSource
driver-class-name: com.mysql.cj.jdbc.Driver
jdbc-url: jdbc:mysql://slave1:3306/ecommerce
username: root
password: password
slave2:
type: com.zaxxer.hikari.HikariDataSource
driver-class-name: com.mysql.cj.jdbc.Driver
jdbc-url: jdbc:mysql://slave2:3306/ecommerce
username: root
password: password
rules:
readwrite-splitting:
data-sources:
ds:
write-data-source-name: master
read-data-sources:
- slave1
- slave2
loading-strategy: random
props:
sql-show: true
代码使用ShardingSphere：
”`java // 无需任何额外代码，ShardingSphere会自动根据配置路由到正确的数据源 @Service public class OrderService {
@Autowired
private OrderMapper orderMapper;
// 写操作自动路由到主库
public void createOrder(Order order) {
orderMapper.insert(order);
}
// 读操作自动路由到从库
public Order getOrder(Long id) {
return orderMapper.selectById(id);
}
}