笔者也曾经有类似的疑问，因此请教过京东的架构师和58同城的 DBA 负责人 ，结论如下：
京东的核心交易是分库分表的策略 ;58 同城的核心交易是分库分表的策略，非核心业务场景大量使用 Tidb ，积累了丰富的运维经验。笔者认为之所以在这两家电商公司核心业务依然是以分库分表，有一个非常重要的原因：分库分表的原理和运维相对简单。
我们以当前最流程的分库分表中间件 shardingsphere 为例，它包含两大产品：
ShardingSphere-ProxyShardingSphere-JDBC▍一、ShardingSphere-Proxy
ShardingSphere-Proxy 被定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。
代理层介于应用程序与数据库间，每次请求都需要做一次转发，请求会存在额外的时延。
这种方式对于应用非常友好，应用基本零改动，和语言无关，可以通过连接共享减少连接数消耗。
▍二、ShardingSphere-JDBC
ShardingSphere-JDBC 是 ShardingSphere 的第一个产品，也是 ShardingSphere 的前身， 我们经常简称之为：sharding-jdbc 。
它定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。
当我们在 Proxy 和 JDBC 两种模式选择时，可以参考下表对照：
JDBC
Proxy
数据库
任意
MySQL/PostgreSQL
连接消耗数
高
低
异构语言
仅Java
任意
性能
损耗低
损耗略高
无中心化
是
否
静态入口
无
有
下图展示了 Prxoy 和 JDBC 两种模式的核心流程。
1.SQL 解析
分为词法解析和语法解析。 先通过词法解析器将 SQL 拆分为一个个不可再分的单词。再使用语法解析器对 SQL 进行理解，并最终提炼出解析上下文。
解析上下文包括表、选择项、排序项、分组项、聚合函数、分页信息、查询条件以及可能需要修改的占位符的标记。
2.执行器优化
合并和优化分片条件，如 OR 等。
3.SQL 路由
根据解析上下文匹配用户配置的分片策略，并生成路由路径。目前支持分片路由和广播路由。
4.SQL 改写
将 SQL 改写为在真实数据库中可以正确执行的语句。SQL 改写分为正确性改写和优化改写。
5.SQL 执行
通过多线程执行器异步执行。
6.结果归并
将多个执行结果集归并以便于通过统一的 JDBC 接口输出。结果归并包括流式归并、内存归并和使用装饰者模式的追加归并这几种方式。
从上面的解析，我们可以发现分库分表中间件原理非常相对简单。
很多同学认为分库分表复杂，是因为在生产环境实战偏少，没有足够的技术储备，很多互联网公司在使用分库分表的过程中，积累了大量的工程经验和技术储备，比如和分库分表密切相关的 DTS 数据传输服务，因此互联网公司使用分库分表起来比较有信心。
最后，谈谈笔者对于技术选型的看法。
Databases are specializing – the “one size fits all” approach no longer applies ----- MongoDB设计哲学
第一点：先有场景，然后再有适配这种场景的技术。什么样的场景选择什么样的技术。
第二点：现实往往很复杂，当我们真正做技术选型，并需要落地的时候，技术储备和成本是两个我们需要重点考量的因素。
▍ 技术储备
技术团队有无使用这门技术的经验，是否踩过生产环境的坑，以及针对这些坑有没有完备的解决方案；架构团队是否有成熟的SDK，工具链，甚至是技术产品。▍ 成本
研发，测试，运维投入人力成本；服务器资源成本；招聘成本等。最后一点是人的因素，特别是管理者的因素。每一次大的技术选型考验技术管理者的视野，格局，以及管理智慧。
