文章目录
-
- 一、先说大实话：两者不能互相替代，干活分工完全不一样
- 二、直白对比：分库分表和ES，差别到底在哪？
- 三、实战场景怎么选？照着抄就行
- [四、大厂通用终极方案：MySQL分库分表+ Canal同步ES](#四、大厂通用终极方案：MySQL分库分表+ Canal同步ES)
- 五、手把手实操：Canal同步MySQL分库分表数据到ES，直接照着做
- 六、最后简单总结，记住四句就够用
做后端开发久了，只要项目数据量起来、并发一高，早晚都会碰到两个技术： MySQL分库分表 和 Elasticsearch（ES） 。
我见过太多新手、初级开发踩同一个致命坑：把这俩东西当成二选一，觉得用了一个就不用另一个。
要么不管业务啥情况，数据一多就跟风搞分库分表，天天跟分片规则、跨库查询、分布式事务较劲，开发写代码累半死，运维维护头都大；要么图开发省事，直接想用ES替代MySQL存订单、支付这些核心数据，最后线上数据丢数据、对账对不上、业务逻辑错乱，出一堆生产事故。
1、分库分表和ES根本不是竞品，各自干啥活，一次讲明白；
2、啥业务必须分库分表？啥业务直接上ES就行？贴合真实工作场景举例；
3、大厂统一标准玩法：MySQL分库分表+Canal同步ES，整套架构+手把手实操步骤。
看完不用再纠结选型，面试能直接说，项目上手就能用，线上上线不翻车。
一、先说大实话：两者不能互相替代，干活分工完全不一样
一句话给大家定调，记这一句就够：
MySQL分库分表，专门管正经业务「写数据、算钱、保数据不出错」；
ES专门管各种「查数据、搜内容、做报表、筛列表」。
分库分表再厉害，复杂模糊搜索、多条件筛选、大批量统计照样拉胯；ES查询再丝滑，也绝对不能拿来存下单、支付、扣钱这种核心交易数据，扛不住也扛不起。
说白了：一个负责把数据安稳存好、业务跑稳；一个负责把数据快速查出来、展示好用。各司其职，搭配着用才最稳。
二、直白对比：分库分表和ES，差别到底在哪？
1、核心本质完全不是一回事
✅ MySQL分库分表
底层还是咱们天天用的MySQL，没啥新花样。就是把一个超大的库拆成几个小库，一张超大的表拆成一堆小表。该有的事务照样有，该有的联表查询照样支持，数据修改、回滚、强一致性全都保留。
核心就一句话：还是正经数据库，专门踏实存核心业务数据。
✅ Elasticsearch（ES）
它压根就不是用来做交易存储的数据库，本质就是个搜索引擎。天生就是为了搜索、筛选、统计数据设计的，不支持事务，数据不是实时强一致，增删改性能也一般，还会有短暂同步延迟。
核心就一句话：只适合拿来查、拿来搜，绝对不能当主库存核心数据。
2、关键区别一目了然（工作选型直接看）
| 对比维度 | MySQL分库分表 | Elasticsearch（ES） |
|---|---|---|
| 事务能力 | 强事务支持，数据绝对一致不乱 | 无事务，数据有延迟，一致性弱 |
| 擅长做什么 | 新增、修改、交易写入、联表业务逻辑 | 模糊搜索、多条件筛选、海量分页、数据统计 |
| 大数据查询表现 | 按分片键查很快，复杂筛选、跨库查询巨慢 | 不管怎么查、怎么分页，海量数据都很丝滑 |
| 适合写入场景 | 下单、支付、扣款等高并发核心写业务 | 不适合写业务，只适合同步过来的副本数据 |
| 运维开发难度 | 中等，主要管好分片规则就行 | 偏高，要调集群、内存、分片、同步规则 |
| 数据延迟 | 实时写入，零延迟 | 近实时，同步有毫秒到秒级小延迟 |
三、实战场景怎么选？照着抄就行
1、只要沾钱沾交易，老老实实搞MySQL分库分表，别碰ES
只要业务涉及下单、付钱、退款、对账、用户余额、资金流水，别管数据量大小，核心主库必须是MySQL分库分表，ES一点都别沾。
真实工作常见场景：
✅ 电商下单付款、订单退款、财务记账对账
✅ 用户注册、账号余额、会员权益、个人账户管理
✅ 库存扣减、下单锁库存、交易核心核心链路
道理很简单：这些业务一旦数据错乱、丢数据，就是真金白银的损失，只有MySQL能保事务、保数据安全，ES扛不起这个责任。
2、只查不改、只搜不写，直接上ES，别瞎折腾分库分表
如果你的业务就是后台列表、条件筛选、关键词搜索、日志查看、报表统计，不用改数据、不用事务，直接上ES就完事。非要给MySQL搞分库分表，纯属给自己增加开发运维负担，吃力不讨好。
真实工作常见场景：
✅ 电商商品关键词搜索、标题模糊检索、搜索结果高亮
✅ 运营后台订单全量列表、多条件筛选、时间范围查询、大批量分页导出
✅ 系统运行日志、用户操作行为记录、运维排查问题查日志
✅ 业务数据大盘、流量统计、各类运营报表数据分析
这类场景最怕查询慢、分页卡、筛选复杂，ES天生适配；要是用分库分表做复杂跨分片查询，又慢又难写，纯属给自己找麻烦。
四、大厂通用终极方案：MySQL分库分表+ Canal同步ES
正经企业项目从来不会二选一，都是一套组合玩法：写业务走MySQL分库分表，查数据全部走ES，Canal负责自动同步数据，既保数据安全，又保查询速度，两边优点全占了。
1、整体业务流转流程
用户下单/业务操作写数据 → MySQL分库分表存核心数据，保障事务靠谱 → MySQL自动记录Binlog日志 → Canal监听日志变化自动同步数据 → 数据实时同步到ES集群 → 前台搜索、后台列表、报表统计全部查ES，不查MySQL
2、这套架构为啥稳定好用？
✅ 分工明确互不干扰：写交易压给MySQL，查询检索压给ES，读写彻底分离，谁都不拖累谁；
✅ 不用改业务代码：原有下单、改数据代码完全不动，全靠Canal监听日志自动同步，零侵入业务；
✅ 后台查询丝滑不卡顿：再多筛选、再多分页、再多数据量，ES都能扛住，不用再写MySQL复杂慢SQL；
✅ 数据延迟极低：同步速度很快，业务用户完全感知不到时间差；
✅ 扩容简单好维护：MySQL只管扩容写节点，ES只管扩容查询节点，后期业务暴涨不用慌。
五、手把手实操：Canal同步MySQL分库分表数据到ES，直接照着做
步骤都是生产环境实测过的，新手直接复刻就能跑通，不用额外复杂开发，快速实现自动同步。
第一步：提前准备好基础环境
1、已经搭好MySQL分库分表环境，订单、用户数据正常写入没问题；
2、MySQL必须开启Binlog日志（Canal同步的核心前提，不开同步不了）；
3、装好ES集群和Kibana，用来存数据、看索引、查同步情况；
4、下载安装Canal服务端和canal-adapter适配器，专门做数据同步转发。
第二步：MySQL开启Binlog基础配置
修改MySQL核心配置文件my.cnf，开启日志并设置格式，改完重启MySQL生效：
properties
# 开启binlog日志功能
log-bin=mysql-bin
# 日志必须用ROW行模式，才能精准同步每一行数据变化
binlog-format=ROW
# 设置数据库唯一ID，集群环境必填
server-id=1
# 指定需要同步的分库分表业务数据库名
binlog-do-db=db_order_sharding第三步：配置Canal服务端监听MySQL
1、修改Canal核心配置，填上自己MySQL的连接地址、账号密码；
2、不用一个个单独配置order_0~order_7、user_0~user_3分片表，Canal能自动匹配监听库下所有分片表；
3、配置完成启动Canal，持续监听MySQL数据新增、修改、删除操作。
第四步：配置canal-adapter适配器，关联MySQL分片表和ES索引
这一步是核心，主要配置数据映射关系，让MySQL分片数据自动对应到ES统一索引，全量历史数据和后续增量数据都能同步：
yaml
# 绑定自己的ES集群地址
es:
host: 127.0.0.1:9200
index: order_user_sharding_index
# MySQL字段和ES字段一一对应映射
mapping:
id: id
order_no: orderNo
user_id: userId
goods_name: goodsName
order_amount: orderAmount
create_time: createTime
# 绑定MySQL数据库信息，正则匹配所有分片表
db:
host: 127.0.0.1:3306
database: db_order_sharding
table: order_.*,user_.* 第五步：初始化全量数据，开启实时增量同步
1、先执行全量数据初始化，把MySQL分库分表里的历史老数据一次性同步到ES；
2、开启Canal增量同步，后续MySQL新增、修改、删除的数据，会自动实时同步到ES；
3、打开Kibana查看ES索引数据，核对数据完整一致，同步没差错就搞定。
第六步：业务代码简单调整
1、下单、新增、改数据等写操作：完全沿用原来MySQL分库分表代码，不用改一行；
2、后台列表、搜索查询、数据统计读操作：全部改成查询ES，不再查MySQL分片；
3、完美实现读写分离，MySQL压力大减，查询速度翻倍。
六、最后简单总结，记住四句就够用
1、分库分表管写事务，ES管搜索查询，别想着二选一替换，一定要搭配用；
2、交易、资金、核心业务老老实实分库分表，搜索、列表、报表、日志直接上ES；
3、企业生产标配：MySQL分库分表存核心数据+Canal实时同步ES+查询全部走ES；
4各司其职不乱用架构，项目才稳定、好维护、后期好扩容。