在云服务器上部署 MySQL 时，最常见的问题往往表现为查询延迟升高、CPU 占用飙升、I/O 等待时间变长、连接数不足、事务锁等待等。这些问题可能来自于数据库本身配置不当、索引缺失或冗余、慢查询堆积、写入压力过高、缓存机制未启用等因素。因此，在进行优化时，首先需要明确瓶颈所在。通常建议开启慢查询日志，以便定期审查执行时间超过阈值的 SQL，例如：

slow_query_log = 1
long_query_time = 1
log_output = FILE

　　通过分析慢日志，可以将 80% 的性能问题集中定位到 20% 的 SQL 上，这比盲目扩容或调整参数有效得多。

　　在基础性能调优层面，InnoDB 是现今最主流的 MySQL 存储引擎，其多数性能依赖于内存缓存与日志写入机制。因此 innodb_buffer_pool_size 是最关键的参数，它决定缓冲池容量，也决定了数据页和索引页是否能被有效缓存。通常建议将其设置为云服务器总内存的 60%~70%，例如在 8GB 内存机器上设置 5G 是较为合理的。另一个影响写入性能的参数是 innodb_log_file_size，它决定事务日志大小，如果日志过小，高并发写入会导致频繁刷盘，造成磁盘 I/O 升高，一般可设置 256MB~1GB。

　　示例配置如下：

[mysqld]
innodb_buffer_pool_size = 5G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2
max_connections = 600

　　其中 innodb_flush_log_at_trx_commit 设置为 2 时，允许日志每秒刷盘一次，能够有效提高写入性能，适合对数据一致性要求不是绝对强制的高并发场景。

　　性能优化第二层落在索引设计与 SQL 语句上。许多开发者误以为数据库慢就是硬件或配置问题，但实际上 70% 以上的性能瓶颈来自不合理 SQL。索引的设计原则是高选择性(区分度大)优先、频繁查询字段优先、复合索引遵循最左匹配原则，避免对索引字段进行函数运算、隐式类型转换或不等值查询，否则会导致无法走索引。

　　例如下面这种错误写法：

SELECT * FROM order_record WHERE DATE(create_time) = '2025-01-01';

　　由于 create_time 被函数 DATE() 包裹，导致索引失效，优化方式应改为时间范围查询：

SELECT * FROM order_record 
WHERE create_time >= '2025-01-01' 
  AND create_time < '2025-01-02';

　　如果频繁对某个字段组合执行查询，则建议建立复合索引，例如用户日志查询：

CREATE INDEX idx_user_time ON user_log(user_id, create_time);

　　大分页是另一个常见性能陷阱，例如使用 LIMIT 100000, 20 时，数据库需要扫描前 10 万行数据后再丢弃，这种情况下建议使用延迟分页，通过主键记忆上一页末尾 ID：

SELECT * FROM article 
WHERE id < 50000
ORDER BY id DESC
LIMIT 20;

　　这种方式避免了扫描无效数据，适用于日志、文章、评论类表。

　　当单库优化已达到极限时，进一步提升性能必须依赖架构层调整，而读写分离是最常见也最容易落地的一种方式。其核心思想是让主库只负责写，从库专门负责读，这样既分离了锁竞争，又能通过添加从库横向扩展读性能。MySQL 原生通过 Binlog 实现主从复制，通常主库开启二进制日志：

[mysqld]
server-id = 1
log_bin = mysql-bin
binlog_format = ROW

　　然后在从库上进行复制配置：

CHANGE MASTER TO 
  MASTER_HOST='master_ip',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154;
START SLAVE;

　　执行 SHOW SLAVE STATUS\G; 可查看复制状态是否正常。

　　读写分离的实施方式取决于业务架构，如果应用端具备 ORM 框架，可以在程序层做数据源路由，例如 Spring Boot + MyBatis：

spring:
  datasource:
    write:
      url: jdbc:mysql://master:3306/app
    read:
      url: jdbc:mysql://slave1:3306/app,slave2:3306/app

　　如果希望不改代码，则可以使用中间件模式，例如 ProxySQL、MySQL Router、MaxScale 等，它们可以根据 SQL 类型自动分配读写请求，甚至支持读权重、读延迟检测、故障自动切换。

　　在云数据库环境中，读写分离功能已经成为标配，只需在应用中使用专用地址即可，无需额外维护主从复制。这也是企业逐渐从自建迁移到云托管数据库的重要原因之一。

　　除了读写分离之外，进一步提升数据库能力还可以引入缓存、分库分表、冷热数据分层存储、ElasticSearch 全文检索、分布式事务等技术。例如热点数据可以放入 Redis，减轻数据库查询压力;日志类表可以做分表分区，将历史数据转移至归档存储;大规模业务可用 ShardingSphere 或 TiDB 等进行透明分库分表，消除单机 MySQL 存储上限带来的约束。

　　可以看到，MySQL 优化不是单点技术动作，而是一条逐层推进的路径：从参数调优，到索引与 SQL 重构，再到数据库架构升级，最后配合缓存与分布式技术形成完整性能体系。对大多数企业来说，最常见的发展路线往往是单库调优 → 主从复制 → 读写分离 → 分库分表 → 分布式数据库，这也是业务量增长带来的必然演进。

　　因此，如果你目前仍依赖单节点 MySQL，但访问量开始明显上升，慢 SQL 频繁出现、CPU 升高、锁等待时间拉长，那么至少应先完成读写分离架构，这将显著提升可用性和吞吐能力，为后续系统扩展打下基础。