如果你接手过一套正在线上跑的MySQL架构，或者正在准备MySQL方向的面试，那存储引擎、主从复制、分库分表这三块内容迟早要碰到。我自己就是被真实故障教育过的人：第一次是MyISAM的表锁导致全站请求排队，第二次是主从延迟让报表数据跑偏了好几天，第三次是单表数据量破亿之后，一条简单的COUNT查询直接慢到几十秒。这篇文章把这三块内容串起来讲清楚，不会堆概念，而是从选型原理、配置步骤、拆分策略到实例排错，把我验证过的经验和踩过的坑一次说透。
这同时也算是我MySQL系列的开篇，后面会继续深入索引、事务、性能调优等方向。这篇先解决最基础也最关键的架构性问题。
1. 存储引擎选型：InnoDB和MyISAM的那点差异，决定了系统的生死
1.1 为什么说选错引擎比SQL写错更致命
很多人刚接触MySQL的时候，只知道建表时有个ENGINE参数，默认是InnoDB，但这背后意味着什么，很多人并没有真正理解。等到线上出问题才明白，存储引擎直接决定了并发模型、数据安全、性能上限。
MyISAM最核心的特征是表级锁。什么意思？任何一条写操作，比如UPDATE某一行，都会把整张表锁住，期间的读操作全部阻塞。从业务视角看，就是高并发场景下请求莫名其妙堆积，CPU占用看起来不高，但响应时间飙升。我记得比较清楚的一次故障，线上某个活动表用的MyISAM，活动开始的瞬间大量用户同时抢，实际不过是几百个并发写，直接把表锁住了，整个服务接近不可用。
InnoDB用的是行级锁。同样是UPDATE一行，InnoDB只会锁住涉及的行，其他行的读写不受影响。这个差异在低并发场景下体现不明显，一旦并发上来，就是能不能继续跑的区别。
再一个关键差异是事务。InnoDB支持完整的事务特性：原子性、一致性、隔离性、持久性。转账、扣库存、订单状态变更，这些业务逻辑必须依赖事务，否则中间一步失败就会出现严重的账务不一致。MyISAM不支持事务，写完一半挂了，数据就停留在中间状态，根本没有回滚能力。
1.2 崩溃恢复能力的差距
生产环境中最容易被忽略的，是存储引擎的崩溃恢复能力。MyISAM写入数据时，只是简单地把数据写到文件里，没有预写日志。如果数据库进程突然被杀掉、或者主机断电，数据文件有可能处于不一致状态。轻则需要REPAIR TABLE，重则数据直接损坏丢失。
InnoDB的做法是写数据之前先写redo log，把每一个操作记录下来。即使数据库崩了，重启时也能通过redo log把数据恢复到崩溃前的状态，保证提交过的事务不丢失。这也是为什么绝大多数生产环境必须用InnoDB。
我把两者在关键维度的差异整理成了一个表，方便对照：
| 能力维度 | InnoDB | MyISAM |
|---|---|---|
| 事务支持 | 支持ACID | 不支持 |
| 锁粒度 | 行级锁 | 表级锁 |
| MVCC并发控制 | 支持 | 不支持 |
| 崩溃恢复 | redo log恢复 | 无预写日志 |
| 外键约束 | 支持 | 不支持 |
| 全文索引 | 8.0内置支持 | 原生支持 |
| 聚簇索引 | 是，数据按主键组织 | 否，数据和索引分离 |
| 适用场景 | OLTP在线交易 | 只读分析、临时表 |
1.3 查看和修改引擎的实操
实际运维中，最常用的几条命令得记牢。查看当前表用的什么引擎：
SHOW TABLE STATUS WHERE Name = 'orders'\G;也可以在information_schema里查整个库的情况：
SELECT table_name, engine FROM information_schema.TABLES WHERE table_schema = '你的库名';在MySQL里查看当前默认存储引擎：
SHOW VARIABLES LIKE 'default_storage_engine';如果发现某个核心业务表还在用MyISAM，要改回InnoDB，大表不要直接ALTER，后面第6章会专门说这个问题。修改语句本身很简单：
ALTER TABLE orders ENGINE = InnoDB;但这句话对千万级以上的表会锁表很久，生产环境必须用在线DDL工具，这个细节很关键，后面细讲。
MyISAM也不是一无是处。如果某个场景是纯读、无并发写、数据量可控，比如内部的报表库、数据仓库的明细快照表，MyISAM的压缩表特性反而有优势，磁盘占用小，扫描性能也够。但绝大多数互联网在线业务，老老实实InnoDB就行。
2. 主从复制链路拆解：binlog到relay log背后发生了什么
2.1 三个线程的协作模型
理解了存储引擎之后，再看主从复制就顺理成章了。主从复制的底层逻辑其实很简单：主库把所有变更写进binlog，从库去拉取这些日志，再在本地重放一遍。整个过程由三个线程协作完成。
主库端有一个Binlog Dump线程，从库端有两个线程：I/O线程和SQL线程。
I/O线程做的事情是连接到主库，请求binlog内容，主库的Binlog Dump线程负责把日志推送给从库的I/O线程。I/O线程拿到日志后，不是直接执行，而是先写入从本地的中继日志文件relay log。然后SQL线程读取relay log，把里面的操作在从库上重放，变成数据变更。
这里有个容易误解的点：很多人以为是主库主动推送binlog到从库。实际上是从库主动发起连接请求，主库只是被动响应。理解这一点对排查问题很有帮助，比如从库连不上主库时，报的往往是I/O线程的状态异常。
2.2 binlog_format参数怎么选
binlog有三种格式：STATEMENT、ROW、MIXED。这个参数直接决定主从复制的一致性和性能。
STATEMENT格式记录的是SQL语句本身。比如在主库执行UPDATE user SET age = 18，binlog里存的就是这条SQL，从库拿到后原样执行。优点是日志量小，但缺点很致命：如果SQL里有NOW()、RAND()这类非确定性函数，主库执行结果和从库执行结果可能不一样。还有带LIMIT的UPDATE或DELETE，如果数据排列顺序不同，主从执行的影响行数也不同，最终数据就会不一致。
ROW格式记录的是每一行数据的变更前后状态，不关心SQL本身长什么样。优点是绝对可靠，任何语句在主从执行结果一定一致。缺点是日志量成倍增加，尤其是大批量UPDATE或DELETE的时候，binlog文件会膨胀得很快。
MIXED是MySQL默认的自动判断模式。MySQL会根据SQL语句判断是否有不确定性，如果存在就切换成ROW记录，否则用STATEMENT。
我的建议是生产环境直接设置binlog_format = ROW。日志量大的问题可以通过调整binlog过期时间、定期清理来缓解。另外一个实际原因：如果后面想接Canal这类中间件做数据同步、异构数据处理，只有ROW格式才能解析出完整的数据变更事件。
2.3 主从延迟是怎么产生的
主从延迟是最常见的问题，表象是主库写入之后，从库查询数据要等一会儿才能读到。延迟的核心原因，可以归类成几个：
从库SQL线程单线程重放，是延迟的头号杀手。主库可以十几个线程并发写，从库在早期版本只能串行执行relay log，写入能力天然不足。MySQL 5.7开始支持并行复制，8.0进一步优化，配置了slave_parallel_workers之后，能显著降低延迟。配置从库并行复制的参数需要在my.cnf里设置：
slave_parallel_workers = 8 slave_parallel_type = LOGICAL_CLOCK如果从库上还跑着分析类的重查询，或者备份任务，磁盘IO和CPU被占用，同样会拖慢同步速度。建议备份优先在专门的备份实例上做，不要和核心从库抢资源。
大事务是最容易被忽略的延迟源。比如一次批量活动更新几十万行，binlog可能几百MB，从库SQL线程要连续重放很久，期间所有其他变更都卡住了。规避方式是把大事务拆成小批次提交，比如每1万行提交一次。
监控延迟比较简单，执行：
SHOW SLAVE STATUS\G; -- 关注 Seconds_Behind_Master 字段这个字段表示从库落后主库的秒数，等于0时说明已经追上。如果长期不为0，先查是否在执行大事务，再看并行复制参数是否生效。
3. 从零配置一主一从：含远程库单表同步的两种解法
3.1 主库侧的配置与账号
主从复制的配置过程不复杂，但每一步都要仔细。先处理主库。
修改主库的my.cnf，开启binlog并设置唯一的server-id：
[mysqld] server-id = 1 log-bin = mysql-bin binlog_format = ROW sync_binlog = 1server-id在整个复制拓扑里必须是唯一的，这是MySQL用来区分不同实例的标识。sync_binlog=1表示每次事务提交后立即刷盘，保证主库崩溃时binlog不丢，但对磁盘写入性能有一定影响，SSD场景下可以接受。
修改配置后重启MySQL，用下面的命令确认binlog已经开启：
SHOW VARIABLES LIKE 'log_bin'; SHOW MASTER STATUS;然后创建复制专用账号，授予复制权限即可，不需要给超级权限：
CREATE USER 'repl'@'%' IDENTIFIED BY '你设置的密码'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES;这里注意，如果主库已经存在业务数据，从库要先把这些数据同步过去才能开始复制。数据导出的推荐做法是用mysqldump，并且加上--master-data=2参数：
mysqldump --single-transaction --master-data=2 -u root -p --all-databases > backup.sql--single-transaction保证导出期间不会锁表，--master-data=2会在备份文件头部用注释记录当时主库的binlog文件名和位置，后面配置从库时需要用到。
3.2 从库侧的配置与启动复制
从库的my.cnf单独配置：
[mysqld] server-id = 2 read_only = ONread_only=ON很关键，它让从库拒绝非超级权限账号的写操作，防止有人误操作导致主从数据不一致。但注意，read_only不会阻止复制线程写入，也不影响SHOW MASTER STATUS的查看。
从库先导入主库备份：
mysql -u root -p < backup.sql然后查看备份文件里记录的binlog位置。在backup.sql里搜索CHANGE MASTER TO，会看到类似这样的一行注释：
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=82345;有了这个信息后，在从库执行：
CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='你设置的密码', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=82345;启动复制：
START SLAVE;在MySQL 8.0里，命令是START REPLICA，不过START SLAVE依然兼容。确认状态：
SHOW SLAVE STATUS\G;重点关注两个字段，都必须是Yes：
- Slave_IO_Running: Yes
- Slave_SQL_Running: Yes
另外再看Seconds_Behind_Master是否为0。如果I/O线程是No，通常是网络不通、账号密码错误、或者binlog位置填错。SQL线程是No，说明relay log重放中遇到了错误，比如主库执行过从库没权限执行的DDL，或者数据冲突。
3.3 把远程库某张表同步到本地的两种可行方案
热搜里有个很具体的需求：把远程库的这张表同步到本地。这个需求看起来简单，但很容易走弯路。需要先说清楚，MySQL主从复制本质上是整个实例级别的同步，不是为"单张表"设计的。不过在特定场景下，可以用两种方案实现。
方案一：定时导出导入，适合数据量可控、延迟容忍度高的场景。
比如每天凌晨或者每小时同步一次，直接跳过复制链路：
# 在本地机器执行 mysqldump -h 远程库IP -u username -p database_name table_name > table_data.sql mysql -h 127.0.0.1 -u root -p local_database < table_data.sql这种方式实现成本最低，但数据不是实时的，并且每次全量导出导入对源库有一定IO压力。数据量大到几个GB，就要考虑用更高效的工具，比如DataX，支持增量同步，但部署复杂一些。
方案二：在主从复制链路上加过滤规则，适合希望接近实时同步单张表的场景。
在从库my.cnf里配置：
[mysqld] replicate-wild-do-table = testdb.target_table然后重启从库。这样从库只会执行目标表的复制事件，其他表的变更会被忽略。
这里有个很实际的坑：如果目标表所在的库还有其他表也要同步，用replicate-wild-do-table会误伤，所以规划时要考虑清楚过滤范围。还有一个问题是，DDL语句在某些版本里不会受到表级过滤规则约束，可能把不该执行的库级DDL也应用到从库，需要谨慎操作。
综合来看，如果只是企业内部的远程数据汇总，方案一足够；如果对实时性要求高，并且已经规划了主从架构，方案二更合适。真正的大规模异构同步，后续可以考虑引入Canal，把binlog解析后投递到目标端，那又是另一个话题了。
4. 分库分表的临界点与拆分策略：别等慢查询打爆了才后悔
4.1 到底数据量多大才需要分库分表
这是被问得最多的问题，网上流传的说法是单表超过2000万就要分表，其实这个数字没有普适性。更合理的判断标准是：当前单表是否已经出现了性能瓶颈，且优化已经没法解决。
判断依据大概有这几个：
- 索引命中率显著下降。MySQL的InnoDB索引是B+树结构，数据量增大到一定级别后，索引层数会增加，每次查询的IO次数上升。通常千万级以内，三层索引树已经能覆盖大部分场景，到了上亿级别，索引树可能变深或者缓存命中率下降，查询开始变慢。
- 写入QPS打满单库上限。即便全部走索引，单库的写入TPS也有限制，通常在每秒几千到几万，取决于硬件和磁盘。如果写入已经持续打满，SQL再怎么优化也上不去了。
- 磁盘持续高水位。单库的binlog、数据文件、索引文件都在增长，磁盘扩容频繁，备份耗时越来越长。
- 慢查询开始累积，而且集中在同一张表上。
我自己的经验是：优先做优化，而不是急于分库分表。先看索引是否合理，冗余字段是否处理了，冷热数据能否归档，读多写少的场景是否可以考虑增加从库分担读压力。这些手段都试过了，瓶颈还在，再考虑分库分表。
4.2 垂直拆分和水平拆分，先拆哪个
分库分表不等于一上来就按订单ID取模分散数据，它包含两种不同的拆分方式。
垂直拆分是把一张大表的字段拆到多张表或者多个库里。比如把用户表拆成用户基础表、用户扩展信息表、用户认证表。好处是实现简单，对业务改动相对集中。缺点是如果拆得太细，原本一条SQL能拿到的数据要多次查询才能拼装，跨库跨表的join会越来越多。
水平拆分是把同一张表的数据行按规则分到多个表或多个库中，比如订单表按订单ID取模分成orders_0、orders_1、orders_2等多张物理表，每张表的结构完全一样，只是数据范围不同。水平拆分能真正突破单表的数据量和写入瓶颈，但带来的问题也最多，比如跨分片查询、聚合统计、分布式事务，都需要改造。
实际业务里通常先做垂直拆分，把不必要的字段挪走，把热点数据控制在一个相对小的范围内，然后再做水平拆分。垂直拆分是第一步，水平拆分才是真正的大手术。
4.3 分片键选择决定拆分成败
水平拆分中最重要的决策是选择分片键。分片键选错了，后面所有查询都会变得很难受。
最理想的分片键是业务里最核心的访问维度。比如电商订单场景，用户查询自己订单的频率远高于运营后台查询，那么就应该按user_id分片。这样"查询某个用户的所有订单"可以精确路由到固定的分片，一条SQL直接查出来。
按user_id分片可以用取模和范围两种方式。取模的方式是user_id % 64得到分片号，数据分布比较均匀，但扩容时所有数据都要重新分布，这是最麻烦的问题。范围方式是根据user_id的区间分片，比如1到1000万存分片0，1000万到2000万存分片1，扩容时只需要新增分片，迁移量小，但可能存在数据倾斜，比如大客户聚集在某些区间。
分片键和业务查询不匹配时，跨分片查询几乎是绕不过去的。比如电商系统按user_id分片，运营后台要查"某个商品最近7天在不同地区的销量"，就得遍历所有分片再汇总，性能很差。解决思路是设置一个全局表或者索引表，记录商品和分片的映射关系，先查映射表定位到分片，再去目标分片执行查询。
另一个常见误区是所有字典数据、配置数据都跟着主表一起分片。实际上这些数据量很小、修改不频繁，应该做成全库复制，也就是每个分片都存一份完整的副本，查询时直接本地取，不需要跨分片访问。
中间件方面，目前社区里比较主流的方案是Apache ShardingSphere，另外还有一些公司在用MyCat。ShardingSphere支持JDBC和Proxy两种形态，JDBC形态嵌入应用，性能较好，但每个应用都要集成；Proxy形态相当于独立的数据库代理层，应用无侵入，但多了一层网络转发。选择哪种要根据团队的运维能力和架构现状来定，没有标准答案。
5. 拆分后的硬骨头：分布式ID、跨库查询与数据搬迁
5.1 自增主键失效后，分布式ID怎么生成
分库分表以后，原先的数据库自增主键立刻失效。原因很简单：每个分片的自增序列独立，若干分片各自生成的主键会重复。这时候需要引入全局唯一ID生成方案。
最差的方案是用UUID直接做主键。字符串长度长，而且无序性导致索引的随机IO非常严重，B+树的页面会频繁进行分裂和页分裂，写入性能大幅下降。
业界比较成熟的方案是雪花算法Snowflake。它的核心构成是：1位符号位 + 41位毫秒时间戳 + 10位机器ID + 12位序列号。在同一毫秒内最多可以生成4096个不同ID，并且整体趋势递增，对索引友好。现在很多语言的第三方库都实现了雪花算法，比如常见的snowflake库或者美团开源的Leaf。
还有一种是利用Redis的INCR命令生成ID，简单可靠，但依赖Redis高可用，如果Redis挂了，ID服务也跟着不可用。数据库发号表的方式则是单独维护一张表记录当前ID水印，每次取一个批次发号，适合对ID生成频率不高的场景。
5.2 跨分片的查询、排序和事务问题
分库分表之后，原来一个SQL能搞定的排序、分页、聚合，变成了跨分片问题。比如要按时间倒序分页查看订单列表，所有分片都得先把各自的数据排好序，然后在应用层合并归并。
数据量小的时候，在内存里归并排序还能接受。数据量大，或者分片特别多，就会很吃力。务实的做法是事先避开这种场景：在订单表里冗余一个全局唯一订单号字段，并保证它本身携带时间特征，这样在应用层合并时的排序依据只会落在少数几列上。
跨分片join也尽量别做。拆分之后不同表可能在不同的库甚至不同的实例上，数据库层面根本没法做好join。替代办法有几个：字段冗余，比如订单表直接冗余用户名，省掉下单时调用户表的查询；多次单表查询后在应用层组装；或者把数据同步到Elasticsearch做检索聚合，再回表取详情。
分布式事务是更麻烦的事。分布式数据库中间件通常提供XA分布式事务，但性能开销很大。业务上更常见的做法是放弃强一致，采用最终一致性方案，比如本地消息表、RocketMQ事务消息、TCC模式等。这些方案各有适用场景，但对业务代码的改动都不小，所以很多团队在分库分表时，会尽量把需要强一致的数据放在同一个分片内，从源头规避分布式事务。
拿订单系统举例，下单这个动作涉及订单主表、订单明细表，如果这两张表在同一个分片内，事务仍然支持；如果订单表和用户表不在同一分片，就只能用最终一致性方案。这也是为什么分片键和分片粒度一定要提前规划，而不是上线后再说。
5.3 存量数据怎么平滑搬迁移
最粗暴的方式是停机迁移。选定一个业务低峰期，比如凌晨2点到4点，把应用停掉，导出所有旧数据，做清洗和分片，导入新库，再启动应用切换流量。这个方案的优点是可以预见的坑少、实现简单，缺点是需要停服，业务规模到了一定程度，产品经理和老板未必接受。
更平滑的是双写方案。过程大概是：先在应用层把读写同时写到旧库和新库，新库从旧库拉取全量数据作为基础；双写一段时间后，用对账任务检查两边数据是否一致，不一致的部分回溯旧库的binlog重新回放；等数据一致且稳定后，把应用读流量逐步切到新库，最后停掉旧库的写。这个方案对应用层改造要求高，但可以在不中断业务的情况下完成迁移。
数据迁移工具方面，离线全量同步可以用DataX，增量同步可以考虑采用Canal订阅binlog后转发到目标端。这里的关键点是，增量同步和双写可能会有重复写的问题，必须设计好幂等策略，否则数据被写两次或状态被覆盖，对账会很难看。
坦白说，分库分表的迁移是最考验耐心和细致程度的环节。别指望一次切换成功，每一步都要验证、备份、回退预案准备好。
6. 主从复制与分库分表最容易踩的坑
6.1 切换存储引擎的隐性问题
如果把一张千万级的大表从MyISAM改成InnoDB，直接执行ALTER TABLE ENGINE = InnoDB，在MySQL 8.0之前会全程锁表，业务上的写入会被阻塞非常久。正确的做法是用在线DDL工具，比如pt-online-schema-change或者gh-ost，实现无锁切换。它们是创建一个新表结构，然后通过触发器或者解析binlog的方式把旧数据逐步同步到新表，最后在原表上做一次原子rename。
还有一个容易忽略的细节：修改某个表的引擎之前，先查一下它有没有和其他表存在外键关系。如果外键字段的类型、索引不满足InnoDB的要求，外键约束可能创建失败，或者改成InnoDB之后原有的外键行为发生变化。
6.2 从库数据不一致的排查与修复
主从数据不一致最常见的诱因是有人在从库手动写了数据。设置了read_only之后，只靠普通账号写不进去，但如果有账号有SUPER权限，依然能绕过read_only。这就需要在运维规范上控制好账号权限，不能给应用账号超级权限。
另一个诱因是主库执行了大事务，从库重放期间，一条报错中断了SQL线程。比如主库创建了一张表，从库上因为某种原因表已经存在，重放时报告错，SQL线程就会停下来。没有及时发现的话，从库就会一直停留在旧状态。
检测不一致的常用工具是pt-table-checksum，它可以对比主从之间的表数据，把差异记录出来。修复用pt-table-sync，但务必在确认差异范围后再执行，而且最好先在测试环境验证。
我自己处理过一次比较典型的问题：从库磁盘满了，I/O线程断开，业务侧因为没有告警，硬生生隔了一周才发现。从那之后，我对主从状态加了两层监控：一层是定时抓取SHOW SLAVE STATUS的各个关键字段，另一层是定期执行pt-table-checksum做数据校验。
6.3 锁表问题的排查链路
锁表问题在热搜里反复出现，确实也是实践中的高频故障。出现锁表时，不要慌，按照下面这个链路来排查。
先看当前所有连接在做什么：
SHOW FULL PROCESSLIST;重点看State列，很多锁等待会显示Waiting for table metadata lock、Waiting for table level lock、或者处于Locked状态。
如果出现大量Waiting for table metadata lock，通常是有人执行了DDL，而DDL在等待某条查询释放表的元数据锁。查询本身可能一直不结束，或者被事务卡住。这种场景下，先找出阻塞源头。在MySQL 8.0里可以直接查performance_schema.data_lock_waits，比较麻烦的方式是查information_schema.innodb_trx，看当前事务列表，然后根据事务的开始时间和状态判断谁在持有锁。
造成行锁竞争的最常见原因是索引失效。比如UPDATE一个字符串字段，没加引号，或者隐式类型转换，导致索引没有走到位，最终InnoDB给整张表的所有行都加了锁。表面上看是行锁，实际效果和表锁没区别。这个问题的规避方法是把SQL的执行计划养成习惯，任何一个UPDATE或DELETE在生产执行之前，先用EXPLAIN看一遍访问类型是不是range、ref或者eq_ref，如果是ALL，就得停下来先处理索引。
死锁问题主要靠参数兜底。innodb_lock_wait_timeout控制等待锁的时间，默认50秒，可以在my.cnf中调低到10秒左右，让业务快速失败后重试。同时开启innodb_deadlock_detect，MySQL会定期检测死锁并回滚其中某个事务，避免互相僵持。
6.4 关于MySQL面试题的一些方向
既然热搜里有mysql面试题，我也顺便说两句。面试官问存储引擎，本质是想考察你能否判断线上场景的技术选型；问主从复制，本质是考察你对数据一致性和高可用的理解；问分库分表，更多是考察面对大规模数据时，你有没有系统性的思考能力。
所以光记住概念不够，最好能展开说说你实际遇到过什么问题、怎么排查的。比如提到MIXED binlog格式，如果能说清楚为什么不建议在生产环境用STATEMENT，就会比单纯背概念有说服力得多。面试中还有一个高频点是问你MySQL 8.0相比旧版本的变化，比如默认认证插件改成了caching_sha2_password，如果客户端驱动版本太老，就会出现认证失败，连接不上，这在部署新版本的时候非常容易踩中，提醒大家在升级时同步更新驱动。
如果自己搭过一套主从、跑过分库分表的迁移演练，把这些经历讲出来，比背一百道面试题都管用。
我个人在实际操作中的体会是，数据库架构设计没有银弹。存储引擎选型、主从复制、分库分表这三件事，本质上都是在做取舍：用一致性换性能，用复杂度换容量。每次动手之前，先问一句"当前瓶颈到底在哪、不拆行不行、拆了之后受益的是哪个查询"，把这一步想明白，后面很多坑都可以提前躲开。
